On Jan 11, 2014 4:08 PM, "lukash" <lukk...@email.cz> wrote:
> ... and attachments :( > > > On Sat, 11 Jan 2014 23:09:26 +0100 lukash <lukk...@email.cz> wrote: > > > Ok, > > > > after trying out John's rc, I definitely see there is a problem. This > > problem does not manifest in my rc, because it actually doesn't > > alternatively nest horizontal vs. vertical layouts without including a > > fixed one every other nesting level to set some constraints. > > > > John's patches only break my rc (in a rather minor way) by having > > _expand default to 'inside' which stretches the middle widget to the > > available space. > > > > But this is where the problem is. If nesting alternatively horizontal > > and vertical layouts, on the third level it may happen that a widget > > will take all space in its primary dimension (the 'in direction' > > dimension, eg. x for horizontal flex) and its parent will just pass it > > through in its secondary dimension (its the same dimension, but the > > parent has perpendicular direction). Then on the first level you > > suddenly have all the space taken by that widget. > > > > Since I probably didn't do a good job explaining it, lets use John's rc > > as an example. He has some third-party modules in it so I'm attaching a > > quickly hacked version that should work without sorting out includes. > > > > John has a main horizontal align layout, which has vertical flex on > > left and right. So far so good, but inside the right one he has another > > horizontal align layout. Which at the time of drawing will take up all > > horizontal space available, leaving nothing for the middle widget (a > > tasklist) in the main horizontal layout. (Because widgets in align are > > drawn in order first -> third -> second.) > > > > John's solution of this problem seems to be valid - change the fit > > function of these two layouts (or, it should be any layout that would > > eat all the space in current code) to take up only minimum necessary > > space it requires. Then, when it is drawn, it will still draw to all > > the available space. > > > > However, consider attached patch rc_patch.diff to John's rc. Run it > > and open a lot of clients. The tasklist will push the clock out. > > Therefore it actually might be better if the fit function for flex > > layout returned 0 and/or give it an optional min_size attribute. In > > fact, I've just found out this also happens with default config if you > > set its expand from 'inside' to 'none' (if you open a lot of clients > > they will push out the widgets on the sides). > > > This is by design. I see that with this patch only two sub widgets are given to the align layout. If you just got rid of the left layout and kept the center layout, you would have a left aligned layout with no problems. I can see how that might be slightly counter intuitive, but I think that it is the least complicated way to code it. If my patches are committed, I will put in a wiki-article explaining how to do just about anything with the align layout as it is after my patch. If you look at my full config with the 3rd party stuff added, you can see that I used this for the battery and wifi indicators. There is a center widget, expand is set to "inside" and then there is no top widget, so the center widget expands to take up the space that is never used by the top widget, and ends up itself being at the top with no issues. > > Regarding the new expand modes in align layout, why has the middle > > widget take up all the space in patch 0001? This broke my rc as > > mentioned above and so far I was unable to find a way to fix it, > > nesting 'none' and 'inside' align layouts didn't work... I haven't > > found what the problem is yet. And I'm not sure why the set_expand() > > was actually needed, when you changed it so that middle widget takes > > all the space? This solution feels weird to me. > > > Patch 0001 does not implement the set_expand function, and only affects the align layout per Uli's request. This, along with patch 0002 was the fix to my problem, as I only use the default expand mode in my config. I invented the other expand modes as I wanted the align function to be more flexible and allow for real centering. Both the non-default options will give a truly centered center widget. > > While messing around, I've also noticed that the 'none' expand mode > > acted really weird on my tasklist (it seemed to limit it to > > approximately half the available size or something). I didn't > > investigate it yet. I'm not sure I'll have much more time to fiddle > > with it... :( > > > I tried using the none expand mode on the task list, and the initial "odd" behavior is that it only takes up the space as needed. Upon further investigation, using the none mode and opening a lot of windows will push the clock and other outside widgets out of the way. This is how I designed it, as in the none mode, the center widget gets priority. I think that can be fixed without changing the layout code anymore using a different set of layouts, but I am not certain. I will look at this more, but I still feel that the patches are ready to commit as-is. > > cheers > > Lukas > > > > -- > > To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org. >
