> And, yeah, if your IDE doesn't do as much, it will be
simpler.
There seems to be a usability tradeoff
between IDEs focused on a single language and a limited set of problems domains,
vs. a generic, multi-language IDE like Eclipse or Visual Studio. Examples
on the Visual Studio side include, on the simplicity end, Visual Basic and
Visual C++ from ten years ago vs. the current, all encompassing Visual Studio. A
simple example is on the usability of VC++ version 6 (which pretty much only
supported C++ development) and its successors which support .NET languages, additional
tools etc. When the user asked for help on a topic in VC++ version 6,
they got help specific to using it with VC++. With later versions of
Visual Studio, you have to wade through many hits to help topics that are not appropriate
to your task at hand. There are ways to try to handle this including,
filtering, context sensitivity, but Visual Studio has not yet returned to the
usability of VC++ version 6 help – at least in the opinion of many users…
Eclipse is another “mega-IDE”,
which unfortunately for C++ programmers, has a Java “slant” –
the most annoying examples being the project file system restrictions and the
lack of build configurations. It exposes new concepts that probably would
not be necessary if it were a C++ only IDE. However, I’ll take a
highly extensible, multi-platform, mega-IDE over a non-extensible, C++ only
IDE. Actually I know nothing about Qt Creator and am just assuming it is
non-extensible – e.g. the ability to plug in widely varying new C++ tools
without convincing the providers of the IDE to do it themselves.
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Friday, December 11, 2009
4:22 PM
To: CDT
General developers list.
Subject: Re: [cdt-dev] CDT and Qt
Creator
Thanks, Mike. The indexer is truly our biggest asset and one of things
I'm most proud of for our community. I use the CDT for some small projects at
work and for playing with the Android native development kit and I'm always
pleasantly surprised when it works as often as it does even for platforms we
never thought of when building it (like Android).
BTW, I ran Eclipse on my Dell Mini 10v and it ran fine, other than the
tiny screen. And it's just a Atom chip with 1G RAM.
As for OS X, that's really up to the community to support. Right now, I
don't think any of the vendors contributing to the CDT support Mac for their
products, thus the weaker support. If I had a Mac, I would be inclined to make
it work better there, but I don't.
And, yeah, if your IDE doesn't do as much, it will be simpler.
Doug.
On Fri, Dec 11, 2009 at 7:04 PM, Michael Jackson <mike.jackson@xxxxxxxxxxxxxx>
wrote:
As a User....
I'll vote for the indexer (with a caveat). The
indexer is basically the main reason I use Eclipse rather than Visual Studio*
or Xcode**, which are my two main platforms. 99% of the time the indexer has
the proper variable, template, method, class in its cache to make intelligent
selections. QtCreator's indexer is,well, not "there" yet.
The "Code Templates", the ones where I can
type "sout" and have that expanded inline to std::cout <<
"" << std::endl; are absolutely WONDERFUL. QtCreator does not
have these.
Caveats: With boost versions greater that 1.36 the indexer has a problem with
shared_ptr.hpp. Not really sure what is going on but by code stopping being
indexed completely when I switch versions of Boost from 1.36 to anything
higher. No idea what the problem is but it generally sucks. I actually keep
boost 1.36 around just for the indexer to use so I can get code completion.
Visual Assist X for Visual Studio (while costing money) does NOT seem to have
the problem with newer versions of boost, but then again, you are paying money
for it. Visual Studio without Visual Assist X is just a lost cause for C++
programming and code completion. Xcode for C++ is about the same type of joke.
Eclipse is Big and Bulky and you need a hulking huge machine to run it.
(Xeon 5500 with 12 GB of Ram here). I use CMake to generate makefiles, and then
manually setup the "Makefile" project in eclipse. I tell git to
ignore the .cproject and .project file in the top level of my source tree. _I_
didn't find CDT too bad to start out with but then again I was doing pretty
vanilla C++ programming. '
Lately, CDT has taken a turn for the worse on OS X. Two major bugs in
debugging are forcing me over to the Visual Studio camp so I can effectively
debug my software. This only effects OS X/CDT so the number of programmers
actually impacted by the bugs are probably pretty small but it still sucks if
you are one of those impacted.
I have tried QtCreator with each new release but it just does not have
some of the conveniences that CDT has so I give it up and wait for the next
iteration. Eventually it might catch up, but it will be a very long while.
I would venture to say that QtCreator is great for Beginners while CDT
is great for those like me who need more control over their projects, assuming
you can live with in the confines of Eclipse.
Thanks for listening.
_________________________________________________________
Mike Jackson mike.jackson@xxxxxxxxxxxxxx
BlueQuartz Software
www.bluequartz.net
Principal Software Engineer
Dayton, Ohio
On Dec 11, 2009, at 6:44 PM, Adrian Taylor 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
|