Community
Participate
Working Groups
It could be interesting to be able to use the extensibility of the CNF in an Outline. Currently it is to deeply linked with the CommonNavigator View.
Can you elaborate on this a little more? Exactly what would you like the CNF to do in an outline view?
We are interested in an extensible outline. Currently we are developing editors (graphical or forms) for EMF models and the outline is used to provide a treeview of the current edited model. First, models can be extensible so we want to extend the outline to reflect this model extension. But we can also imagine another scenario where several kind of treeview can be defined for a model (just like in the Team Synchronize view) and then the architecture of the CNF is perfect for this usecase. A solution could be to replace all the dependencies on CommonNavigator by an interface. This interface will implemented by CommonNavigator and CommonNavigatorPage (the IContentOutlinePage using CNF) Currently, the framework is not too dependent on CommonNavigator. Here are the methods from CommonNavigator used by the framework : ----- CommonNavigator methods ---- CommonNavigator.IS_LINKING_ENABLED_PROPERTY getCommonViewer() getNavigatorContentService() selectReveal(newSelection) isLinkingEnabled() setLinkingEnabled() ----- IViewPart methods ---- addPropertyListener() removePropertyListener() getSite() getTitle() getViewSite().getActionBars() As you can see, only 5 IViewPart methods are used and can be extracted to an interface.
Ok, it sounds like you want an ICommonNavigator interface or something like that so that you can provide your own implementation. But then how are you using the CommonNavigator? (I'm sure I'm missing the point here, please try and help me understand). When you talk about outline, you mean a specific outline implementation? If so, can you give me the class you are talking about. Do you mean that you want to decouple the current outline implementation from the CommonNavigator so you can provide your own? Can you accomplish this by subclassing the CommonNavigator (I know that subclassing is not "allowed" by the API definition, but I'm asking more to find out what you are wanting)?
Creating an interface ICommonNavigator would be perfect. Then we can create an implementation extending ICommonNavigator and IContentOutlinePage. I am working on a prototype to test if it is possible and perhaps to initialize a patch if the community is interested.
(In reply to comment #4) > Creating an interface ICommonNavigator would be perfect. Then we can create an > implementation extending ICommonNavigator and IContentOutlinePage. > > I am working on a prototype to test if it is possible and perhaps to initialize > a patch if the community is interested. > Ok, I would welcome a patch for this. Thanks.
Created attachment 105184 [details] Patch to enable the use of CNF in an Outline This patch extracts generic methods from CommonNavigator to a ICommonNavigator interface and proposed a default implementation of this interface for outlines based on IContentOutlinePage. Modified files are all in the org.eclipse.ui.navigator project. This is a first implementation I've done to validate the concept. I currently extend the CommonNavigatorOutline to create a generic extensible outline for EMF models.
(In reply to comment #6) > Created an attachment (id=105184) [details] > Patch to enable the use of CNF in an Outline > > This patch extracts generic methods from CommonNavigator to a ICommonNavigator > interface and proposed a default implementation of this interface for outlines > based on IContentOutlinePage. > Modified files are all in the org.eclipse.ui.navigator project. > > This is a first implementation I've done to validate the concept. I currently > extend the CommonNavigatorOutline to create a generic extensible outline for > EMF models. > Your patch has quite a bit of formatting changes which makes it difficult to determine the substantive changes. Can you provide a patch with no formatting changes so the differences only show what actually changed?
Created attachment 105426 [details] Updated patch using good format I think it will be easier with this one... Sorry but what is your formatting options ? I cannot find the exact configuration.
(In reply to comment #8) > Created an attachment (id=105426) [details] > Updated patch using good format > > I think it will be easier with this one... > Sorry but what is your formatting options ? I cannot find the exact > configuration. > Generally the default eclipse options are used for formatting, though some projects tend to vary a bit from that sometimes. I'm not sure about the CNF code. Thanks for the patch, it's going to take me a little while to get to this, as I am only a part-time committer and need to devote time to bugs right now. Feel free to ping me (by commenting on the bug report) if you have not heard anything in a while.
Created attachment 106327 [details] Patch supporting CNF in a outline (supporting menu extensions) I forgot to refactor some classes to support popup menu extensions. The new patch fixes this and works well but I don't like the way it is currently done. So I will try to propose another solution soon.
Do you plan to integrate this kind of feature in 3.5 ? Do I need to integrate changes in the patch ? Because we really need this behavior to create customizable and extensible outlines. We created a first example of use in the Ecore Tools project and we would be interested to switch from the basic outline to this new extensible CNF-based outline.
I have not looked at this yet, and probably won't for a couple of weeks. Assuming I agree it should be done at all (I have no opinion on it right now), it can certainly be done in the 3.5 timeframe. The reason for the delay is I'm focusing on 3.4.1 issues and bugs right now. Thanks for your patch and your patience, and feel free to ping me in a couple of weeks if you like.
Do you have some time to look at this patch. This is a blocking point for me, as I wish to contribute an outline based on the CNF for the upcoming Eclipse Papyrus project. I would like to avoid duplicating code and I am so waiting for this feature to be implemented.
Any news ?
I like this and I want to get it into 3.5, which means it needs to go in soon, and into M6. However, the patch is much larger than 250 lines, and something bigger than 250 lines needs to get all kinds of approval. So here is what I would like to do to get this in: 1) You should explain the steps at making the change based on your patch, but excluding your outline implementation. E.g. a) create ICommonNavigator as extracted from CommonNavigator b) any special methods you needed to add to ICommonNavigator c) any extra hooks you needed in other classes (you don't need to explain the mechanical stuff about extracting the interface, just the odd things you found -- including the issues about the menu extensions). If you can do this in the next week or so, I will check it in shortly after that. 2) File a different bug report offering the outline implementation. You can create a patch for that once the work on this bug report has completed. I assume your outline implementation will be < 250 lines.
It seems that in trying to get CommonNavigator functionality to work as a page for use in a PageBookView, I've been pursuing this issue also. See Bug 264738. Attached are the classes CommonViewerPageView and CommonViewerManager, which is derived from NavigatorViewManager. I have not thoroughly tested all of this it seems to do the trick.
Unfortunately the CNF now depends on the CommonViewer to store a pointer to the NavigatorContentExtension (it actually stores this in the TreeItem). I can't think of an straightforwards way to not have this dependency, given that you are not supposed to subclass the views. So I don't think we can do this. If you disagree and have a proposal, please reopen this.
Others have been requesting this and we have done some abstraction in the Viewer area for having the viewer remember the CNF content. So I think we should reconsider this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
