Home » Language IDEs » C / C++ IDE (CDT) » Integration
| Integration [message #6764] |
Sun, 16 December 2001 02:21  |
Eclipse User |
|
|
|
Originally posted by: j9brown.uwaterloo.ca
I'm unclear about certain design decisions that seem to have been
made for CDT. At least on the surface it appears to me that
CDT is duplicating functionality already present in the Eclipse
platform. I'm not saying that anything in particular is wrong,
I'm just curious why things are as they are...
1. Command Specifications
This looks like a plain old Properties view to me and yet it
isn't. It would make more sense to me if commands were
arrayed compactly as a list in the Command Launcher view.
Instead of a cascading property list, we'd simply use
wizards to edit the various essential fields.
Alternately, the commands seem to require a Container
in order to operate. Perhaps then they could be viewed
as children of a Project (representing objects derived from
IResource) and displayed in the C++ Projects list.
In that case it would make sense to use the existing platform
Properties view to manipulate their fields. This would
pose a dilemma for possible "global" commands...
Basically, I don't see what is gained by arranging these
commands in a property list style view.
2. C/C++ Project Objects View
I'm assuming that this is equivalent to the JDT Hierarchy
view which provides a global listing of objects in the
system. How about calling this view Hierarchy as well?
That name is certainly much shorter and yet it encompasses
every use that I can see this view being put to.
Have a look at how the JDT Hierarchy view integrates
with the Packages and Outline views. In that case, you
can explicitly state "Open in Type Hierarchy" to focus in
on a particular class. I'd imagine this could easily be
extended to cover other scopes (namespaces etc...).
To do this, the C/C++ Project Objects view would need
to become more of a class browser (a good thing, IMHO)
with browser-style buttons to move around in the hierarchy.
I picture a browser with:
Back button - focus on previous view of hierarchy
Forward button - reverse the operation of Back
Up - focus on parent element in hierarchy
Home - focus on root of hierarchy (global scope)
Browse - pop up a dialog requesting new scope
Filters - specify types of objects to display
3. Project Details
What information is supposed to be displayed here that is
not already visible from either the C/C++ Projects, C/C++
Project Objects, or the Outline view? It seems to provide
a substantial amount of detail, but if you click over to the
Outline view, you see the same information.
My guess is that it is supposed to cooperate with the
C/C++ Project Objects view, but it would be more
intuitive for me if the added information were presented
as a child of the related object in the tree. This would eliminate
the redundant view but add significant value to the "scope
browser".
Incidentally, in loading a C++ project, I found that the
"Project Details" view was being populated, but not
the Outline view...
4. C/C++ Parsed Files
Rather than present the information here in list form where
it quickly becomes hard to find things, I'd recommend that
the "this file has been parsed" information be presented as
a decoration in the C/C++ Projects view.
To avoid visual clutter, the option to show/not show the
decoration could be presented as a filter. Frankly, I'm
not altogether certain what this information is good for,
except perhaps for debugging the C/C++ plugin itself.
It makes sense to me that when the scanner code reaches
maturity, any files that could not be scanned for some reason
(ie. syntax error) should be flagged with a warning or
error marker, perhaps with an option to disable the warning.
(See JDT 2.0 Prerences pane)
~~~
Anyhow, these were the first few things I noticed when
I started up the plugin. Otherwise it looks _very_ promising
and I wish you luck. In fact... I might be interested in
contributing to the project in any way possible, should I find
the time.
Jeff.
|
|
|
| Re: Integration [message #6781 is a reply to message #6764] |
Mon, 17 December 2001 11:00  |
| Eclipse User |
|
|
|
Hi Jeff,
Thanks for the very detailed feedback. I'll put my responses inside
your text.
Jeff Brown wrote:
> I'm unclear about certain design decisions that seem to have been
> made for CDT. At least on the surface it appears to me that
> CDT is duplicating functionality already present in the Eclipse
> platform. I'm not saying that anything in particular is wrong,
> I'm just curious why things are as they are...
>
> 1. Command Specifications
>
> This looks like a plain old Properties view to me and yet it
> isn't. It would make more sense to me if commands were
> arrayed compactly as a list in the Command Launcher view.
> Instead of a cascading property list, we'd simply use
> wizards to edit the various essential fields.
>
> Alternately, the commands seem to require a Container
> in order to operate. Perhaps then they could be viewed
> as children of a Project (representing objects derived from
> IResource) and displayed in the C++ Projects list.
> In that case it would make sense to use the existing platform
> Properties view to manipulate their fields. This would
> pose a dilemma for possible "global" commands...
>
> Basically, I don't see what is gained by arranging these
> commands in a property list style view.
>
We've been talking about various problems with our commands views for a
while. First there are redundancies between the Command Launcher and
Command Specifications view; they both are used to launch commands. The
main difference between them is that the launcher view is mostly
intended for commands that a user spontaneously decides to run, while
the specifications view is indended for commands that will be repeatedly
issued (such as building a particular make target). We do want to merge
the two views at some point but we're still not sure which approach
makes the most sense. Your suggestions will be kept in mind.
>
> 2. C/C++ Project Objects View
>
> I'm assuming that this is equivalent to the JDT Hierarchy
> view which provides a global listing of objects in the
> system. How about calling this view Hierarchy as well?
> That name is certainly much shorter and yet it encompasses
> every use that I can see this view being put to.
>
There are differences between the JDT Hierarchy and the C/C++ Project
Objects View. First, the JDT Hierarchy is a class hierarchy view, while
the Project Objects view is a contents hierarchy for the project -
listing declarations of the project. To see a class hierarchy for C++,
a Details view is used. Project Objects is also different because it
lists functions, structs, variables, macros, and other declarations in
addition to classes.
> Have a look at how the JDT Hierarchy view integrates
> with the Packages and Outline views. In that case, you
> can explicitly state "Open in Type Hierarchy" to focus in
> on a particular class. I'd imagine this could easily be
> extended to cover other scopes (namespaces etc...).
> To do this, the C/C++ Project Objects view would need
> to become more of a class browser (a good thing, IMHO)
> with browser-style buttons to move around in the hierarchy.
> I picture a browser with:
> Back button - focus on previous view of hierarchy
> Forward button - reverse the operation of Back
> Up - focus on parent element in hierarchy
> Home - focus on root of hierarchy (global scope)
> Browse - pop up a dialog requesting new scope
> Filters - specify types of objects to display
Myself and others on the team really like this idea of a class
"browser". This support can be added quite easily.
>
> 3. Project Details
>
> What information is supposed to be displayed here that is
> not already visible from either the C/C++ Projects, C/C++
> Project Objects, or the Outline view? It seems to provide
> a substantial amount of detail, but if you click over to the
> Outline view, you see the same information.
> My guess is that it is supposed to cooperate with the
> C/C++ Project Objects view, but it would be more
> intuitive for me if the added information were presented
> as a child of the related object in the tree. This would eliminate
> the redundant view but add significant value to the "scope
> browser".
>
Perhaps the biggest problem with the Project Objects view is it's name.
We've been struggling with finding appropriate names to some of our
views. It's a pretty generic view - it complements others views -
Projects, Project Objects, System Objects, and various other views.
It's usefulness is in the different relationships it can view of the
input objects. For example, if a class is inputed into it, it can be
used to browse the contents of the class, or the class hierarchy, if a
variable is inputted into the view, it can be used to browse it's uses
in the project, if a parsed file is inputted into the view, it can be
used to browse the parsed contents of the file or the include hierarchy
of the file, or if a function is inputted into the view, a user can
browse it's contents, it's callees or it's callers.
The Outline view can only be used when a file is open in the editor
because Outline views are strictly driven from editors.
>
> Incidentally, in loading a C++ project, I found that the
> "Project Details" view was being populated, but not
> the Outline view...
>
> 4. C/C++ Parsed Files
>
> Rather than present the information here in list form where
> it quickly becomes hard to find things, I'd recommend that
> the "this file has been parsed" information be presented as
> a decoration in the C/C++ Projects view.
>
We have talked about eventually doing away with this view, as the
information it contains can be accessed by others means. The one thing
I find useful about it now, is that it can be used to get at your system
"include" files. These are files that are not contained in the project
but are discovered by the parser (provided the include path is setup).
If the view was eliminated we would still be able to access those files
through the include hierarchy or system objects.
>
> ~~~
>
> Anyhow, these were the first few things I noticed when
> I started up the plugin. Otherwise it looks _very_ promising
> and I wish you luck. In fact... I might be interested in
> contributing to the project in any way possible, should I find
> the time.
>
Thanks again and look forward to hearing more feedback and hopefully
seeing contributions.
Dave
|
|
|
| Re: Integration [message #8763 is a reply to message #6781] |
Wed, 02 January 2002 17:03 |
| Eclipse User |
|
|
|
Originally posted by: j9brown.uwaterloo.ca
Happy holidays everyone! I started writing this sometime before
Xmas but haven't had the time to finish it until now. Sorry for the
delay...
> There are differences between the JDT Hierarchy and the C/C++ Project
> Objects View. First, the JDT Hierarchy is a class hierarchy view, while
> the Project Objects view is a contents hierarchy for the project -
> listing declarations of the project. To see a class hierarchy for C++,
> a Details view is used. Project Objects is also different because it
> lists functions, structs, variables, macros, and other declarations in
> addition to classes.
Yes... I see the differences. Why not call the view "Declarations"
then? A simple drop-down menu could be used to filter the contents
of this view to only show some combination of, say...
- type declarations (structs, enums, classes, typedefs)
- function declarations
- namespace declarations
- global variable declarations inside namespaces
- macro definitions
Additionally we could further filter to only show:
- template type / function declarations
- public/protected/private visibility
I think "class browser" functionality in this view makes sense
since most of these declarations are scoped, hence they form a
hierarchy. We would need to make the distinction between
"navigate to supertype" and "navigate to containing scope".
On class declarations, both buttons would be active, on all
others but for macros, only the second would be. We could
presume macro definitions belonged to the "global" scope.
In the case of classes with multiple inheritance,
"navigate to supertype" might prompt for the one we're
interested in.
Additionally we could offer different tree formats for arranging
the entries. Three come to mind:
1) scope hierarchy - contained declarations appear
inside containing ones
2) class hierarchy - derived classes appear as
children of parent classes
3) class hierarchy - superclasses appear as
children of derived classes, currently
focused class is at root
Alternately, we could offer an option that
displays the class currently in focus, and all of its
supertypes as children in the tree... e.g.:
In the global scope we might see...
:: :
- namespace myNamespace
+ class myClass
+ class mySuperType<T>
+ class myInterfaceType
- int myNamespaceGlobalVar
- int globalVar
- int atoi(char* str)
- #define MACRO
Then if we double-click or right-click or whatever
on myClass we'd get:
:: myNamespace :: myClass :
+ derived from class mySuperType<int>
- derived from class myInterfaceType
- int x
- int iface(int bar)
- int x
- int y
- int iface(int bar)
Just a thought. Basically, I'm thinking beyond the class
browser idea into a generic declarations browser.
Perhaps I could better illustrate this with a mock-up
or some concept code.
> > 4. C/C++ Parsed Files
> >
> We have talked about eventually doing away with this view, as the
> information it contains can be accessed by others means. The one thing
> I find useful about it now, is that it can be used to get at your system
> "include" files. These are files that are not contained in the project
> but are discovered by the parser (provided the include path is setup).
> If the view was eliminated we would still be able to access those files
> through the include hierarchy or system objects.
Personally, I would like to see this view eliminated to reduce
duplication / interface clutter. Perhaps someone could list out
a variety of use-cases involving this view, and consider how
they might be better performed using the other available views.
If the view isn't pulling its weight, then the alternatives are to
distribute its reponsibilities elsewhere, or to graft valuable
new ones. (see below)
> Perhaps the biggest problem with the Project Objects view is it's name.
> We've been struggling with finding appropriate names to some of our
> views. It's a pretty generic view - it complements others views -
> Projects, Project Objects, System Objects, and various other views.
> It's usefulness is in the different relationships it can view of the
> input objects. For example, if a class is inputed into it, it can be
> used to browse the contents of the class, or the class hierarchy, if a
> variable is inputted into the view, it can be used to browse it's uses
> in the project, if a parsed file is inputted into the view, it can be
> used to browse the parsed contents of the file or the include hierarchy
> of the file, or if a function is inputted into the view, a user can
> browse it's contents, it's callees or it's callers.
I think this description indicates that the view is pulling too much
weight. There are two distinct usage patterns that I can see:
1) browsing declarations in source files
2) browsing the parse tree
The first task would be very well served by the Declarations
view I proposed above. The second task, however, is so closely
related to the C/C++ Parsed Files view that perhaps a
consolidation of these responsibilities is in order.
I would recommend that we:
- eliminate the C/C++ Parsed Files view
- create a new Declarations browser as described above
based on the existing C/C++ Project Objects view
- create a new Parse Tree browser view to subsume
the remaining responsibilities
e.g. Parse Tree view
+ myFile1.cc
- include <iostream>
+ main(int argv, char** argc)
- int foo = 42;
- helper
- cout...
+ iostream
- namespace std
- ...
- ios.h
- iosbase.h
- ...
|
|
|
| Re: Integration [message #8788 is a reply to message #8763] |
Thu, 03 January 2002 18:02 |
| Eclipse User |
|
|
|
Jeff Brown wrote:
> Happy holidays everyone! I started writing this sometime before
> Xmas but haven't had the time to finish it until now. Sorry for the
> delay...
>
Happy Xmas and New Year!
>
> > There are differences between the JDT Hierarchy and the C/C++ Project
> > Objects View. First, the JDT Hierarchy is a class hierarchy view, while
> > the Project Objects view is a contents hierarchy for the project -
> > listing declarations of the project. To see a class hierarchy for C++,
> > a Details view is used. Project Objects is also different because it
> > lists functions, structs, variables, macros, and other declarations in
> > addition to classes.
>
> Yes... I see the differences. Why not call the view "Declarations"
> then?
We considered that name at one point. I think the main issue we had with
"Declarations" is that the view is not just for declarations, although I
prefer "Declarations" too.
> A simple drop-down menu could be used to filter the contents
> of this view to only show some combination of, say...
> - type declarations (structs, enums, classes, typedefs)
> - function declarations
> - namespace declarations
> - global variable declarations inside namespaces
> - macro definitions
We already have a view menu that does this. That's the menu on the far right
of the view toolbar.
>
> Additionally we could further filter to only show:
> - template type / function declarations
> - public/protected/private visibility
We don't currently store these distinctions but it's worth looking into.
>
> I think "class browser" functionality in this view makes sense
> since most of these declarations are scoped, hence they form a
> hierarchy.
As you mentioned further down, "declarations browser" is what we're really
after. The views are actually generic in the sense that they are implicitly
driven by our ui object model. This allows us to change the model schema
without having to update the UI. The view filter menus, view relationship
menus, and contents of a view all emerge from it's input. Because of this, we
don't have to explicitly write code for viewing particular object types and
browsing particular dimensions of an object. The key to getting at the
information the represents any relationship for a particular object is to make
that object the input to a view (ie. Project Details).
> We would need to make the distinction between
> "navigate to supertype" and "navigate to containing scope".
Currently this distinction is implicitly made by the relationship menu (the
second to the right view menu) of a view when a class is the input to that
view. The Project Objects view is strictly a "contents" (or scope) view of
the project (we only show a single relationship between objects at one time in
a view), so that the Details view is required to get at other relationships.
> On class declarations, both buttons would be active, on all
> others but for macros, only the second would be. We could
> presume macro definitions belonged to the "global" scope.
That's what we presume right now.
>
> In the case of classes with multiple inheritance,
> "navigate to supertype" might prompt for the one we're
> interested in.
The way we do this now is display all base classes or derived classes (we
don't prompt). Below is are examples of this:
dervived classes of Employee:
(C) Employee
-------------------------------
(C) Sales_Person
+(C) Manager
--- (C) Sales_Manager
base classes of Sales_Manager:
(C) Sales_Manager
-----------------------------------
+(C) Sales_Person
--- (C) Employee
(C) Manager
--- (C) Employee
If we choose to make the Project Objects view more of a "Browser", browsing
could simply consist of changing the input to the view, thus allowing the user
to change the relationship that he/she is looking depending on the object
he/she is looking at. For example, if I start by viewing all of the classes
in my project, I may then select a class, double click it, and then set the
input to the view to be that class. With a class as my input I may choose to
view the relationships that make sense for class (ie base classes, derived
classes, uses, contents). If I see a base class I'm interested in, I set the
input to it, and so on. Rather than having specific buttons for class
browsing, I was thinking of simply using "Back", "Forward" and "Home" buttons,
like those in web-browsers. All these buttons need to do is change the input
to the view while maintaining a history.
> Additionally we could offer different tree formats for arranging
> the entries. Three come to mind:
> 1) scope hierarchy - contained declarations appear
> inside containing ones
This is what we get by default for a project in the Project Objects view.
>
> 2) class hierarchy - derived classes appear as
> children of parent classes
>
> 3) class hierarchy - superclasses appear as
> children of derived classes, currently
> focused class is at root
We currently get this for any class that is the input to a view. We can
browse it's contents, base class hierarchy or derived class hierarchy
depending on what is selected in the relationship menu.
>
> Alternately, we could offer an option that
> displays the class currently in focus, and all of its
> supertypes as children in the tree... e.g.:
>
> In the global scope we might see...
>
> :: :
> - namespace myNamespace
> + class myClass
> + class mySuperType<T>
> + class myInterfaceType
> - int myNamespaceGlobalVar
> - int globalVar
> - int atoi(char* str)
> - #define MACRO
>
> Then if we double-click or right-click or whatever
> on myClass we'd get:
>
> :: myNamespace :: myClass :
> + derived from class mySuperType<int>
> - derived from class myInterfaceType
> - int x
> - int iface(int bar)
> - int x
> - int y
> - int iface(int bar)
The key difference between what we have and your suggestion is that you're
displaying multiple relationships in a single view. In the above example,
you're displaying the contents of myClass while also displaying the base
classes of myClass. In our case, we restrict the user to a single
relationship at a time in order to avoid confusion. With the basic tree
control, one can make very few distinctions between objects and relationships
( derived things may look a lot like contained things). The complexity grows
because we show lots of different types of relationships - uses, returns,
parameters, callees, callers, etc. - depending on the object. That's one
reason why we have a details view - so that we can view multiple relationships
but make it clear which one is being used in each view.
>
>
> Just a thought. Basically, I'm thinking beyond the class
> browser idea into a generic declarations browser.
That's what's this should be :)
>
> Perhaps I could better illustrate this with a mock-up
> or some concept code.
>
> > > 4. C/C++ Parsed Files
> > >
> > We have talked about eventually doing away with this view, as the
> > information it contains can be accessed by others means. The one thing
> > I find useful about it now, is that it can be used to get at your system
> > "include" files. These are files that are not contained in the project
> > but are discovered by the parser (provided the include path is setup).
> > If the view was eliminated we would still be able to access those files
> > through the include hierarchy or system objects.
>
> Personally, I would like to see this view eliminated to reduce
> duplication / interface clutter. Perhaps someone could list out
> a variety of use-cases involving this view, and consider how
> they might be better performed using the other available views.
> If the view isn't pulling its weight, then the alternatives are to
> distribute its reponsibilities elsewhere, or to graft valuable
> new ones. (see below)
>
>
> > Perhaps the biggest problem with the Project Objects view is it's name.
> > We've been struggling with finding appropriate names to some of our
> > views. It's a pretty generic view - it complements others views -
> > Projects, Project Objects, System Objects, and various other views.
> > It's usefulness is in the different relationships it can view of the
> > input objects. For example, if a class is inputed into it, it can be
> > used to browse the contents of the class, or the class hierarchy, if a
> > variable is inputted into the view, it can be used to browse it's uses
> > in the project, if a parsed file is inputted into the view, it can be
> > used to browse the parsed contents of the file or the include hierarchy
> > of the file, or if a function is inputted into the view, a user can
> > browse it's contents, it's callees or it's callers.
>
> I think this description indicates that the view is pulling too much
> weight. There are two distinct usage patterns that I can see:
> 1) browsing declarations in source files
> 2) browsing the parse tree
>
> The first task would be very well served by the Declarations
> view I proposed above.
The Declarations/Objects view is able to provide the same basic functionality
as the Details view (in fact they are the same view). But having the Details
view serves me because it gets driven by the Declarations/Objects view.
Having two views lets me browse different relationships and contents of
different artifacts without having to get lost in the Project Objects view.
> The second task, however, is so closely
> related to the C/C++ Parsed Files view that perhaps a
> consolidation of these responsibilities is in order.
>
> I would recommend that we:
> - eliminate the C/C++ Parsed Files view
Perhaps, although the "Parse Tree" browser you've suggested sounds very
similar.
>
> - create a new Declarations browser as described above
> based on the existing C/C++ Project Objects view
Very little would be needed to add the kind of support I'm suggesting. There
are similarities and differences between what you suggest and what I'm going
for. I'll summarize what I'm thinking of here:
-double-click (or a right-click action) on declaration to set input to
view
-"home" button sets the default input - the project, with a "contents"
/scope view
-"back" button sets the input to be the previously set input
-"forward" button sets the input to be the next set input if we are
further back in the history
- as we have now, possible relationships are determined by the type of
input object and are populated in the relationship menu rather than by
explicit actions
-
Let me know whether this provides the kind of support you would want in a
declarations browser.
>
> - create a new Parse Tree browser view to subsume
> the remaining responsibilities
It looks like the thing that "Parse Tree" browser view adds that the Parsed
Files view does not already have is drill down capability. In our case, the
details view serves as an extension to the view for drilling downt. All we
have to do to get the parsed files view to do this independently of the
details view is change the "table" flag to "tree" when we construct the
Parsed Files view(it's a one-liner).
>
> e.g. Parse Tree view
> + myFile1.cc
> - include <iostream>
> + main(int argv, char** argc)
> - int foo = 42;
> - helper
> - cout...
> + iostream
> - namespace std
> - ...
> - ios.h
> - iosbase.h
> - ...
Thanks again for sharing these ideas.
Dave
|
|
|
Goto Forum:
Current Time: Fri Apr 25 21:35:28 EDT 2025
Powered by FUDForum. Page generated in 0.02506 seconds |
Home