Community
Participate
Working Groups
The framework defines some tags like NoAutoCollapse. How does the developer know that these tags exist? AFAICT, tags can be provided by the framework, by add-ons or user defined. If there are going to be many tags, I think we need a way to document them. If an addon allows to enter a tag, is there a way to query this addon so that the model editor knows what tags to present to the user? Maybe query for some "Tag" object that provides tag id and description.
There's a list of tags on org.eclipse.e4.ui.workbench.IPresentationEngine. The idea behind the use of tags is that they should be self-describing and encode their semantic meaning. That is, if two different components choose the same tag, they will have the same meaning. It could be useful if the E4 editor offered content-assist based on the tags already defined in the model.
(In reply to comment #1) > There's a list of tags on org.eclipse.e4.ui.workbench.IPresentationEngine. > > The idea behind the use of tags is that they should be self-describing and > encode their semantic meaning. That is, if two different components choose > the same tag, they will have the same meaning. I see. Is there something on paper about this? > It could be useful if the E4 editor offered content-assist based on the tags > already defined in the model. That is what I was thinking. Let me move this bug over to e4 and see if it gets some support. What I would like to do is to model the tags. If you look at the past there were frequent use of values that you had to look up outside of the definition, e.g. ISources I think the model could be filled with an (MTag) element list that holds information about the available tags. From the outside, actors are able to inject values into the tag list. The user can then look up the available tags from within the model. We can start to load the values from IPresentationEngine and build from there.
I also think is a good idea to have the editor content-assist tags. However it's not just about the tags in the IPresentationEngine. Also throughout the renderers there are a lot of tags (WBWRenderer,MenuManagerRenderer etc). These tags are useful and I don't thing we should leave them out. Maybe we can have the SWT renderers gather all the available tags in one place in some ISWTRenderTags or something similar and have the tags dividied in Widget-agnostic tags and Renderer tags. This would require an extension mechanisms for the editor (much like the new editor extension point) to accommodate model extensions which may include other tags. In the mean time there we could change the tag textbox in the supplementary tab of the editor and autofill it with the IPE's values. I will track it in bug 394073.
I'm not sure if I like this content assists. The tags are designed to be flexible and extentable and we would imply that the list we present is finite. Also content assists has only limited possibility to give a detailed explanation. I would prefer that the flags are documented on a wiki page, so that we can add useful descriptions. Doing this is code feels wrong to me.
(In reply to comment #4) > The tags are designed to be > flexible and extentable and we would imply that the list we present is > finite. I agree with this part. Content assist is useful to see what tags have already been defined (and can help prevent typos). You won't find an authoritative definition of a tag — the tag is interpreted by the the user. > I would prefer that the flags are documented on a wiki page, so that we can > add useful descriptions. Doing this is code feels wrong to me. http://wiki.eclipse.org/Eclipse4/RCP/Modeled_UI/Tags http://wiki.eclipse.org/Eclipse4/RCP/Modeled_UI/Rendering_the_Model Though there are more tags now on IPresentationEngine. You guys really should check the wiki :-)
(In reply to comment #4) > I'm not sure if I like this content assists. The tags are designed to be > flexible and extentable and we would imply that the list we present is > finite. Also content assists has only limited possibility to give a detailed > explanation. > I would prefer that the flags are documented on a wiki page, so that we can add > useful descriptions. Doing this is code feels wrong to me. One of the strong points of the extension point mechanism was the documentation model. All extension points were described in detail with examples. I think we need something like that for tags as well. But unlike the extension points, tags are really simple. It is just one string. so the documentation model is so much simpler. e.g. Class: MTag String: Tag: NoAutoCollapse String: Descr: Will keep the part stack visible if the last part is minimized MApplicationElement: Apply_to: MPartStack String:Provided by: CleanUp Addon If the number of tags grow (and exactly that is the purpose of tags) we will run into forum posts like this: http://www.eclipse.org/forums/index.php/t/403398/
(In reply to comment #5) > (In reply to comment #4) > > The tags are designed to be > > flexible and extentable and we would imply that the list we present is > > finite. > > I agree with this part. Content assist is useful to see what tags have > already been defined (and can help prevent typos). Then you mean you don't agree right? > > You guys really should check the wiki :-) You just updated it? ;)
I don't think wiki and auto completion are mutually exclusive. We can have them both. I remember a forum post the guy spent lots of hours on it just because he didn't think tags were case-sensitive so I think there is a value in suggesting them. Also I think beginners don't know they exist so just having them exposed is a good thing IMHO. If they want details they can see the wiki and there we write BIG that the list is extendable.
Ok I'm partially convinced. +0 from me, no objections from me for the implementation of this.
Tags are used in (at least) three different ways: 1) Descriptive: Applied to an element to modify how it's interpreted by the rendering system (NO_CLOSE, NO_AUTO_COLLAPSE...) 2) Operative: When added / removed from an element causes some action to occur (MINIMIZE, MAXIMIZE...) 3) CSS: All tags applied to an element can participate in the CSS styling (active, TrimStack...)...this is very useful but right now we have a brute force approach, take *all* the tags and pass them as pseudo-classes to the CSS engine. If there are a lot of tags in an element for other reasons then this has the potential to slow down the styling. There may also remain cases where we were using tags before 'persistedDate' came into being. We should see if we can identify cases where info currently being stored in tags could be moved over to either the persistent or transient maps (see above). I'm all for getting a better handle on these as part of getting our API story straight. This seems at least somewhat like the issues we also have keeping track of annotations, any chance there's a common solution ? Wim, rather than saying that NO_AUTO_COLLAPSE is 'Provided by' CleanUpAddon it might be clearer to state 'interpreted by' since the addon changes its response based on the tag. When I originally decided to put these into the IPresentationEngine the hope was that they'd serve as hints to clients that wanted to provide their own Cleanup or Min/Max addons as to the tags they should respond to (allowing higher level code to work the same regardless of the addon set being used...).
(In reply to comment #10) > > Wim, rather than saying that NO_AUTO_COLLAPSE is 'Provided by' CleanUpAddon > it might be clearer to state 'interpreted by' since the addon changes its > response based on the tag. When I originally decided to put these into the > IPresentationEngine the hope was that they'd serve as hints to clients that > wanted to provide their own Cleanup or Min/Max addons as to the tags they > should respond to (allowing higher level code to work the same regardless of > the addon set being used...). I see. Say that somebody has the NAC tag assigned to a part-stack. If the "interpreted by" module is not available then the tag is ignored. Your idea is that the replacement addon for cleanup should interpret that tag if it is available. IMO, the interpreted-by cannot be added to the model element because we really don't know who is using it and for what reason. We can only make sure that we state the intention of the tag. How about we change provided-by to defined-by and move the NO_AUTO_COLLAPSE tag in this example to a higher class. The Apply_to should be changed to an array and renamed to Intended_Apply_to to allow the tags-completion engine to make an educated guess on what tags are intended to go where. e.g. Class: MTag String: Tag: NoAutoCollapse String: Descr: Will keep the part stack visible if the last part is minimized MApplicationElement[]: Intended_Apply_to: MPartStack String: Defined-by: Platform
Wim, I agree with most of what you're saying could you supply a patch of what you're considering doing ? I'm still a bit unclear as to how the format you are defining will appear in the code (as javadoc?). We can then go over the specifics...I have some issues with the way you describe the NAC but not the format particularly.
*** This bug has been marked as a duplicate of bug 394073 ***
Swapping roles.
*** Bug 394073 has been marked as a duplicate of this bug. ***
I've recently had to add a new 'key' in IPresentationEngine to support a mechanism to use the 'persistedState' field to be able to contain a custom renderer URI. While I was in there I was wondering if this could help... 1) Enforce at least some naming consistency where all constants that should be added to the 'tags' field end in _TAG and keys for persistent data end in '_KEY'... - or - 2) We could break these constants into separate interfaces if we want (i.e. UITagConstants / UIStateKeys) Constants specific to the rendering engine should stay where they are One good thing here is that it should be possible to introspect the interface (whichever way we do the above) and extract the values to be used by the model editor for the various fields...the presumption is that the class is available to the editor for introspection.
(In reply to comment #16) > 2) We could break these constants into separate interfaces if we want (i.e. > UITagConstants / UIStateKeys) Yes, I like that. So in short: . tags become a model element . tags have there own node in the model editor tree . Users can add tags to the model on the fly. . The model comes pre-populated with a number of known tags. . tags can be added from the outside . tags are associated with one or more model elements . tags have a description . tags can be autocompleted/selected I don't think we have to change the internals of the model at this point because the current String representation of the tag can serve as the key for the model element. It would just add some flesh to it and enables the model editor to work with it. Is this where everybody sees it going?
+1 for having constants in an interface for the available tags, which I think is Erics suggestion. I think Wim suggests a more complex enhancement. -1 for the suggestion to make tags model elements from my side. Tags are currently a really nice feature, very simple. Everyone can add them as strings to every model elements and write renderers or model addons to use them. This is very simple and powerful, I suggest we should not make the solution any more complex. Simplicity is an important feature IMHO.
(In reply to comment #18) I totally agree Lars. The only thing that I want to solve for the users of the model is this: "what tags are available? (and what do they do)" The thing I want to add is the ability to give the tags a "home". Like I said, there is not going to be a modification in the current structure, only a way to store the available tags. The Tags model element is just a helper class that stores information about the tags. Once the model editor starts, it can be populated with the constant elements from the interfaces Eric describes. Unlike with interfaces, elements can be added to that list.
Wim, I think that the tag's 'home' *is* the interface defining them...there should be no need to store these in the model anywhere (they're not 'descriptors' in the sense that MPartDescriptors are). Also it may be nice for the editor to be 'self-editing'...;-). I'd like to be able to extend the set of interfaces the editor introspects with others so that folks can support the tag equivalents of DSL's (Domain Specific Languages), same for Tags (whatever we do the result should be symmetric in how we handle these two interfaces).
Too much resistance.
Just started with e4 rap ... to find about the tricks that are possible with the resp. tags only - and finding these tags scattered within the depths of some forum or stackoverflow entries is really a P**A. :(
(In reply to Marco Descher from comment #22) > Just started with e4 rap ... to find about the tricks that are possible with > the resp. tags only - and finding these tags scattered within the depths of > some forum or stackoverflow entries is really a P**A. :( I think you mean PIT* ;)
(In reply to Marco Descher from comment #22) > Just started with e4 rap ... to find about the tricks that are possible with > the resp. tags only - and finding these tags scattered within the depths of > some forum or stackoverflow entries is really a P**A. :( Please add items to the wiki-based docs: https://wiki.eclipse.org/Eclipse4/RCP/Modeled_UI/Tags
