Re: [cdt-dev] CDT and Qt Creator

[James Blackburn <jamesblackburn@xxxxxxxxx>]

2009/12/12 John Cortell <rat042@xxxxxxxxxxxxx>:
> Won't the Project Layout issues be resolved by the E4 Flexible Projects work
> Serge Beauchamp had done?

Our product has serge's flexible resources stuff in it, and it works
well. It effectively gives you VS style projects + the Eclipse
resource model - local history, team support (if linked resources are
supported), etc all working with CDT editing, managedbuild & debug
(CDI).

I believe CDT will  be able to cope with all this just fine.  There
may be a couple of places which still don't handle linked resources
properly, but when I was working on this, I went on a blitz of
submitting / committing fixes...

Cheers,
James

>
> John
>
> At 06:11 PM 12/11/2009, Doug Schaefer wrote:
>
> This is great data, and we could do something about most of this, if we work
> together as a community to address them. Up until now, we haven't really
> been involved in solving these issues for Carbide.
>
> Next question. How does Qt Creator do these things better? Since that's the
> real topic of this thread.
>
> Doug
>
> On Fri, Dec 11, 2009 at 6:44 PM, Adrian Taylor <adrian@xxxxxxxxxxxx> wrote:
> Speaking as a user of Carbide, rather than one of its developers, here are
> some specifics from me:
>
> Project layout:
>
> -- Symbian has very specific ideas about project filesystem layout, as does
> Eclipse, and the two are fundamentally incompatible. Specifically:
> -- Project files in Symbian-land are stored deep in a subdirectory, whilst
> Eclipse insists that .project and .cproject are at the outermost point which
> contains any relevant source code or headers.
> -- Several Symbian projects may have the same 'outermost point' and thus
> conflict in Eclipse-land.
> I know that the Carbide team and you yourself Doug have been fighting the
> Eclipse establishment to relax these rules, to little avail. I know you have
> hopes for EclipseFS. But meanwhile, this is responsible for a majority of
> the complexity.
> -- The nature of projects themselves are a problem. Why shouldn't you just
> be able to work directly on Symbian project files? Why the need to create an
> Eclipse project? The Carbide team has done a great job of hiding it well
> using a slick import wizard, but it's still wrong.
> -- And what's a workspace? Eclipse seems to want to copy, or at least link,
> my code into its own directory. Why? All my code has a fixed location in
> Symbian-land.
>
> Builds:
>
> The Carbide team have jumped through some big hoops to get the Symbian build
> system to play nicely with CDT, and on the whole, it now works well. But
> there are is still untidiness round the edges:
>
> -- CDT can't cope properly with multi-line error messages emitted by
> compilers. In C++ code full of templates, that leads to despair and
> hopelessness.
> -- Build configurations are important for Symbian. In CDT they are hidden
> away. And, although Carbide could expose that feature more obviously in the
> UI, it still might not be smooth in terms of the settings which applied
> globally versus as part of a build configuration.
> -- There's nothing Carbide or CDT can do about this, but Symbian builds are
> slow. I think there's a perception they're slower in the IDE (sometimes this
> is true, but either way, it's the perception that counts). The whole CDT
> experience seems hugely less slick when builds always take 5-20 minutes.
> It's not related to complexity, but it is probably one reason why people are
> put off Carbide.
>
> Indexer:
>
> -- The indexer is *great*. But...
> -- Often things go grey when you've made a mistake, but there's no way to
> find out the error message until you spend 10 minutes building the project
> with a compiler. It just seems weird to a user to have two different things
> parsing the code. Why does the IDE know I've done something wrong but it
> won't tell me what? Seems weird to an end-user.
> -- Likewise, you have to fiddle with two sets of macro definitions, include
> paths etc. The Carbide team has done a good job of hiding this but it's not
> transparent.
> -- Unfortunately the indexer still isn't quite perfect. For example the call
> hierarchy sometimes just stops. Which is a shame because when it works, it's
> terrific. But the fact that you can't quite trust its results makes
> everything seem complex.
>
> Launches:
>
> -- Launch configurations are useful. All the (fairly recent) efforts to
> hide/automate them are also useful. But they still seem to lurk as something
> sinister behind the scenes which users eventually will have to understand.
> The need for them is not obvious in Symbian-land.
> -- The debug view is a pain. You seem to have to click in it before you can
> use debug keys, or at least it's possible for it to lose focus. Debugging
> should be a global operation, not stuck in some funny little pane. This may
> be Carbide-specific; I don't know.
>
> Eclipse runes:
>
> -- "Hard to learn" - to be a confident user of Carbide, you have to
> understand a perspective, a view, an editor, a plugin, a workspace, a
> project, a build configuration, a launch configuration, and probably a bit
> more. All of these are Eclipse terminology.
> -- You just don't want to have to learn 10 more concepts when you're already
> struggling with the Symbian weirdness!
> -- I imagine most Carbide users need to install Subversive pretty quickly.
> Then not only do they have to struggle with understanding plugins, update
> sites, etc. but they also have to contend with the Eclipse IP process, or
> specifically its implications meaning the key bits of Subversive are
> squirreled away on someone else's website. Sigh. It's enough to drive me mad
> and I must have installed it a dozen times. Still, things are improving in
> that specific area now.
> -- Eclipse keystrokes differ from the rest of the world's.
> -- Carbide's greatest value is in the indexer features hidden behind obscure
> keystrokes. Sadly I think most Carbide users don't get far enough to learn
> F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.
>
> I use Eclipse, Carbide and CDT all the time. For me, the power of the
> indexer makes it all worthwhile. But I must admit, if I were to try to
> create a simple IDE for Symbian beginners, I probably wouldn't start with
> Eclipse!
>
> Adrian
>
>
> On 11 Dec 2009, at 23:09, Doug Schaefer wrote:
>
> Instead of talking in generalities, I'd prefer to talk with specifics.
> Saying Carbide is hard to learn, what exactly about it is it hard to learn?
> Is it things in the CDT or Eclipse platform or things Carbide has added on
> top? Is it creating projects? Is it setting up builds? Is it launching debug
> sessions? Is it creating files? Is it too many choices? Would adding wizards
> in strategic places make the CDT easier to learn?
>
> Most of the complaints on usability with Eclipse I've heard are really
> complaints from users who find IDEs complex in general. Is Qt Creator really
> that less complex than the CDT? What about Qt Creator makes it easier to
> learn. And why don't we invest in the CDT to make it equivalent?
>
> Doug.
>
> On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech < pawel.piech@xxxxxxxxxxxxx>
> wrote:
> All we've done so far is rather vendor-specific.  What we would like to see
> in CDT is the ability to isolate and turn off various features using
> capabilities: e.g. build, static analysis, debuggers, etc.  To accomplish
> this we would likely need to look at dependencies between these various CDT
> components and see if we can isolate them better.  However, we haven't
> invested any time in this yet.
> -Pawel
>
>
>
> Paul Beusterien wrote:
>
> Hi Pawel,
>
> Thanks for the response.  Are there any available artifacts from the
> stripped-down IDE investigation?  Any effort estimates?
>
> Regards,
> Paul
>
> On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech < pawel.piech@xxxxxxxxxxxxx>
> wrote:
> Hi Paul,
> Complexity is a common complaint about Eclipse-based tools (not especially
> limited to C - development tools).  I don't know of any efforts to overhaul
> the UI, but I expect that there would be a lot of interest out there for
> it.  For Wind River's part, we are investigating creating a stripped-down
> version of the IDE specifically targeted at Debugging use cases, but I know
> we won't be able to get far without support from the community.
>
> Cheers,
> Pawel
>
> Paul Beusterien wrote:
>
> Hi CDT community,
>
> I'm responsible for the tools strategy at the Symbian Foundation.  Like the
> Eclipse Foundation, Symbian depends on the contributions from open source
> communities to drive its mobile device platform technology forward.
>
> I'm curious if you have any thoughts about one of the challenges we're
> facing with understanding/determining the direction for Symbian C++
> development tools.
>
> There are two open source communities vying for the Symbian C++ developer -
> Qt Creator and Carbide (based on CDT).
>
> Carbide's investments have been primarily focused on adding features to give
> more power to device creators. While it has become very feature-full, it has
> also become very complex and hard to learn, especially for developers that
> want to just build simple mobile apps.
>
> Qt Creator is a targeted C++ development environment with a big emphasis on
> usability.  For example, it has rigorous hurdles to add a button or menu
> item. Now, it is rapidly adapting to improve its mobile development
> capabilities.
>
> Thus, we currently have a fragmented C++ developer story at Symbian.
>
> It is unlikely that Qt Creator will ever support the rich set of features
> that Carbide currently provides to the power user.
>
> Are there any initiatives will enable CDT based IDEs to lower its learning
> curve and better support the needs of a simple C++ application developer?
>
> Thanks,
> Paul
>
> --
> Paul Beusterien
> Development Tools Manager
> Symbian Foundation
> Foster City, California USA
> twitter: paulbeusterien
>
>
>
>
>
>
> _______________________________________________
>
> cdt-dev mailing list
>
> cdt-dev@xxxxxxxxxxx
>
>
>
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>