Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-patch] Usability feedback; please add new file 
The new file is attached.

Thanks,

Jeremy

Jeremy Handcock wrote:
As discussed on cdt-test-dev, I have some CDT usability feedback from a fellow Hatter that I'm adding as a supplement to the test plan. Please add this as a new file under /home/tools/cdt-home/developer/usability_feedback.html
Title: CDT Informal Usability Study
CDT Informal Usability Study
Study results
Author : Bertina Lee, compiled by Jeremy Handcock
Revision Date : 08/27/2003 - Version: 0.1.0
Change History : 0.1.0 - Document Creation

Table of Contents

1. Introduction
2. Results
2.1 High Points
2.2 Pitfalls


1. Introduction

This document is the result of feedback obtained from an application developer's experiences in using CDT 1.1. Bertina Lee used the CDT to develop a non-trivial C++ application in which MIDI files are parsed and converted to sheet music format. Her feedback on CDT usability is offered as an informal study of both the major high points and the pitfalls of using the CDT for application development within the Eclipse framework.

It should be noted that this study was done using CDT 1.1. Some of the points below have been addressed as of the most recent development version, and comments of that nature have been added for clarification.

2. Results

2.1 High Points

Area/Functionality Comments
Build on Save Option to build on save and ability to turn this functionality on/off is nice.
Perspective concept The CDT takes good advantage of the "perspective" concept that Eclipse uses. Toggling between perspectives while coding allows one to quickly switch between a set of editing-related windows/views to a different set of debugging-related windows/views. Also, the ability to customize and save perspectives is extremely useful.
Debugger The debug perspective is very intuitive and extremely easy for a new user to work with.
Outline View A very useful tool. "Search for references" functionality is particularly useful when changing function parameters and doing refactoring.
Import/Export Wizards Intuitive and easy to pick up.
Non-default Build Command Being able to specify a non-default build command is nice. However, there are some limitations - see pitfalls below for details.

2.2 Pitfalls

Area/Functionality Comments Related Defects
Task Tags No support for automatic TODO or FIXME task tags as in the JDT.
Build Abortion There isn't currently a functioning method of aborting a build once it has been started. [41752]
Search/Replace Search/Replace functionality currently does not support a tab delimiter.
Makefile Reliance CDT 1.1: Unlike some other IDEs, the CDT component of Eclipse requires a Makefile in order to build a project. No standard Makefile templates are given, so you have to learn how to write a Makefile in order to use the CDT. Additionally, with the exception of editing it by hand, there is no way to update an existing Makefile within the CDT.

NOTE: This is currently being addressed in development versions of the CDT with the Managed Make Builder.
Code Completion CDT 1.1: No support for automatic code completion as in the JDT.

NOTE: Code completion functionality is currently in development.
Non-default Build Commands Non-default build commands are not handled well. Non-default build commands are assumed to be targeted build tools with 'clean' and 'all' targets. [25979]
Refactoring Currently no formal refactoring support as in the JDT.
Icons No reference for the toolbar icons, etc. is available. Perhaps a reference key should be available for users in the documentation with a clear explanation of the icon's meaning.

Last Modified on Wednesday, August 27, 2003

Back to the top