Home » Language IDEs » C / C++ IDE (CDT) » Call for Input For CDT Fall Conference: CDT Usability
| Call for Input For CDT Fall Conference: CDT Usability [message #156036] |
Tue, 11 October 2005 21:19  |
Eclipse User |
|
|
|
Originally posted by: ""m_imrisek\".yahoo. com"
For the CDT Developers Conference I am putting together a presentation
on the CDT End User Experience for which I would like to get feedback
from the CDT user community.
I would like to get 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
work flows?
o Project create/import/build
o Launch and debug work flows
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 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. :^)
Regards,
Martin
--
Martin Imrisek
Software Systems Designer
Texas Instruments
|
|
| | |
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156093 is a reply to message #156036] |
Wed, 12 October 2005 17:22  |
| Eclipse User |
|
|
|
Originally posted by: wesjanik.yahoo.com
I find the indexing/completion code to be perhaps the most useful feature
CDT has to offer. To me, this is the most important feature that sets a
good IDE apart from a color-coded text editor coupled with other tools. I
would like to see more work in this area on more robust features. A more
fluid method of navigating to method bodies, and better handling of code
completion are a couple examples. I think JDT provides some good examples
of how to better handle code completion. In JDT, when code completion is
used to invoke a method on an object instance, the IDE is smart enough to
add both parentheses. If, however, developers add the closing parenthesis
to the method themselves, the IDE is again smart enough to not duplicate
the effort. This allows the developer to continue writing the code
without having to stop to arrow over the bits code completion has added
for them. Additionally, parenthesis, periods, and other delimiters should
select a highlighted function, variable, etc. instead of requiring the
developer to press enter. Essentially, these features allow the developer
to write code more quickly than they can type by freeing them from the
need to type whole words or add certain syntax elements that can be
anticipated by the IDE.
The integration of the debugger is second on my list of most useful
features. Mostly, I would like to see better handling of variable
introspection. For example (and I may not be using something correctly
here), parameters passed as references show up as memory locations and not
values. This is only mildly helpful.
Code formatting comes in third on the list. While there is some handling
of indents, it is pretty primitive. Automatically aligning/formatting
blocks of code (as is done in JDT) would make writing easily
readable/maintainable code a lot easier.
|
|
| | |
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156173 is a reply to message #156036] |
Thu, 13 October 2005 14:08 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.dharty.com
One of the biggest problems I face in using eclipse is within its
project management. Most of this lies in the poorly designed
application(s) I'm working with. All of them have all of their source
in a common directory, eg projectdir/source.
In the past (currently as well), developers used multiple MSVC projects
(stored in /projectdir/projects) to group individual source files out of
the bunch into individual applications. Each application had different
properties (source files, defines, include paths) and many used
different compilers. The applications have some unique source files,
but also share many.
So far the way I tried to emulate this functionality in two ways:
1: Create a single project in "projectdir" and set the defines and
include paths more my most commonly used project. Then specifically
EXCLUDE all of the files not needed for this project. With over 600
files in the tree, this is quite a task. This solves most of the indexer
errors, but the project is really only indexed for one of the many
projects. Then I create a workingset for all of the different projects.
However, because I had to exclude many files to get the indexer to
work with a particular set of defines, only the "core" project's working
set has all of the source files defined as source and properly indexed.
Make targets are used to specify the compiler and necessary targets,
sometimes the "compiler" is a batch file with more detailed directions.
2: The second approach I have taken has been to create a workspace in
projectdir, and create mutliple projects under the projects directory,
one for each project. Then I add an externally linked folder back to
the source directory. This has several advantages because now I can set
the correct defines and includes separately for each project as well as
exclude from the projects all files that that project does not use. The
downside is that the externally linked folders are absolutely linked,
thus making the projects difficult to use in a revision control system
unless everyone uses the same directory structure, and even then each
developer would be limited to one checkout per machine. To semi-solve
this, I have created a "PROJECT_ROOT" pathvariable that points to the
projectdir and all source folders are relative to that. This still
means a developer using a different folder layout will have to modify
that setting before working on the projects. Finally, the indexer
doesn't seem to work well when using externally linked folders. The IDE
can find declarations, but not definitions. One alternative to this I
tried was to add all of the projects source files as individually linked
external source files. Again, the indexer couldn't handle this and the
fact that they were source files was partially hidden by the "shortcut"
icon covering the source icon. To make matters worse, I couldn't add
linked source files to a subfolder of the project so all of the
externally linked source files had to reside in the root of the project
which broke what little file hierarchy we had.
Method 2 is the optimal solution I have found so far, but the linker
issues pushed me back to working in method 1. The revision control
issue is a pain, but can be managed.
What I think would really be helpful, for both managed and standard make
projects, would first to be able to create multiple projects in the same
directory, and then secondly (and perhaps more importantly) select
individual files (perhaps limited to within the workspace?) to add to
the project. Heres a rough hierarchy
/workspacedir
/.metadata
/projects
/project1.cdt ("contains" project1 files in source)
/project2.cdt
/project3.cdt
/source
/project1.c
/project2.c
/project3.c
/sharedByProjects1And2.c
/alsoSharedByProjects1And2.c
/sharedByProjects2And3.c
/sharedByProjects1And3.c
with perhaps the addition of a project for the sole purpose of "bringing
in external source files to be available to the projects:
/workspacedir
/.metadata
/projects
/project1/.*project
/project2/.*project
/project3/.*project
/source
/project1.c
/project2.c
/project3.c
/sharedByProjects1And2.c
/alsoSharedByProjects1And2.c
/sharedByProjects2And3.c
/sharedByProjects1And3.c
/externallylinkedproject/.*project
/linkToSourceTreeExternalToWorkspace
/alsoUsedByProject1.c
/alsoUsedByProjects1and2.c
/alsoUsedByProject2.c
Thanks,
David
m. imrisek > wrote:
>
>
> For the CDT Developers Conference I am putting together a presentation
> on the CDT End User Experience for which I would like to get feedback
> from the CDT user community.
>
>
> I would like to get 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
> work flows?
> o Project create/import/build
> o Launch and debug work flows
> 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 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. :^)
>
> Regards,
>
> Martin
>
> --
> Martin Imrisek
> Software Systems Designer
> Texas Instruments
>
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156188 is a reply to message #156173] |
Thu, 13 October 2005 19:44 |
| Eclipse User |
|
|
|
David H wrote:
> One of the biggest problems I face in using eclipse is within its
> project management. Most of this lies in the poorly designed
> application(s) I'm working with. All of them have all of their source
> in a common directory, eg projectdir/source.
>
> In the past (currently as well), developers used multiple MSVC projects
> (stored in /projectdir/projects) to group individual source files out of
> the bunch into individual applications. Each application had different
> properties (source files, defines, include paths) and many used
> different compilers. The applications have some unique source files,
> but also share many.
>
> So far the way I tried to emulate this functionality in two ways:
Second that. In our case, it's a Linux project, but with a similar
structure. In general, I'd like to see more flexibility in how Eclipse
manages projects and the assumptions it makes about code may be organized.
Particularly:
* Multiple projects in a common directory.
* Projects that refer to other projects in an external directory.
* Autoconf projects - lots of issues here, but lots of real-world
examples to experiment with.
* Projects that use shadow directories or link trees.
|
|
| | |
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156231 is a reply to message #156036] |
Fri, 14 October 2005 13:21 |
| Eclipse User |
|
|
|
I currently have been trying to use CDT with a rather large win32 project
with lots of MFC. I have tried the indexer and it picks up quite a bit,
however, for a project with hundreds of files, it would be nice to have
the indexer persist it's work between eclipse sessions--it takes about 2
hours to fully index this project!
I have been working on smaller projects with eclipse and I've found it to
work really well. The MBS seems to be generic enough to allow for some
pretty neat plugins to it (I am using SConsBuilder which has been great
for the most part).
The indexer has been really helpful for these smaller projects, although
at times slow and other times gives as been incorrect.
Two examples of how it has been incorrect:
I have noticed that when I have a class with member functions defined in
the header (.h) any references to (*this) or to an instance of the class
itself (such as a copy constructor or assignment operator) autocomplete
incorrectly. All they show is the green circle Class icon and the name of
the class. Member variables that I try to autocomplete to see what
function they have show the arguments to that function as autocomplete
options.
I have had functions with the same name in different classes in one of our
large projects. The indexer goes to declarations fine but in going to the
definition from one of the declarations it would always pick the member
function of the other class with the same name. Sorry I don't have more
details on this.
One other nitpicky thing is the Find/Replace dialog. It doesn't let you do
match across line boundaries. This isn't CDT specific but just something
that I think about whenever I use the find replace box.
Sometimes having a single tool do something extremely well just makes me
look forward to using that product. For instance Dreamweaver MX 2004's
find/replace box is so nice that I often use dreamweaver for this ability
alone (it allows you perform changes on folders, sites, and when you do
multiple file find/replaces it shows you all the changes that it made in a
view at the bottom of the IDE so you know what it matched). I'm not
saying Eclipse and especially CDT needs that kind of find/replace, but in
general having a tool or feature in an IDE that is so robust and useful
often makes user overlook shortcomings in another area. Eclipse's
synchronization tool is an example of such a tool. I worked on an OS
project with a group and even though I couldn't use (or didn't know how to
use) much of Eclipse's CDT stuff for the project, I did know that it has
very robust team synchronization abilities and we used it simply for that.
And that was back before a lot of the code indexing abilities were there.
In other words, focusing efforts on debugging is good and all, but
honestly I think solidifying the IDE for developing code should be first
priority, and will help others to put it to use for existing projects.
CDT has its work cut out for it--It has a lot to take on for the myriad
C/C++ projects in existance and for it to try and play nice with them. If
it can do that effectively I believe that will help others to enter into
the Eclipse door--full featured debugging can be forgiven for now as long
as they have an IDE alternative for doing their coding in, which in my
case was an alternative for Visual Studio 6/7 (blech!).
Good job with what has been done, CDT is truly getting there as far as a
robust C/C++ IDE.
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156236 is a reply to message #156204] |
Fri, 14 October 2005 14:24 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.dharty.com
> * Macro Recording / Playing
Agreed, Textpad has been my favorite windows text editor for many
years, partially because of this feature.
> * Block (Column) select / copy
Also a great feature of textpad (and others I'm sure). This can also
allows you to select a block and alt-tab or tab to bring end of line
items (eg comments or equals) into alignment
before block select
sBadRxPkt[chan].sCtr.SEARCH, // comment
sBadRxPkt[chan].sCtr.SEARCH_STATE, // comment
sBadRxPkt[chan].sCtr.lHDRCHK_STATEINGY, // comment
sBadRxPkt[chan].sCtr.lCRC2_STATE // comment
after block select
sBadRxPkt[chan].sCtr.SEARCH, // comment
sBadRxPkt[chan].sCtr.SEARCH_STATE, // comment
sBadRxPkt[chan].sCtr.lHDRCHK_STATEINGY, // comment
sBadRxPkt[chan].sCtr.lCRC2_STATE // comment
> Different color (Ex. grey) for codes that will not be compiled such as
> between #if 0 end #endif like
Or Howabout #ifdef folding too?
+#if defined (IDONTCAREABOUTTHISSECTION) (..)
// if block folded
-#if defined (ICAREABOUTTHISSECTION)
this.isCodeBeingUsedInThisBuild();
#endif // ICAREABOUTTHISSECTION
The C++ editor preferences lists macro folding as an option, but I've
never seen it work.
David
Burak wrote:
> I also have several comments.
>
> I really appreciate people working on CDT. That's my favourite ide for
> months. Here are my additional improvement suggestions about the editor.
>
> * Macro Recording / Playing
> * Block (Column) select / copy
> * Different color (Ex. grey) for codes that will not be compiled such as
> between #if 0 end #endif like
> * Artistics Style or another basic code style integration
>
> "Yug3sh" <yug3sh@yahoo.com> wrote in message
> news:dine22$26n$1@news.eclipse.org...
>
>>Things I find most useful about CDT:
>>
>>1. The indexer is invaluable. This is the primary reason I use CDT.
>>2. Output parsers and the ability to build my project from within the IDE
>>and reflect the errors back in the IDE.
>>
>>Things I would like to see improved / added:
>>
>>1. Better refactoring support. Refactoring in CDT is extremely weak right
>>now. Whatever refactoring support there is currently isn't very polished
>>(e.g. refactoring / renaming a variable marked static will rename all
>>other occurances outside of the file as well).
>>2. I'd like to see better toolchain support. Right now I use openwatcom
>>1.3 and its not fully / properly supported in eclipse. The Error parser is
>>partially functional (only some errors are flagged after a build and are
>>reflected in the IDE).
>>3. Integration of something like lint / splint would be nice. Realtime
>>analysis / parsing of code and flagging would really make it slick.
>>
>>
>>
>>"m. imrisek" <""m_imrisek\"@yahoo. com"> wrote in message
>>news:dihoae$3j1$2@news.eclipse.org...
>>
>>>
>>>For the CDT Developers Conference I am putting together a presentation on
>>>the CDT End User Experience for which I would like to get feedback from
>>>the CDT user community.
>>>
>>>
>>>I would like to get 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 work
>>>flows?
>>> o Project create/import/build
>>> o Launch and debug work flows
>>> 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 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. :^)
>>>
>>>Regards,
>>>
>>>Martin
>>>
>>>--
>>>Martin Imrisek
>>>Software Systems Designer
>>>Texas Instruments
>>>
>>
>>
>
>
|
|
| |
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156259 is a reply to message #156036] |
Sat, 15 October 2005 12:50 |
| Eclipse User |
|
|
|
Project Management:
* CDT needs more development emphasis on large, real-world projects with
thousands of files and millions of lines of code.
* CDT/Eclipse falls on its face when trying to deal with autoconf-based
projects, projects that include files of the same name (but in different
directories) or projects that include sub-projects.
* Indexing would be a wonderful feature, but it is completely unusable
on large projects (indexing takes 2 hours to complete on one of our
"smaller" projects and we don't use it at all on the others).
* A good place to start looking at these issues would be with some of
the many popular, large open-source projects such as the Linux kernel,
Apache web server or the glibc library itself.
* I honestly don't understand the value of Managed Projects except maybe
for educational or tutorial purposes. Real-world projects are likely to
autoconf-based or have complex makefile requirements far beyond what MP
can provide.
Editing/Authoring:
* The text editors need additional features to make them comparable to
popular code-editors like MSVC, EMACs, CodeWright and others. I know
this isn't a CDT specific issue, but it is one of the major complaints I
get against Eclipse. Things like drag & drop editing, sorting,
column-select, etc.
* As I mentioned before, indexing would be a great feature, but in its
current state, it is unusable on real-world projects. It is too slow and
dependent compiler output. I've tried generating my own CTags file, but
I can not seem to determine what magic set of parameters to CTags to
produce a file that Eclipse likes.
* Again, not really CDT issue, but lack of easily-configurable toolbars
(ala MSVC) and other such features in Workbench affect CDT usability and
adoption.
* Recognize more file types as source files - such as *.in files
(Makefile.in, configure.in, etc.), shell scripts with no .sh extension.
* Code-completion is very buggy and prone to getting confused or not
offering any suggestions at all.
* Hover operations frequently show empty boxes, "////...", "***..." or
other useless information picked up from comments.
* The configuration dialogs need to be more informative about how to
make these features work. Need more customization capability to tailor
these features to particular project characteristics.
* The editor & indexer functions need to understand #defines and #ifdefs.
Compiling/Building:
* Output parser still does not seem to understand standard GCC warnings
& errors. Warnings get flagged as errors. Error messages that span
multiple lines get separated in the Problems view and you can't resort
them back to order in which they appeared.
* Output parser gets confused if two files in the project have the same
name ("conflicting names") and problems view doesn't work & errors don't
get tagged in the editor. This is a very common occurrence in large
projects.
* Long delays after compile finishes to parse output. This needs to
happen as the build is running.
* Reliance on compiler/build output needs to be eliminated altogether.
Many makefiles hide the compiler command in the output (i.e. Linux
kernel and others).
* Binary parser needs to be more configurable for heterogeneous
processor environments - need to ability to specify which binaries to
parse or not.
* Support for remote build servers. In some projects, I use Eclipse
running on Windows, but builds need happen on a remote Linux server. To
do this, I replace the standard make command with and rsh-like script.
This works pretty well, but Eclipse/CDT just needs to understand that
just because I am running the IDE on Windows doesn't mean that I am
running the build on Windows or that I am building code FOR Windows.
Debugging:
* In general, I have found debugging to work pretty well.
* In looking at the gdb commands, I do notice that Eclipse sends an
environment setting for each directory in the project - this causes
delays in launching for large projects and seems unnecessary since
enough information to find the source is already available.
* It would be nice if CDT had some features to help with multi-threaded
debugging.
* More GUI configuration of debugger profiles would be nice too -
setting up signal-handling, etc.
General:
* I'm not exactly a fan of MSVC, especially the most recent versions,
but in comparison Eclipse/CDT still has a ways to go before it could be
considered an equivalent in terms of customizability of the GUI, bugs,
editor functionality and speed. Great strides are being made with each
new release though.
* ISV products derived from Eclipse are, without exception from what I
have seen so far, *AWFUL*. Take an outdated, buggy version of Eclipse,
slap on a bunch of ill-conceived and poorly-designed plug-ins and then
try to use this mess to lock customers in to your value-subtracted
"solution". No thanks. We've had much better luck building our own
toolchains and keeping current with the latest releases of standard
Eclipse/CDT.
Eclipse/CDT is one of the best things to happen in the Embedded an
Open-Source development worlds in a long-time. I really appreciate all
of the hard work the developers have put into it so far and my team is
anxiously looking forward to new and improved releases in the future.
Keep up the good work!
Thanks
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156266 is a reply to message #156188] |
Sat, 15 October 2005 14:46 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.rocketcomp.com.au
Keath Milligan wrote:
> David H wrote:
>
>> One of the biggest problems I face in using eclipse is within its
>> project management. Most of this lies in the poorly designed
>> application(s) I'm working with. All of them have all of their source
>> in a common directory, eg projectdir/source.
>>
>> In the past (currently as well), developers used multiple MSVC
>> projects (stored in /projectdir/projects) to group individual source
>> files out of the bunch into individual applications. Each application
>> had different properties (source files, defines, include paths) and
>> many used different compilers. The applications have some unique
>> source files, but also share many.
>>
>> So far the way I tried to emulate this functionality in two ways:
>
>
> Second that. In our case, it's a Linux project, but with a similar
> structure. In general, I'd like to see more flexibility in how Eclipse
> manages projects and the assumptions it makes about code may be organized.
>
> Particularly:
>
> * Multiple projects in a common directory.
> * Projects that refer to other projects in an external directory.
> * Autoconf projects - lots of issues here, but lots of real-world
> examples to experiment with.
> * Projects that use shadow directories or link trees.
When you include a source file in a project, eclipse seems to want to physically
include the file rather than just a link to the file.
This creates problems when using the same source files for msvc and cdt as the
directory gets cluttered up with .meta files etc
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156425 is a reply to message #156036] |
Mon, 17 October 2005 10:04 |
| Eclipse User |
|
|
|
I can comment on one ISV product. We have been using MontaVista DevRocket
for about a year and a half, lately at version 1.1. It is based on
Eclipse 2.1, CDT 1.1. We have two embedded application projects in C++,
each of about 600 files. We cross-develop on Windows with an embedded
target of ARM PXA270 (iwmmxt_le).
We have given up using DevRocket for most purposes. We use it to maintain
only the main makefile of each project and run the debugger. We have
built our own tool to make a header dependencies file, which DevRocket
doesn't. The only dependencies DevRocket builds are of the form .cpp ->
o and .o -> link.
We use Microsoft Visual Studio for editing, browsing, and building our
large projects.
DevRocket is somewhat capable of handling smaller projects. We have one
shared library, a .so file (13 source files excluding system headers)
which we build under DevRocket, only because a complete rebuild is fast
enough in this small case.
The debugger leaves a *lot* to be desired. It can't step into or break in
a shared library. It does not allow you to add a break point during
execution. And the program often crashes or hangs without the debugger
noticing. In many cases, we are reduced to debugging by printf.
For editing, while Visual Studio's MDI (multiple document interface) has
some real annoyances, it's much better than the rigidly paned and docked
behavior of DevRocket. The column-select ability of Studio is also a big
plus. And, Studio gives us at least minimal browsing ability, with
one-click support to go to the definition of a name. In DevRocket, the
very poor, slow substitute is incessant searching of the entire project
with hits on comments and longer names that include the one you want,
which makes searching unusable for many short names.
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156458 is a reply to message #156425] |
Tue, 18 October 2005 15:27 |
| Eclipse User |
|
|
|
I whole heartedly agree with the previous sentiments. Large project
support and performant indexing is critical to making CDT more widely
viable. Managed make is great, but I would prefer if the output were a
single Makefile at the root level of the project. If I want to use managed
make, then I can't really share my project w/ someone who doesn't use
Eclipse. Refactoring is another "big" area that could benefit from some
focus.
Additionally, I still think there could be some improvements that are
perhaps smaller, but would make the job of just writing code easier:
- A myriad of improvements to the editor
1. Intelligent brace support: i.e. if auto complete adds braces or brackes,
and I type them, only one pair should remain.
2. Ability to auto insert closing bracket (w/ semi colon if needed)
3. Better word selection. If I ctrl-arrow along a line, the current support
is pretty basic. I wanna be able to get to the end of a word, not the
start of the next (among other things)
4. Rectangular selection, cut/copy/paste support.
5. Join lines action in the editor. Like shift j in VI (this should
intelligently remove comment characters if they are not needed)
6. Code folding (comments, includes, code blocks, etc)
- Multiple types of auto completion
Right now, the code templates completion is useful, but I would also like
to be able to specify short aliases for expansion. E.g. dnl becomes !=
NULL).
Yeah, I can do this as a code template but I don't want to have to hit
ctrl-space to expand. I'd like to bind my aliases to space.
See Intellij for great support for templates, expansions and code assist.
In that IDE, you can bind different expansions or code assist to different
hot keys.
- Console pops up on error
With auto build on, the console is constantly churning, so I code with it
minimized. However, I would like it, or the Problems tab, to pop up when
there is actually an error. This may not actually be a CDT issue, I'm not
sure.
- Improved debugging support
Often during a debug session I'll hover the cursor over a variable and
just get an address in the tooltip. What I really want is to see the value.
Also, the variable display for String could do with a lot of improvement.
In the same way that I can chose to display the STL components as an
array, I wanna chose to display just the actual chars of the string, not
all the rest of the crap. This could be an option in the context menu:
Display String Value.
This also applies to the on-hover part. I won't need to see all the
extraneuous stuff (unless I want to), just the string value.
I would also like to see the Run to line icon on the debugger toolbar. I
know, I'm wierd, but I don't like it on the context menu ;)
- Auto indenting
Indenting support can save me lots of time in a day. I should be able to
paste in lines and have them auto indented. I know I can reformat the page
after the fact, but having it done as I type will save me time.
- Add shift-click hover action
Right now, ctrl-click goes to the declaration. I can right click and chose
goto implementation to get to the actual code, but it would be cool if I
could specify a hotkey to do this. E.g. shift-click goes to impl, and
ctrl-click to class def.
- // Comment style also should wrap if Enter is hit
I know the /* version of the comment will wrap if you hit enter and
continue
until you finish the comment block. I want the same support for //.
- Split screen editor support
I would really like to be able to view two parts of the same file at the
same time. Most editors support split screen view of the same file.
Additionally, I would like to be able to view two files side by side.
- Macro support
This is probably not a CDT issue, rather an Eclipse one, but I really
would like to be able to record macros and replay them based on a hot key.
- Simplified code assist pop up
The code assist pop up can be confusing sometimes. Take a look at the
CodeBlocks popup for a good example. For example, I don't just want it
sorted in alphabetical order, by visibility or method/field would be very
useful.
On the whole, I find CDT a very useful IDE. I have been using it
exclusively for doing my C++ development. I do find the editor component a
little rough compared to my other editors. I predominantly use Intellj for
work, and jEdit for everything else. IJ is a great example of how to make
life easy for a programmer. jEdit has the best text editor component out
there. A lot can be learned from both of these programs. While the larger
issues are obviously important, ironing out the niggles in the editor
component would go a long way to making life easier. I just want to reduce
the amount of time I spend using the delete, tab (indent), end, home, etc,
keys!
Todd
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156617 is a reply to message #156036] |
Fri, 21 October 2005 15:09 |
| Eclipse User |
|
|
|
I posted my CDT Usability response to the e-mail group, which apparently
doesn't receive as much action as this newsgroup (that I only discovered
today!) My response was the only one I saw on the e-mail group!
Quick comment about many of the responses I've seen on the newsgroup -
the request was for experiences with "CDT Usability", not a request for
your wish-list of features. One could argue that your usability of
something is based on its feature set, but I would argue that
slapping-on more and more features doesn't address problems inherent to
the overall design, architecture, and flow of the CDT and Eclipse as a
whole. Adding more fancy features and making everything more complex
could decrease overall "usability" of the "package" for a future new
user if aspects of the *basics* aren't improved first.
On that note, my response is below:
----------------------------
Martin & group,
I'm a newbie to Eclipse, and I think I have a lot of comments and input
based on my first experience. Unfortunately, I think there are too many
to list. Also, I think most of them are attributed to my lack of
knowledge of GCC, Unix style shells, command line compiling, Java,
makefiles, and all of the other things that aren't found in any
Windows-based IDE's that I've used. I have to believe there are many
more developers out there with a background similar to mine.
Overall, I'm very excited about the idea of Eclipse. I'm using it right
now to customize the CDT to use our custom toolchain and debug tools, so
we can leverage off of all the other powerful Eclipse IDE plug-ins.
Then we can concentrate on the nuts and bolts of our platform rather
than a formatter, editor, project manager, etc.
Instead of having me type a laundry list of specific comments, I'll try
to concentrate on my overall impressions, and how I see Eclipse gaining
"market share" and support. So let's all take a step back - what I see
is that there are at least two different mindsets when it comes to
developing software:
The first is "mine" - double-click an icon to open your IDE, write your
code, click the "compile" button, and you've got a piece of software you
can sell to Joe Shmoe User.
The second is "yours" (not meant to be insulting, but in general, this
is my impression of all the developers in the *-nix and open-source
world) - install Linux or a bash shell, spend hours and hours
configuring your environment, read a ton of man pages, use a text editor
like vi to write the code, create a makefile, learn Perl for the heck of
it, build the project, discover a bug in the compiler, create a patch,
figure out how to use CVS, submit the patch to the open source
community, re-compile, and finally you've got a piece of software you
can only give away to other developers exactly like yourself (it's way
too complicated for Joe Shmoe User to even attempt to use). And you
also only give away the source and binaries for *-nix, not Windows. On
top of all that, there's a completely different lingo/language of words
and acronyms used that nobody but yourselves can understand.
To illustrate it another way, there are the people who read slashdot
regularly, and there are people who can't understand 2 words of what's
on slashdot.
My general impression of Eclipse is that all you've done is strapped a
GUI on the second mentality that I described above. Out of the box,
Eclipse takes weeks to figure-out for a Microsoft-molded developer like
me. People like me have had their hands held by pretty user friendly
GUIs that hide all the big-bad details. This is where I feel Eclipse is
not getting the support and following that it could be getting. It's
not something "most" developers understand or have the patience to spend
weeks figuring out. Just look at the world in general - why does the
vast majority of the population use Windows rather than Linux?
BTW - everyone that I've talked to in "my world" ever since I started
looking at Eclipse hadn't even heard of it.
Prior to trying to use Eclipse, for example, I had never heard of the
following things, just to name a few: Build-file Generator, Dependency
Calculator, Ant, Refactor, Working Set, Launcher, Make Target, Binary
Parser, Error Parser, Project References, CVS, C/C++ Indexer, Artifact.
I had heard of makefiles before, but up until a month ago, I had never
seen one. Other IDEs don't use/reference all this stuff and it's
enough to scare users of those IDEs away from Eclipse. I know there are
a lot of developers like me out there - I'd say that 95% of my developer
friends, co-workers, customers, etc. are like me. I'm sure that 95% of
your acquaintances are like you. So - how can we merge the two worlds??
I'm not going to try answering that question here and now, but hopefully
it's food for thought. That's what I believe Eclipse is up against.
Just in case at this point you're thinking: "who is this noob? he's
probably a lousy coder! I'm embarrassed to hear that he calls himself a
developer!", in my defense, I have a recent MSE from a top 5 university
and aced my programming classes. When it comes to understanding "your
world", I'll admit, I suck. I've never had a reason to enter your
world until now.
I do have some comments that come to mind regarding the CDT Usability.
** Embedded/Remote Targets - I'm currently in the embedded
tools/products market, and it's clear that Eclipse is tailored for host
side apps.
** Documentation - I have diligently read most of the documentation for
Workbench, PDE, CDT, & CDT Plug-in Dev *twice*, and in general, I'm
still lost. It assumes a lot of background knowledge from "your
world".
** Specifications - I recently read a post where someone asked if there
was a spec for the CDI and the response was along the lines of, "no -
you have look at the source for how gdb is implemented". This just
*baffles* my mind. How can a group of distributed developers create a
generic API that is intended to be applied to any & all current & future
debuggers *without* a spec? Maybe there is just some magic concept of
open-source development that I don't understand. Or maybe this is part
of the reason why it isn't easy to integrate a non-gdb debugger with
Eclipse?
** MBS - For my personal needs, it seems that everything I don't
want/need to deal with is configurable and everything that I *do* need
to configure is buried in a deep dark corner or it's locked down and
assumed that everyone wants it that way.
For example, in a project's "Properties" page, in our vision of our
final Eclipse "product" for our toolchain, almost all of the things on
the left-hand side of of the properties window (Info, Builders,
Documentation, File Types, Indexer, Project References) are of no use to
us. What we'd rather see is all of our custom toolchain Option
Categories out there, not buried down inside one little "Tool Settings"
tab inside "C/C++ Build".
Also, the concept of "Configurations" is something we have no use for.
Never have and don't see how we could. Yet the MBS forces us to specify
a "Configuration", and it forces a certain project structure on us based
on the selected configuration - i.e. it automatically creates "Debug"
and "Release" directories and places the makefiles and output binaries
there. I think a better concept is that of "Targets" rather than
"Configurations", where you can specify a sourcepool of code modules for
each target and set build/compile options for each individual target.
Within one project you could have a .lib target and 3 different kinds of
..exe targets, all of which share the same sourcepool of code. You
should also be able to set destination directories for intermediate
files and final binaries, or set one target with debug options and
another with release options. Maybe there's a way to configure this
stuff, but all I know is that after a couple of months, I still haven't
found it.
Last one, for a user to create a new project for our toolchain, they
need to follow: File -> New -> Managed C Project (or Managed C++
Project) -> Then pick our project type from a bunch of useless GNU
project types. I haven't figured out how yet (so if it's possible, my
comment = it's not easy to do), but I want to remove all of the GNU
stuff since it will just confuse the majority of our customers. But
furthermore, MBS should allow my custom project type to be created
directly from File -> New -> MY C/C++ PROJECT. The whole idea of
Standard vs. Managed and even having C separate from C++ is far from
intuitive.
Summary for MBS - I want my customers to have an easy time using our
Eclipse-based toolchain. That means they should be able to sit down and
create a new project without having to read extensive documentation.
Intuition should be able to lead them through at least the basics. I
know which IDEs they are all used to using, and unless I make drastic
changes to the CDT's MBS layout for them, they'll have a lousy
experience like I have had so far. We'll either get flooded with
support calls or we'll lose them as customers. Or they'll continue
using the old IDEs. My suggestion - nothing should be there unless I
put it there, and it should be more flexible as to where I can put it.
Final conclusion, if I didn't believe in the concept and theory of
Eclipse so much, I would have dropped Eclipse long ago due to the
experience I've had thus far. I do appreciate all the work that has
been done and I definitely appreciate that it's essentially done by
volunteers. Like I said, I am in full support of this idea & framework
and I would love to see it gain more momentum and support. Please
understand that my feedback is strictly meant to suggest improvements
and spark ideas - NOT to slam anyone for not doing a good job. I
realize that creating an IDE to end all IDEs is not a walk in the park.
I also definitely hope I can contribute to the effort in some way soon.
I hope some of that helps. I could probably type a bunch more for
another 2 hours, but I have to get back to learning Java, GNU make, and
GDB/MI...
--John
m. imrisek > wrote:
>
>
> For the CDT Developers Conference I am putting together a presentation
> on the CDT End User Experience for which I would like to get feedback
> from the CDT user community.
>
>
> I would like to get 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
> work flows?
> o Project create/import/build
> o Launch and debug work flows
> 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 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. :^)
>
> Regards,
>
> Martin
>
> --
> Martin Imrisek
> Software Systems Designer
> Texas Instruments
>
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156635 is a reply to message #156617] |
Fri, 21 October 2005 16:48 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.dharty.com
I tried to resist the flame bait, but there is just too much wrong with
whats been said in this post its hard to know where to start. There are
some valid points (Documentation, Specifications), but it seems that the
underlying gist of the post is that a software developer shouldn't be
bothered with having to learn the tools used to write software.
Also let me point out that you seem to confuse USING the Eclipse CDT and
EXTENDING the Eclipse CDT. The two are completely separate matters. If
you plan on extending any existing software, then I would suggest you
invest a little time learning the tools that are required to build it.
If the intended users of your extended Eclipse are indeed embedded
developers, than you better get used to the fact that they want, expect
and need more control over the "big-bad details" of the development
environment than click, code and compile. If you create a tool to be
used on one platform (eg wintel) and one platform only, then you can
abstract more of the layers from the eyes of the users. If the tool is
designed to be extensible and run on potentially thousands of different
types of targets, then you better make more of the layers visible to the
users.
The extendability of Eclipse is what makes it ideal for embedded
projects. Thats probably why you see so many embedded tool providers
switching to an Eclipse based IDE. I use the "off-the-shelf" Eclipse
CDT for all of my embedded development, and all I had to do was point
the make targets to my pre-existing make files.
As a user of Eclipse I have my gripes, but the plugin framework makes it
much more easily extensible than other proprietary tools I've worked
with. In 35 lines of Java, I created an error parser plugin for the
embedded compilers my team uses. I did not need to use the command
line, I did not even need to know or use GCC or Unix shells.
Have you ever tried to get VisualStudio to use a different compiler?
The simplest way to do so is to create a makefile project which uses a
makefile, but then you need to learn how to write a make file and you
loose all of the point click and compile you so highly covet.
Have you ever tried to write a plugin for VS? Good Luck! Other
developers on my team who still use VS to build the embedded targets
(which btw points make at a makefile) still do not have an error parser
after many years of using the platform. Perhaps if VS were more easily
extendable, someone would have tried.
I could go on, but I have to get back to that complier patch I've been
working on :~)
> I'm a newbie to Eclipse, and I think I have a lot of comments and input
> based on my first experience. Unfortunately, I think there are too many
> to list. Also, I think most of them are attributed to my lack of
> knowledge of GCC, Unix style shells, command line compiling, Java,
> makefiles, and all of the other things that aren't found in any
> Windows-based IDE's that I've used. I have to believe there are many
> more developers out there with a background similar to mine.
> Overall, I'm very excited about the idea of Eclipse. I'm using it right
> now to customize the CDT to use our custom toolchain and debug tools, so
> we can leverage off of all the other powerful Eclipse IDE plug-ins. Then
> we can concentrate on the nuts and bolts of our platform rather than a
> formatter, editor, project manager, etc.
>
> Instead of having me type a laundry list of specific comments, I'll try
> to concentrate on my overall impressions, and how I see Eclipse gaining
> "market share" and support. So let's all take a step back - what I see
> is that there are at least two different mindsets when it comes to
> developing software:
>
> The first is "mine" - double-click an icon to open your IDE, write your
> code, click the "compile" button, and you've got a piece of software you
> can sell to Joe Shmoe User.
>
> The second is "yours" (not meant to be insulting, but in general, this
> is my impression of all the developers in the *-nix and open-source
> world) - install Linux or a bash shell, spend hours and hours
> configuring your environment, read a ton of man pages, use a text editor
> like vi to write the code, create a makefile, learn Perl for the heck of
> it, build the project, discover a bug in the compiler, create a patch,
> figure out how to use CVS, submit the patch to the open source
> community, re-compile, and finally you've got a piece of software you
> can only give away to other developers exactly like yourself (it's way
> too complicated for Joe Shmoe User to even attempt to use). And you
> also only give away the source and binaries for *-nix, not Windows. On
> top of all that, there's a completely different lingo/language of words
> and acronyms used that nobody but yourselves can understand.
>
> To illustrate it another way, there are the people who read slashdot
> regularly, and there are people who can't understand 2 words of what's
> on slashdot.
>
> My general impression of Eclipse is that all you've done is strapped a
> GUI on the second mentality that I described above. Out of the box,
> Eclipse takes weeks to figure-out for a Microsoft-molded developer like
> me. People like me have had their hands held by pretty user friendly
> GUIs that hide all the big-bad details. This is where I feel Eclipse is
> not getting the support and following that it could be getting. It's
> not something "most" developers understand or have the patience to spend
> weeks figuring out. Just look at the world in general - why does the
> vast majority of the population use Windows rather than Linux?
>
> BTW - everyone that I've talked to in "my world" ever since I started
> looking at Eclipse hadn't even heard of it.
>
> Prior to trying to use Eclipse, for example, I had never heard of the
> following things, just to name a few: Build-file Generator, Dependency
> Calculator, Ant, Refactor, Working Set, Launcher, Make Target, Binary
> Parser, Error Parser, Project References, CVS, C/C++ Indexer, Artifact.
> I had heard of makefiles before, but up until a month ago, I had never
> seen one. Other IDEs don't use/reference all this stuff and it's
> enough to scare users of those IDEs away from Eclipse. I know there are
> a lot of developers like me out there - I'd say that 95% of my developer
> friends, co-workers, customers, etc. are like me. I'm sure that 95% of
> your acquaintances are like you. So - how can we merge the two worlds??
>
> I'm not going to try answering that question here and now, but hopefully
> it's food for thought. That's what I believe Eclipse is up against.
>
> Just in case at this point you're thinking: "who is this noob? he's
> probably a lousy coder! I'm embarrassed to hear that he calls himself a
> developer!", in my defense, I have a recent MSE from a top 5 university
> and aced my programming classes. When it comes to understanding "your
> world", I'll admit, I suck. I've never had a reason to enter your
> world until now.
>
> I do have some comments that come to mind regarding the CDT Usability.
>
> ** Embedded/Remote Targets - I'm currently in the embedded
> tools/products market, and it's clear that Eclipse is tailored for host
> side apps.
>
> ** Documentation - I have diligently read most of the documentation for
> Workbench, PDE, CDT, & CDT Plug-in Dev *twice*, and in general, I'm
> still lost. It assumes a lot of background knowledge from "your
> world".
>
> ** Specifications - I recently read a post where someone asked if there
> was a spec for the CDI and the response was along the lines of, "no -
> you have look at the source for how gdb is implemented". This just
> *baffles* my mind. How can a group of distributed developers create a
> generic API that is intended to be applied to any & all current & future
> debuggers *without* a spec? Maybe there is just some magic concept of
> open-source development that I don't understand. Or maybe this is part
> of the reason why it isn't easy to integrate a non-gdb debugger with
> Eclipse?
>
> ** MBS - For my personal needs, it seems that everything I don't
> want/need to deal with is configurable and everything that I *do* need
> to configure is buried in a deep dark corner or it's locked down and
> assumed that everyone wants it that way.
>
> For example, in a project's "Properties" page, in our vision of our
> final Eclipse "product" for our toolchain, almost all of the things on
> the left-hand side of of the properties window (Info, Builders,
> Documentation, File Types, Indexer, Project References) are of no use to
> us. What we'd rather see is all of our custom toolchain Option
> Categories out there, not buried down inside one little "Tool Settings"
> tab inside "C/C++ Build".
>
> Also, the concept of "Configurations" is something we have no use for.
> Never have and don't see how we could. Yet the MBS forces us to specify
> a "Configuration", and it forces a certain project structure on us based
> on the selected configuration - i.e. it automatically creates "Debug"
> and "Release" directories and places the makefiles and output binaries
> there. I think a better concept is that of "Targets" rather than
> "Configurations", where you can specify a sourcepool of code modules for
> each target and set build/compile options for each individual target.
> Within one project you could have a .lib target and 3 different kinds of
> .exe targets, all of which share the same sourcepool of code. You
> should also be able to set destination directories for intermediate
> files and final binaries, or set one target with debug options and
> another with release options. Maybe there's a way to configure this
> stuff, but all I know is that after a couple of months, I still haven't
> found it.
>
> Last one, for a user to create a new project for our toolchain, they
> need to follow: File -> New -> Managed C Project (or Managed C++
> Project) -> Then pick our project type from a bunch of useless GNU
> project types. I haven't figured out how yet (so if it's possible, my
> comment = it's not easy to do), but I want to remove all of the GNU
> stuff since it will just confuse the majority of our customers. But
> furthermore, MBS should allow my custom project type to be created
> directly from File -> New -> MY C/C++ PROJECT. The whole idea of
> Standard vs. Managed and even having C separate from C++ is far from
> intuitive.
>
> Summary for MBS - I want my customers to have an easy time using our
> Eclipse-based toolchain. That means they should be able to sit down and
> create a new project without having to read extensive documentation.
> Intuition should be able to lead them through at least the basics. I
> know which IDEs they are all used to using, and unless I make drastic
> changes to the CDT's MBS layout for them, they'll have a lousy
> experience like I have had so far. We'll either get flooded with
> support calls or we'll lose them as customers. Or they'll continue
> using the old IDEs. My suggestion - nothing should be there unless I
> put it there, and it should be more flexible as to where I can put it.
>
> Final conclusion, if I didn't believe in the concept and theory of
> Eclipse so much, I would have dropped Eclipse long ago due to the
> experience I've had thus far. I do appreciate all the work that has
> been done and I definitely appreciate that it's essentially done by
> volunteers. Like I said, I am in full support of this idea & framework
> and I would love to see it gain more momentum and support. Please
> understand that my feedback is strictly meant to suggest improvements
> and spark ideas - NOT to slam anyone for not doing a good job. I
> realize that creating an IDE to end all IDEs is not a walk in the park.
> I also definitely hope I can contribute to the effort in some way soon.
>
> I hope some of that helps. I could probably type a bunch more for
> another 2 hours, but I have to get back to learning Java, GNU make, and
> GDB/MI...
>
> --John
>
>
> m. imrisek > wrote:
>
>>
>>
>> For the CDT Developers Conference I am putting together a presentation
>> on the CDT End User Experience for which I would like to get feedback
>> from the CDT user community.
>>
>>
>> I would like to get 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
>> work flows?
>> o Project create/import/build
>> o Launch and debug work flows
>> 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 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. :^)
>>
>> Regards,
>>
>> Martin
>>
>> --
>> Martin Imrisek
>> Software Systems Designer
>> Texas Instruments
>>
|
|
|
| Re: Call for Input For CDT Fall Conference: CDT Usability [message #156703 is a reply to message #156231] |
Mon, 24 October 2005 11:13 |
| Eclipse User |
|
|
|
A lot of what you have written here would be considered bugs, and should
be raised in bugzilla.
Nathan Snapp wrote:
> I currently have been trying to use CDT with a rather large win32
> project with lots of MFC. I have tried the indexer and it picks up
> quite a bit, however, for a project with hundreds of files, it would be
> nice to have the indexer persist it's work between eclipse sessions--it
> takes about 2 hours to fully index this project!
>
> I have been working on smaller projects with eclipse and I've found it
> to work really well. The MBS seems to be generic enough to allow for
> some pretty neat plugins to it (I am using SConsBuilder which has been
> great for the most part).
> The indexer has been really helpful for these smaller projects, although
> at times slow and other times gives as been incorrect.
>
> Two examples of how it has been incorrect:
>
> I have noticed that when I have a class with member functions defined in
> the header (.h) any references to (*this) or to an instance of the class
> itself (such as a copy constructor or assignment operator) autocomplete
> incorrectly. All they show is the green circle Class icon and the name
> of the class. Member variables that I try to autocomplete to see what
> function they have show the arguments to that function as autocomplete
> options.
>
> I have had functions with the same name in different classes in one of
> our large projects. The indexer goes to declarations fine but in going
> to the definition from one of the declarations it would always pick the
> member function of the other class with the same name. Sorry I don't
> have more details on this.
>
> One other nitpicky thing is the Find/Replace dialog. It doesn't let you
> do match across line boundaries. This isn't CDT specific but just
> something that I think about whenever I use the find replace box.
>
> Sometimes having a single tool do something extremely well just makes me
> look forward to using that product. For instance Dreamweaver MX 2004's
> find/replace box is so nice that I often use dreamweaver for this
> ability alone (it allows you perform changes on folders, sites, and when
> you do multiple file find/replaces it shows you all the changes that it
> made in a view at the bottom of the IDE so you know what it matched).
> I'm not saying Eclipse and especially CDT needs that kind of
> find/replace, but in general having a tool or feature in an IDE that is
> so robust and useful often makes user overlook shortcomings in another
> area. Eclipse's synchronization tool is an example of such a tool. I
> worked on an OS project with a group and even though I couldn't use (or
> didn't know how to use) much of Eclipse's CDT stuff for the project, I
> did know that it has very robust team synchronization abilities and we
> used it simply for that. And that was back before a lot of the code
> indexing abilities were there.
>
> In other words, focusing efforts on debugging is good and all, but
> honestly I think solidifying the IDE for developing code should be first
> priority, and will help others to put it to use for existing projects.
> CDT has its work cut out for it--It has a lot to take on for the myriad
> C/C++ projects in existance and for it to try and play nice with them.
> If it can do that effectively I believe that will help others to enter
> into the Eclipse door--full featured debugging can be forgiven for now
> as long as they have an IDE alternative for doing their coding in, which
> in my case was an alternative for Visual Studio 6/7 (blech!).
>
> Good job with what has been done, CDT is truly getting there as far as a
> robust C/C++ IDE.
>
|
|
| | | |
Goto Forum:
Current Time: Fri Jul 18 13:10:16 EDT 2025
Powered by FUDForum. Page generated in 0.18768 seconds |
Home