|Re: [cdt-dev] CDT and Qt Creator|
Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:
-- 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.
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.
-- 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.
-- 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.
-- "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!
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?
Back to the top