[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] CDT and Qt Creator
|
Won't the Project Layout issues be resolved by the E4
Flexible
Projects work Serge Beauchamp had done?
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