Community
Participate
Working Groups
There should be a model tag that prevents the shell from being able to be resized. Similar to a dialog, the shell should only have the style tags CLOSE & TITLE. Specifically when opening a workbench window with only an MPart (no stack as in the case of a login window) preventing the user from being able to resize the window would be important.
Created attachment 225536 [details] shellNoResize Tag Proposed Patch.
Looks good to me...Joseph, I'll be getting to these once 4.2.2 ships...
Thanks Paul. Note that the expected fix will be to create the shell without the sizing trim if the tag is set. You won't be able to change this once the shell has been rendered (but it will still listen to changes in the 'x', 'y', 'width' and 'height' fields even if the tag is set.
@Eric - Would it be better / easier if I pushed the patch to Gerrit for review? Just as a note to comment 3, currently it is not possible to dynamically update the size of the window during the call to @PostConstruct. While you are able to inject the MWinodw element and change the size, the notification event is not processed. The model will update after the shell is set to the original size for the window, and there isn't an explicit repaint event that will trigger the resize. If there is, it will look choppy (ie. you can see the window resize). Moral of the story, for now, be sure to set the appropriate size in the model fragment.
Joseph, I'm going to re-purpose this defect in order to make it more general. Rather that a tag specific to this particular style bit I'm looking at allowing the use of a new 'persistedData' key "STYLE_OVERRIDE". For SWT based renderers (specifically the WBWRenderer initially) the expected 'value' would be the string version of the integer you get by OR'ing the various style bits together. This should allow about as complete control over the shell's initial state as is possible. At the same time I expect to move the tags in the WBWRenderer (ShellMaximizedTag & ShellMinimizedTag out to the IPresentationEngine, making them API so you can define the initial display state of the shell. How does this sound ?
Note that going forward we may find uses in other rendering situations for STYLE_OVERRIDE....
*** Bug 410787 has been marked as a duplicate of this bug. ***
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0f0fbd2062cb6980a5d333534aaa4fa6d1d72e05 This adds two new Tags and a persistentData key into the API. The new tags, WINDOW_MAXIMIZED_TAG & WINDOW_MINIMIZED_TAG are used to define the initial min/max state of the window. The new persistent data key 'STYLE_OVERRIDE_KEY' allows for a contract between a renderer and someone using this key on a ui element. So far I've only implemented the code to respect the new overrides in the WBWRenderer but there you can simply define the SWT flags you want in an 'int' and store the string version in the MWindow's peristentData map. Two things to think about: We can use the same key on different platforms (i.e. the value/format of the string is a contract with the renderer that will generate the widget and need not be an int...). Are there other create-time only style bits we might want to override on other widgets (Toolbars...) ?
The feature look good, IIRC my initial intention for the feature was to provide some kind of "dialog" type control over the window. As far as other uses go, the style overrides could be handy with dialogs too. Where I can create an MDialog with a style override of File | Open and it would open the native (swt) File dialog. But then again, I don't even recall if Dialogs are in or out for 4.4. Plus, there would have to be a way to prevent adding any child elements to the dialog. So I'm not too sure how we could make that all jive, but it just seems goofy not have some kind of model representation for the native style dialogs. (And of course there is the issue of retrieving the user input from the dialog as well) Moral of the story I think we will be able to find uses for the style overrides JD
