Community
Participate
Working Groups
Created attachment 229700 [details] Render the part stack below the part if the "StackBottom" tag is set for a part stack
Can this be address in M7? Adds nice flexibility to the PartStack.
If it speeds up the process, I can create a gerrit ticket instead.
Comment on attachment 229700 [details] Render the part stack below the part if the "StackBottom" tag is set for a part stack Did you loose the SWT.BORDER on purpose?
Sorry, it is still there.
Folks, this is something that should most likely be handled by CSS...I'll have to check with bogdan tomorrow to see if it's already there and, if not, to make this attribute stylable. We should not in general be using tags to *directly* control the renderers. A good example of the pattern we want is in the new 'busy' handling. We add / remove the 'busy' tag from views as needed but it's the CSS that determines what the response is (italic, bold?, red?....).
Eric, AFAIK you can't archive this via CSS as the stylebit is passed to the CTabFolder during the construction and cannot changed at runtime.
I'm fairly sure it's doable, let's see what Bogdan has to say...note that I wouldn't really think that this styling has to be 'dynamic' in the sense that the 'busy' (italic...) feedback has to be, do you see a need for it to change after the stack is constructed ?
I see no need to change it after construction hence the suggestion to do it via the renderer. I think the renderer is the right place, IMHO it is similar to the "NoAutoCollapse" tag for a stack.
Lars, the reason for doing this in CSS and *not* baking it into the renderer is that CSS allows for much finer control over when the attribute gets applied (i.e. someone could want to have the 'normal' stacks have their tabs on the bottom and the tagged ones on top). if the tag were, for example 'alternateTabPos' then you can produce CSS which handles both scenarios. Note that it also allows us to (in the future) perhaps have left / right as well. I'm basing this off of the work that went into the 'busy' part handling. The idea was to separate 'intent' form 'implementation'; the adding/removal of the 'busy' tag is intent (show this part as busy / not busy) while the CSS is left to define how that should appear on the screen. While we've adopted a convention of using italics other products may want to change font boldness, size, color...had we baked this into the renderer we'd only ever be able to support italics. This is one of those things that we really should have a full discussion about during one of the e4 meetings...it *is* an interesting and important question.
Eric, via tags you can have the same scenario you describe: i.e. someone could want to have the 'normal' stacks have their tabs on the bottom and the tagged ones on top. I would be happy if CSS could handle that but my concern is that if we do this via CSS that the user would expect a dynamic behavior. Also tags are IMHO not API so we could always replace the tag later if we get a nice CSS solution.
Lars, anything we publish to the user community as being the way to accomplish something *are* API, at least implicitly. BTW, the CSS solution doesn't necessarily imply that we wouldn't need the tag. The tag represents a hint to the CSS engine for those cases where CSS alone isn't enough. For example...using CSS I can fully describe that I want any stacks inside the MArea to have their tags on the bottom. While we *could* also have explicit CSS based on a stack's id it is likely easier to supply the tag in this case for the CSS naive (which is most of us...;-). The main point I'd like to stress here is that using CSS whenever possible is an advantage, not a liability. It's extremely powerful as is demonstrated by what's possible on web pages. The corollary is that the actual renderer should only set Control's attributes when clearly necessary so as to not interfere with the CSS handling.
Eric, if technical feasible I'm +1 for the CSS solution. Is it?
Just talked to Bogdan who assures me that it's easily done. He's going to take a stab at getting the CSS code into M7 but at worst it'll show up in RC1.
Cool, thanks.
Moving to RC1 since even if the SWT changes make it into M7 there is other work that needs to be done / looked at such as CSS changes...
FWIW: Updated version of the initial patch https://git.eclipse.org/r/#/c/17885/
Markus, thanks for the updated patch. I'd still far prefer that we do this through CSS, we do have existing examples of this pattern; see org.eclipse.e4.ui.css.swt.properties.custom#CSSPropertySingleSWTHandler Daniel, I see this is marked for M7. Since it's really an API change could you move it up a bit ? Do you see any problem with making 'tabPosition' style-able through CSS ?
Thanks Markus for the bug report, we solved it in Bug 429728, allowing to set all SWT Stylebits. Marking this one as dup *** This bug has been marked as a duplicate of bug 429728 ***
