Community
Participate
Working Groups
Build Identifier: M20110912-1510 As far as I know, one can put integer numbers in the field Container Data of the children of a PartSashContainer. They determine the _relative_ sizes of these children of the parent PartSashContainer. (1) Now I would like to set an absolute size constraint on one child, minimum or maximum size (in my case maximum size). The other children should take up the remainder of the space. How can one do this? (2) There seems to be another problem even with relative sizes: One can set the relative size of one child to 5%. If the application is started, the child gets this 5%, even if the window is maximized. However, if one tries to change the size with the sash only a tiny little bit, the size of the child jumps to 10% (estimate). Afterward one cannot set the size of the child below this (estimated) 10%; above that limit, one can change its size at will (well up to 90% at the upper end, in case the parent has two children). In other words, there is a limit on the relative size. Reproducible: Always
Any solution?
The sash container uses integers to maintain the ratios between its elements. The code will attempt to maintain this as well as maintaining the *total* of the weights. I think your issue for the %'age changes is that you are starting with a total that is too small. For example if you simply use weights of '9' and '1' to be the percentages then the only choice the sash has would be 10% increments. Try using 1000 / 9000 instead and you'll give the sash container code enough 'space' to be able to adjust the sashes down to the pixel level. As far as setting min or max values goes I think it's a good idea. First cut would be two persistent data 'keys' that can be used to store the *percentage* value for either min or max. I'd prefer to use the percentage since it's independent of the actual integer range being used (see above). There is already code in the SashLayout that restricts the range to a fixed percentage so this should be relatively straightforward to implement (patches welcome! ;-).
Thanks a lot Eric for the detailed explanation. My actual requirement is to show a branding image just below the toolbar, the model i was trying is the below one PartShashContainer -->Part (to show branding image) -->PartStack ---->Part ---->Part Want to fix the height and show the complete image irrespective of height of the window to the maximum possible.
Siva, no promises that this will work in your situation but you might try the following: Make an MToolControl and add it to the top trim *at the end*. Have the implementation construct the 'branding image' at whatever height you wish Now, also have the implementation always set its *width* to match the shell's client area's width (add a resize listener to the Shell). This will cause that control to 'wrap', putting it below the rest of the top trim's entries (i.e. the main toolbar).
I implemented a patch for absolute sizes. Container data can be in one of the following formats. <empty> Integer relative percentage (legacy) Integer <optional spaces> '%' relative percentage Integer <optional spaces> 'px' absolute size in pixels Relative sizes take up the remaining space after absolute sizes are allocated. If a sash is resized, the absolute or relative values are adjusted but still kept as absolute or relative. It would be nice to specify min/max constraints in the configuration string as well, but I will leave that to a future enhancement. It is undetermined what the impact will be on other renderers besides SashRenderer/SashLayout; there very well may be a better solution.
Created attachment 246056 [details] screenshot: relative and absolute settings in the model
Created attachment 246057 [details] screenshot: before resize
Created attachment 246058 [details] screenshot: after resize
Gerrit Review: https://git.eclipse.org/r/#/c/31777/ This patch does not yet contain min/max code but allows absolute sizing by using a 'px' suffix
For min and max limiting, I am thinking allowing any combination fixed or relative values using a terse CSS-like syntax. examples: 10%;min:5%;max:50% min:50px;max:500px min:20px;50%;max:80% default:40%;min:5px
Are you planning to support a fixed size directly? Setting min / max to the same value would work but maybe having explicit support would help.
(In reply to Lars Vogel from comment #11) > Are you planning to support a fixed size directly? Setting min / max to the > same value would work but maybe having explicit support would help. min:100px (same as 100px;min:100px) the part will be set to 100px, will only grow if sash is dragged, and cannot get smaller. min:100px;max:100px (same as 100px;min:100px;max:100px) this is fixed size I could certainly add this attribute to the spec: fixed:100px (can't be resized) fixed:50% (only resized when shell is, and always 50 weight) It would be trivial for us to implement, but more rope for the end user... I was not too pleased with how the UI responds with max values set. The current code handles sash dragging by adjusting adjacent parts. If one side maxes out, the sash appears to be frozen. There is no visual indicator, and it makes for a seemingly unresponsive UI. Min constraints are much more intuitive as to why the sash cannot be moved. Flashing the part border or changing the appearance of the sash or cursor are options.
I suggest using the terms Fixed and Relative for the 2 sizing modes. Relative would be a weight and fixed would be pixel setting. This makes more sense than using absolute and relative.
After using the current patch in the field, I have changed my approach. This new approach is based on 3 concepts: 1. Initial size can be expressed in weights or pixels. 2. Separate parameter specifies whether or not the part resizes when the parent resizes. 3. Minimum and maximum constraints are not a good idea and have been removed. The initial size can be set as an absolute or relative value, independent of the resize mode of the part. This was the major flaw in my initial approach. A part can have one of two resizing modes: Weighted and Fixed. A fixed resize mode part only changes sizes when its neighbor sash is moved. A weighted resize mode part changes sizes when its parent is resized, relative to its weighted siblings. The resizing mode should not change when a part is moved to another stack. The user should be able to change the resizing mode. I created an addon that adds a tool item each parts toolbar for this purpose; There are obviously other approaches to this. Every sash container must have at least 1 weighted resize mode part to consume remaining space in the container. The system will convert a fixed resize mode to weighted resize mode if needed. The size specified (either as a relative weight or absolute size) only applies to the initial display of the part. When a part is resized, the size will be adjusted based on the mode. When a part is moved to a new sash container, the size will be set based on the system default part distribution settings. Minimum and maximum settings make the UI seem unrepsonsive. They also do not apply when the part is moved to a sash with a different orientation (unless their parameter can specify both width and height). This functionality will be commented out in the patch, to be reintroduced as an experimental feature if requested.
Created attachment 246798 [details] screenshot: before resize (with toolitem)
Created attachment 246799 [details] screenshot: after resize (with toolitem)
Is https://git.eclipse.org/r/#/c/32189/ still the correct Gerrit review?
(In reply to Lars Vogel from comment #17) > Is https://git.eclipse.org/r/#/c/32189/ still the correct Gerrit review? Steven AFAIK you have an updated version of this. Could you point me to the latest Gerrit review?
Once you have this working you should check to make sure that incompatible situations are handled correctly. For example: - if both parts have a min size and there's not enough space what happens - if both parts have a max size and there's too much space This is a nice feature to have but can cause issues when used in odd combinations. This isn't a problem as long as the various situations are covered in the docs and nothing catches fire...;-).
What is the use-case for this? Understanding the use-case is necessary to make sure any new API here serves its intended purpose. The old (pre-E4) PartSashContainer supported minimum sizes, maximum sizes, and fixed height/width children. At the time, the purpose of fixed height/width children was to prevent views on the edge of the editor are from resizing when the window was resized. In order to handle this use-case well, the behavior of having a fixed or relative size can't be baked into the layout -- it has to be computed based on what sort of other views are present in the layout (ie: is there an editor in one of the other children). That is, the views would prefer fixed sizing but if there was no editor on the other side of a sash, the views would revert to relative sizing. I agree that min/max constraints aren't a good idea unless we have a strong use-case for them. In Eclipse 3.x, min/max sizes were needed to support a "minimized" mode for view stacks and it needed to support wrapping tabs, which brought along with it a bunch of extra limitations. Looking at the attached patch, I see it's doing some regex matching inside the layout code. We probably shouldn't do that, since layouts need to be very fast. It may be better to cache the quantities we need as ints/bools (for example, an isFixed boolean and an int size) and only update them when they change.
My use case: I have a static control that is just a label (kind of) and I want it on top of the Part Stack. Depending on initial window if I use weight it will be either cut off or have lots of extra unneeded space. Setting a static size will fix that. I cannot think of a use case where max size is needed though.
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
Re: comment 21 This is PartSashContainer, though... so your "control" is actually a view or editor, or are you doing a funky RCP thing that is using a PartSashContainer without the rest of the workbench? Can your control appear in a stack with other views or is it a standalone view that can't be stacked with?
boolean "fixed" and integer size would be a good idea. Our use-case is what Stefan Xenos wrote in comment:20 - we need fixed height/width children to prevent views on the edge of the Application from resizing when the window is resized. Our users should be able to define the size of the right Part of the Application (which is DetailsPart) and this setting should not change if the window size changes. The left Parts of the Application are designated to use as much space as available. This is an actual problem for us and our customers and we found no (good) workaround yet.
Is there any update on this isse? I also have demands for fixed sized controls inside PartSash. We use e$ Model editor to define views, and some of the views contains a Toolbar like control that should as Stefan Wild described, not resize, but the rest of the parts should take the extra space.
(In reply to Christoph Laeubrich from comment #25) > Is there any update on this isse? > I also have demands for fixed sized controls inside PartSash. > > We use e$ Model editor to define views, and some of the views contains a > Toolbar like control that should as Stefan Wild described, not resize, but > the rest of the parts should take the extra space. I think Steven pushed a patch got Gerrit a few years ago. If you have interested in reworking it, I can search for it.
Sure why not :-)
(In reply to Christoph Laeubrich from comment #27) > Sure why not :-) https://git.eclipse.org/r/#/c/32189/
Yep, we pushed a fork with a working implementation back in the day...
(In reply to Steven Spungin from comment #29) > Yep, we pushed a fork with a working implementation back in the day... You should return at some point, we are now much more agile. You would like it. :-) (yeah, I know, no chance, you are happy with Kotlin and the like...) ;-(
Hey Lars, I miss you guys, but JetBrains has wooed me by sending free stuff. LOL. It's great to hear you have honed the development process! I'd offer more help on this issue, but it was so long ago; IIRC there was a peculiar messaging architecture that was the major hurdle in getting this off the ground.
