[cdt-dev] RE: [cdt-patch] CView update

["Sally, Gene" <Gene.Sally@xxxxxxxxxxx>]

Alain,

Sorry for the slow response, as this is a background task for me and I've been swamped at home and work.

>> (1) Build actions shuffle
I read the docs for view contributions and understand this.  I'll need to check with Sean or read the code/docs to use a more elegant way of determining if the project is using the new build model than what I did the first time.

>> (2) CPatternFilters extends ResourceFilter
This I understand as well.

>> (3) CView extending ResouceNavigator.
I dug in to the code and this seems like a fairly large rework, as alluded by somebody else (sorry, can't recall the person) when the original discussion about doing this started. Also impacted by other re-work in ResourceNavigator as you stated.

I can tackle item 1 in short order, item 2 will take a bit longer and item 3 involves touching a lot of code, but is not that difficult. I think that 2 & 3 should be done at the same time because of the way these classes are inter-related.

Comments?  Sound OK?  

gene


-----Original Message-----
From: Alain Magloire [mailto:alain@xxxxxxx] 
Sent: Wednesday, July 23, 2003 12:24 PM
To: cdt-patch@xxxxxxxxxxx
Subject: Re: [cdt-patch] CView update

Bonjour Gene,
	Took a closer look at the patch and add a discussion with some folks.

The patch could be seperated in 3:
(1) Build actions shuffle
(2) CPatternFilters extends ResourceFilter
(3) CView extends ResourceNavigator.

(1):
Clever reshuffle, but after discussion and looking at the issue, it would
be better to do this as contributions. In brief builder has there own
nature that can be use has filter so they could contribute (specific) actions
to a project.   So the idea is to remove the current action code from the CView.java
and make them contribution forms "Std Make Builder".

(2) CPatternFilters
CPatternFilters.java is a copy of ResourceFilters,  and should work on ICElement, the
idea was not only to use simple pattern matching but also on more complexe actions.  For
example:
- filtering objects can not be only on pattern "*.exe" or "*.so" or "*.dll":
	gcc -o foobar hello.c
- filtering the includes
- filtering the reference library

Take a look at the JDT filters in the package explorer they define a bunch of filters
that works on IJavaElement not only pattern matching.

In brief ResourcePatternFilters works only with IResource, CPatternFilters works
with ICElement and non-celements, this can make things problematic if you call
ResoucePatternFilters methods on an ICElement(some do not have a correspondign IResource).

(3) CView extending ResouceNavigator.
Again on sure on this for the same reasons seen in (2), we are working on a different
set of objects (ICElement), the same way the JDT PackageExplorerPart is working
wiht IJavaElement and non-java-resources.  The original CView.java was copy/paste of parts of the
ResouceNavigator in Eclipse-1.0, so the similarity makes the extension even more tempting.
  Also reading the Eclipse-3.0 plan, it says that ResourceNavigator will be more extensible,
but we may still have the same problem; CView, ResourceNavigator, PackageExplorerPart etc ... they are working
on different data sets; ICElement, IResource, IJavaElement.


Some of the points may not be clear but I'll be happy to clarify.
Many many thanks for the patch(although it was not applied), portion of it
made us reflect on what we are trying to achieve and clear the confusion.


_______________________________________________
cdt-patch mailing list
cdt-patch@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-patch