Thank you for your suggestion. bin command is originally suggested and also implemented by Chris, so he should be the best man to answer your questions. But I will try to the best of my understanding.
Actually the Qt layout management is quite complicated since it has to provide some senisble and visually appeased layout (*) for different types of widgets. bin h/bin v are real Qt widgets. While bin z is a syntax element used by J to mark the extend of bin h/bin v. bin h/bin v itself will not request any space except for some margins. In other words, its minimum size is determined by widgets or other bin it contained. Each type of widgets follows a different size policy to request minimum space and now much extra space it will request. A bin s without any number followed is different from a bin s1 I guess that widgets without a stretch factor will not be given extra space if there are some other widget that have stretch factor set, but I'm not sure the size policy of a bin s which is a just filler. This means that s is equal to s0. So that the final layout of your example will be |xx a xxxx b c| 1/3 of extra space allocated to the first bin s, 2/3 to the second and the third got none. I also think that stretch factor applies to widgets inside a bin but not the bin itself. Well, bin z is a misnomer, it is not a bin buf a filler. One can change size policy of a widget to make it stop expanding, but this also depends on other widgets in the same bin. Say if all widgets do not expand, where will the extra space go? Anyways I guess each non-layout widgets will first be allocated enough space. The allocation of extra space to widget and filler is conducted in the second round and this starts from the outermost container (the parent form) and iterates inwards. (*) http://qt-project.org/doc/qt-4.8/layout.html Пн, 30 дек 2013, Don Guinn писал(а): > Thank you for this. May I suggest a few additions and a few questions. > > Make it clear that the "bin" itself does nothing other than activate the > bin commands. > > There was no mention to the default value of "1" for the bin and that a > number without being preceded by "s" is ignored. Actually, invalid > characters are ignored. And "s" (with preceding "bin") can appear anywhere > between tokens. This numeric value for "s" is interesting. Add up all the > numbers from all the "s"s inside the "v" or "h" and the space between > tokens separated by "s" is divided proportionally. Say you have three > tokens within a "v" or "s" block. > > bin hs1; > a; > bin s2; > b; > c; > bin sz; > > 1/4 of the extra space is put between the left margin and a, and c and the > right margin. Half the available space is put between a and b. And b and c > are stuck together as if a "bin s0" were between b and c. > > Questions: > > Are bin blocks tokens? Do they participate in stretching like other tokens? > > What are the rules for the stretching of specific tokens? If an "s" appears > within a bin block no token stretches, where if there is no "s" some tokens > stretch and others do not. How can I get some tokens to stretch and others > not when and "s" appears in a bin block? > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
