|Re: [cdt-dev] Call for Input For CDT Fall Conference: CDT Usability|
Hello Martin,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.
Regards Matthias Imrisek, Martin wrote:
All,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 workflows? o Project create/import/build o Launch and debug workflows o etc. * Debug views features * Debug views behaviour * MBS * 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 used) * Any other areaSince 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. :^) Regards, Martin-- Martin Imrisek Software Systems Designer Texas Instruments 416-340-2096------------------------------------------------------------------------ _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev
Back to the top