I have the layout in the picture below, it’s a vertical layout in which there are horizontal layouts. They are all setSizeUndefined(). The problem starts is when i want to align all the “Apply” buttons along with the “Close” button.
The normal layouting functionality of the subwindow that hosts these, makes the window as wide as the widest inner horizontal layout, but the problem is, that the rest of the horizontal layouts also snap to the dimension of their content, so i can’t align the inner “Apply” buttons.
It would’ve been nice that after the window determines it’s final size, i could tell the other horizontal layouts that are smaller to set width 100%, then align the “Apply” buttons. And this would be nicely done by a method on the subwindow layout, that since it already determined which inner layout is bigger (probably each sublayout compares its side with that of the parent (if it’s undetermined), and setting itself, it could also set a reference to it, and then the parent layout only needs telling the others to
fill 100% space , w/o doing a which is bigger algorithm all over again.
One solution (beside setting fixed size, which i don’t want), is to calculate myself which is bigger, and set the others to 100%, but the solution should belong to the layout which contains the others.
Anyone knows how to do this any other way?
P.S. The layouting starts looking bad like in the picture below because i set one of the horizontal layouts to 100% size.
This is a bug in my opinion, because the outer layer, which is set to undefined, is suppose to snap to widest inner control, not the fixed size one. The phases of layout calculation are inversed here.
I also find this feature useful. During development I had even simpler case in which it would be a life saver.
I had Vertical layout with buttons. The layout had to have undefined width to scale to its content, but it would be best if the buttons were all the same width, without setting it explicitly.
I suggest you create a new enhancement/defect ticket in the
Trac , so we the dev team can start pondering what to do about it. I suspect nothing will be done before version 7, but nevertheless, the issue is worth documenting.
Ok I will, it’s not urgent for me, but i will need that sometime. This is also not a sole invention of mine, I think i came upon something like this in another GUI framework, probably .NET’s WPF, and I mean where the rendering and calculation of the size of the components occurred in distinct phases, on which you could but in and do something (probably overriding paint() or something, i never done something complicated at the time to remember.
Until i make the ticket (probably at the end of a day’s work when I’m wasted ), I’ll save the probable steps here:
The steps are (or the philosophy is, how i would put it):
there’s need for simplicity, and come to think about it, proper layout behavior should be default, as i explain below, but a boolean can also be set to disable the functionality taking 100% space.
as i haven’t studied the Vaadin internals, i believe that a container holding a collection of controls in a layout should have a method that calculates the widest, and holds the value in a separate field, with which new control sizes are compared when dynamic layouting takes place. Only that field needs be communicated to resize a parent, and eventually, an event could be registered if not already.
the different stages i spoke about should be internal to that functionality, as i think
undefined > defined > 100% etc. should be the natural order, the longest between defined and undefined is evaluated first, then 100% sized controls; furthermore, the undefined and the defined evaluations could be done in parallel, only returning the biggest from the two categories with a simple evaluation, like: two threads, one for each category evaluates the each of the two collections, dumping the return in a private field, through a synchronized setter, such as if the existent value is smaller, set, if not, ignore, and set a binary cycle counter to indicate when the rest of the stages should start. The setter can then do the 100% evaluation after the undefined/defined field is set twice (to complete a cycle), or, at this point perhaps, it can be interrupted by another process that sets the layout, restarting the counting variable that maintains the defined / undefined cycle). In parallel with the 100% setting of the controls, the rest of the undefined controls that haven’t moved to 100% could be set now in parallel, before a repaint takes place.
So in short:
*thread1 evaluates undefined controls
*thread2 evaluates defined controls
*____they set a synchronized evaluator setter as they return, which sets a ‘widest’ attribute, and maintains a cycle variable, determining whether both threads 1 and 2 returned or not, so stage 2 can begin
*depending on cycle counter variable, stage 2 begins
*____thread 3, setting 100% components
*____if(undefined components should take 100% of the remaining space)
*________thread 4, reset their size to 100% perhaps, or simply set their size to the ‘widest’ attribute
And a relevant picture; after undefined would take 100% remaining space and i would set Apply button alignment to right, they should all be aligned with the Close button:
), I’ll save the probable steps here: