Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] CDT and Qt Creator

There's three main things I filter from the Symbian engineering comments that are more generic (from my experience as a Symbian developer and Carbide developer):
 
1) Eclipse start-up is too slow. This is becuase we load all projects in the workspace - always. Qt Creator and Visual Studio don't load projects on start-up, rather they ask what you want to do before loading anything.
 
2) Context menus and commands are cluttered and a strain to find anything. Basically, if you don't know hot keys for eclipse, you will suck at the tool. I've found giving a cheat sheet to developers with top 10 or 15 hot keys decreases frustration levels more than anything. I'm sure comamnd groups could be organized/filtered. I can right click on a source file for a simple Qt creator project and see 7 commands, no sub-menus. On a small project in Carbide I get 46 options, many with sub-meuns (27 if  you exclude Carbide-specific commands). 11 commands are for searching/navigation alone. Some comamds don't even make sense (Run/Debug As on a soruce file?)
 
3) Navigation/Search in Qt Creator is cleaner. There's one search field where you can get to files, resources, methods, classes etc. With ecipse/CDT you need ctrl+shift+r, ctlr+t, ctrl+shift+a, ctrl+shift+t, find in files (and other confusing find features).  (Basically same thing at 2)). I don't know how well Qt search really scales, but the UI concept is very clean and seems obvious.
 
With proper focused training I don't think Carbide/Eclipse is any more complex to use than Qt Creator, it's simply a matter of weeding the complexity to find the fundamental IDE features from more advanced stuff.
 
Thanks,
Tim


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Doug Schaefer
Sent: Monday, December 14, 2009 7:21 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] CDT and Qt Creator

This feedback seems to deal mainly with issues in Carbide itself and how it manages Symbian development, not CDT. I'm much more interested in a comparison between Qt Creator and the Eclipse C/C++ IDE for host development for example. That would be comparing apples with apples, and could bring up ideas that we can fix in the CDT itself.

Doug.

On Mon, Dec 14, 2009 at 6:54 PM, Paul Beusterien <paulb@xxxxxxxxxxx> wrote:
Doug> Next question. How does Qt Creator do these things better? Since that's the real topic of this thread.

Here is the answer from Hamish Willee, one of the Symbian engineers experienced with both tools

----------------------------------------------

I think Qt creator is a much simpler IDE to learn than carbide/eclipse. This is pretty much down to the fact that Carbide is a visual mess - everything is in there but you need to learn how to navigate it and to cope with a high degree of screen clutter - most of which you won't use most of the time. Unfortunately you can't just shut down all the views to make it simpler, because if you do so you'll spend hours trying to work out how to bring them up again when needed; Even when you understand the eclipse model for views, perspectives etc, you can still get lost. 

In contrast, creator is much simpler and less cluttered, while still managing to present all the things you need right "up front":
1.  The sidebar gives you immediate access to the main views - code edit view, debug, help, project settings, and buttons to run, debug or build the current project. The icons for these are large, and their meaning is intuitive.
2. The position of elements on the screen and menus is both logical and fixed. I can find it when I want it without having to dip into the help system.
3. Creator starts as a blank canvas. It offers a welcome screen that offers me my recent projects. I prefer this to the carbide mechanism of opening my recent projects and tabs. I know some people may wish for this, but I'm always shutting down tabs that I didn't want open from old projects.

One reason Qt can do this because it doesn't try to give you a view on Symbian. [ Qt Creator abstracts much more of Symbian away than Carbide.]

I don't know if Eclipse can be "fixed" for this. I think its a job for a professional UI designer. 
One thing I would consider is having a single menu item for ALL Symbian specific stuff - with links to all the other settings etc that are currently scattered in the other menus - e.g. links to the symbian sections in the global preferences settings, project settings, debug configurations, etc.

I'd also discuss with the community whether we should do less on startup - ie instead of starting everything that has already been loaded, return to a minimalist view that lists just the current projects.

In summary, Carbide needs to be learned while Qt creator is intuitive.

----------------------------------------------

On Fri, Dec 11, 2009 at 4:11 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> 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




--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
1-650-918-7074
skype: paul.beusterien
twitter: paulbeusterien

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top