Hi,

On 05.01.2014 00:56, John Kha wrote:
> On Fri, Jan 3, 2014 at 10:52 AM, Uli Schlachter <psyc...@znc.in> wrote:
>> On 02.01.2014 09:25, John Kha wrote:
>>>> Start awesome with the default config and open any client. The tasklist 
>>>> entry
>>>> for this client will only be as wide as the name of the client. It will not
>>>> cover all of the align layout's middle space.
>>>>
>>>> This is because awful.widget.tasklist uses a flex layout and that layout 
>>>> now
>>>> asks for less space. The align layout centers the middle widget in the 
>>>> space
>>>> that is left (and only assigns it as much space as it asked for).
>>>>
>>>> Ideas?
>>>
>>> Patch 0001
>>> If the draw function ignores the fit results for the middle widget,
>>> the expected behavior is back.
>>>
>>> Patch 0002
>>> Makes the draw function optionally start with the middle widget and
>>> force the outside widgets to expand or contract to take up the
>>> remaining space ("outside" option) or just draw the outside widgets to
>>> their requested size in the remaining space ("none" option). The old
>>> functionality, drawing the first and last widgets, then expanding the
>>> middle widget to take the remaining space is still the default
>>> ("inside" option). The attached screenshot was made by pasting the
>>> attached align_test.lua into the default rc.lua.
[...]
>> Back to your patch:
>> I am mainly trying to convince myself that both patches together don't change
>> the default behavior and old code continues to work. But things turn out to 
>> be
>> complicated and I don't have any good ideas on how to simplify this.
>>
>> One thing I noticed is that the "centering" behavior of the old code isn't
>> really back. The only expand mode that centers the middle widget is "none", 
>> but
>> the default is "inside" which should be the same behavior as after your first
>> patch. I think...
> 
> The "inside" behavior ends up doing the same thing as your original
> code, albeit in a slightly different way.
> 
> The old code:
> 59             w, h = width, size_limit - size_first - size_third
> 60             local real_w, real_h = base.fit_widget(self.second, w, h)
> 61             x, y = 0, size_first + h / 2 - real_h / 2
> 62             h = real_h
> 
> This tells the center widget to try and fit itself into the space left
> over from the first two and then centers it in the remaining space. If
> the widget doesn't fit in the remaining space, it will be centered in
> that remaining space. I couldn't actually think of a place where that
> would be useful, so I just rewrote it to ignore the fit function, and
> to always draw the widget in the entire space, leaving it up to the
> sub widget how exactly to do that. After changing the align and flex
> layouts, which were previously coded to fit into all of the available
> space no matter what, I thought the best way to restore the default
> behavior was to just make the draw function ignore the fit function
> for the middle widget and expand to take that space. So, in that way,
> the old behavior is only the same when a fit or align widget was the
> middle widget.
> 
>> Also, previously, the widget was centered in the space that was left over 
>> from
>> the first and third widget and now it is centered inside of the align layout.
>>
> 
> That was my intention. It is to allow people to align something
> centered in the available space, something that was not easily doable
> before. The two other cases primarily serve that purpose. The "none"
> mode obeys all the fit function returns from the sub-widgets, so in
> that way, it is the closest to the old code.
> If it is desired to put something centered in the remaining space,
> that can be done too. The outer expand mode would be, "inside" and the
> center widget would be another align widget, expand mode of "none",
> and the only sub widget being the middle widget.
> The "outside" mode also centers the middle widget, but it forces the
> other two widgets to expand to fill the remaining space.
> 
> Overall, I think the slightly changed behavior is more useful and less
> confusing, though the implementation might be a bit confusing.

I just remembered that we are playing layout-ping-pong. Your "inside" mode
brings back the original behavior of the align layout. This was then changed in
the following commit to the current behavior (CC'd the author):

commit 8560de597c3a1f349907e6ef94cf343c86f63c30
Author: Lukáš Hrázký <lukk...@email.cz>
Date:   Sat Jan 5 16:12:50 2013 +0100

    wibox.layout.align: make the middle widget really centered

    Centers the middle widget in the align layout in the remaining space
    left by the widgets on the sides.

    Signed-off-by: Lukáš Hrázký <lukk...@email.cz>
    Signed-off-by: Uli Schlachter <psyc...@znc.in>

I also found the corresponding mailing list threads (there was a v2 of the 
patches):

http://www.mail-archive.com/awesome-devel@naquadah.org/msg07777.html
http://www.mail-archive.com/awesome-devel@naquadah.org/msg07855.html

Lukáš: Could you take a look at these patches and comment on the new behaviors?
After all, this would likely break your config by reverting the above change.

I would provide links to them in the archives, but apparently gmane has DNS
issues and mail-archive didn't get the patches. Ask if you don't have the 
patches.

[...]
>> default expand mode inside of draw(). Could rename self.expand to 
>> self._expand
>> (marking it as something like a private variable), call
>> self:set_expand("inside") from the "consutrctor" and call self.emit_updated()
>> inside of set_expand() (this last thing ensures that a redraw gets 
>> scheduled)?
>>
> 
> Hopefully the attached patches are what you are closer to what you are
> looking for. (0001-0003)

Thanks, I do think that this stuff is easier to understand this way.

(Memo to myself: The docs for :draw() are just wrong and those return values
will just silently be ignored by the caller anyway. Should clean that up before
committing. It's my own mistake!)

>> I wonder if it would make sense to split these patches up differently. One 
>> patch
>> would only change one layout, because the changes to the other layouts are
>> pretty much unrelated.
> I put the patches the way they are because the first one more or less
> does the same thing to the flex and align layouts. The 2nd patch adds
> functionality to just the align layout. From my perspective, the first
> patch is a fix to the current behavior. The second adds some features,
> so it is a separate patch. Attached are the patches split out the
> changes to the two layouts, this has been a great lesson in
> manipulating git.
[...]

Sorry for being so annoying to work with. :-)

I don't have the time right now, but I should get this done this week. I will
just call this "giving Lukáš some time to complain before I merge this", even
though that's not really true.

Cheers,
Uli
-- 
"In the beginning the Universe was created. This has made a lot of
 people very angry and has been widely regarded as a bad move."

-- 
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.

Reply via email to