[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] Call for Input For CDT Fall Conference: CDT Usability
- From: Matthias Spycher <matthias@xxxxxxxxxx>
- Date: Wed, 12 Oct 2005 15:53:34 -0700
- Delivered-to: email@example.com
- User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Here some feedback/issues raised by CDT users in our field. They use the
CDT and C++ for system modelling and simulation.
- The MBS boosts productivity and leaves a very good first impression.
Most of our users don't want to deal with makefiles directly. On closer
inspection, users find that entries in the problems view are out of
order or mistakenly flagged as errors when compared with the output in
the build console. Sometimes they cannot launch a simulation because of
such spurious entries. Although not directly related to the MBS, error
parsing needs some work.
- Users often accidentally expand binaries in the C/C++ projects view.
Most users are not interested in seeing the elf symbols and would like
to see a preference that turns this feature off by default. Others would
like to see header and implementation files listed in pairs, i.e. a
different sort order.
- Users working on large projects tend to disable indexing because of
performance considerations. Others will use eclipse/CDT only for
browsing and debugging, preferring to edit with vi/emacs and build with
make on the cli.
- Some users find there are too many options for project management (C
and C++ projects could be combined).
- Handling of external files is confusing for most users. For example,
you can set a breakpoint in a file that was enumerated in an include
path under the Includes container. The breakpoint will show in the
breakpoints view, but the debugger won't honor it unless the
corresponding directory (include path) is added to the project as a
linked resource or added to the launch configuration in the source
lookup tab. If you have a managed project and you decide to link in a
directory, you may need to exclude (one by one via the properties
dialog) certain files (*.cpp) from accidentally being built.
In general, users run up against "unexpected behavior" because they're
not aware of the eclipse plugin architecture and how it forces a
delineation of the features available in a product like the CDT. So, for
example, launch configurations are very loosely coupled to projects.
This is excellent for developers, but can sometimes confuse users who
expect tighter integration.
Users who compare the CDT to a product like Visual Studio will often
complain about the lack of integration between the IDE and the
underlying tools (e.g. population of the problems view). But then they
also fail to recognize the fact that the CDT doesn't dictate a
particular tool chain.
Imrisek, Martin wrote:
For the CDT Developers Conference I am putting together a presentation
on the CDT End User Experience. Although this session was orignally
motivated by our experiences with CDT as end users migrating from
MSVC6 I would like to gather up as much feedback and comments as
possible from a wide audience of CDT users and ISVs for this discussion.
Send me your comments on end user likes/dislikes from your or your
customers experiences on any the following areas:
* What do you/your users find effective/not effective in various
o Project create/import/build
o Launch and debug workflows
* Debug views features
* Debug views behaviour
* Large project development and debug (I'd really like to know the
size of typical projects as well as the largest for which CDT is
* Any other area
Since CDT is both a product platform for ISVs as well as a complete
C/C++ development environment on several hosts I am very interested in
getting perspectives from host side C/C++ application developers as
well as users of embedded tools based on the CDT.
Comparisons to your favourite IDE are welcome whether it be Emacs or
MSVC or whatever are welcome. :^)
Software Systems Designer
cdt-dev mailing list