Re: [Draft] Introduction of Widget Layouts
At 1248034560 time_t, Gregor Best wrote: Okay, first bug reports are coming in, and I love that :) Uli reported that awful.widget.graph and awful.widget.progressbar don't take the layout parameter, a thing I indeed missed. A fixed version is attached. I'm also writing a patch for konius problem atm, I'll send that later That one pushed. You did not finished the other one, it seems? Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
On Mon, Jul 27, 2009 at 11:08:10AM +0200, Julien Danjou wrote: [...] That one pushed. You did not finished the other one, it seems? [...] Didn't have the time, sorry. I'll work on it tonight. -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpeJDrLF8Ks0.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gregor Best wrote: Okay, first bug reports are coming in, and I love that :) Uli reported that awful.widget.graph and awful.widget.progressbar don't take the layout parameter, a thing I indeed missed. A fixed version is attached. I'm also writing a patch for konius problem atm, I'll send that later I told you I would break it... :P Oh and now I experience koniu's problem, too. Uli P.S.: WTF? Why is the SMTP port blocked here? :( - -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKZCJHAAoJECLkKOvLj8sG2IgIAMxCQyN+hZAcfqfChG7NrCXE ZQCG+HWDn8ZxurivBx8LtYPLx5NEj/izwm4hZcFZLO4UQhT3RgaVG8CsJAHY/eSD 2FMZOT4YRBGauUtg3iqIU4M/2n4ziN2mBdhTR7yQCPsvQtKgMd4cNGUoahp19eG3 qMViSRlx9ZvQIk9ig3OaumoLxVPAW3fVjOkFYyhjqQC2VUSg3Yc2Oa0q+ergqM0d 9tlikd84VfQETEM6etxojvY6CrEOtu3J8PLaiEVkA7rCpTL4Pg8DD6nDkQSve5Tz vGuZPo7ZFLPa5+RO0k1mb2fXcPD+Qo0Beei9ZcUL2RF15tG0hKDisPicD2LmftU= =IgC/ -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
On Sat, Jul 18, 2009 at 04:02:13AM +0100, koniu wrote: I've updated to see what its like and apart of my widgetbar being a mess, but I have a problem with the naughty patch which renders it unusable under certain condition: W: awesome: event_handle_key:549: error running function: /usr/share/awesome/lib/naughty.lua:385: attempt to perform arithmetic on field 'border_width' (a nil value) that should be s/config.border_width/border_width: lib/naughty.lua.in | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/naughty.lua.in b/lib/naughty.lua.in index ce17024..7ed0769 100644 --- a/lib/naughty.lua.in +++ b/lib/naughty.lua.in @@ -380,17 +380,17 @@ function notify(args) -- position the wibox if iconbox and iconbox.image.height textbox:extents()[height] then -notification.height = iconbox.image.height + (2 * config.border_width) +notification.height = iconbox.image.height + (2 * border_width) else -notification.height = textbox:extents()[height] + (2 * config.border_width) +notification.height = textbox:extents()[height] + (2 * border_width) end -notification.width = (iconbox and iconbox:extents()[width] or 0) + textbox:extents()[width] + (2 * config.border_width) +notification.width = (iconbox and iconbox:extents()[width] or 0) + textbox:extents()[width] + (2 * border_width) if capi.screen[screen].workarea.width notification.width then -notification.width = capi.screen[screen].workarea.width - (2 * config.border_width) - (2 * config.padding) +notification.width = capi.screen[screen].workarea.width - (2 * border_width) - (2 * config.padding) end if capi.screen[screen].workarea.height notification.height then -notification.height = capi.screen[screen].workarea.height - (2 * config.border_width) - (2 * config.padding) +notification.height = capi.screen[screen].workarea.height - (2 * border_width) - (2 * config.padding) end BUT when i corrected that (so it shows some notifications), after displaying one it seems to segfault. havent investigated closer, but i'm wondering if it works for other people. [...] Hmm, I'm using that code for about 2 months here without a problem... I'll investigate. -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpPf8VFYPOAT.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
Okay, first bug reports are coming in, and I love that :) Uli reported
that awful.widget.graph and awful.widget.progressbar don't take the
layout parameter, a thing I indeed missed. A fixed version is
attached. I'm also writing a patch for konius problem atm, I'll send
that later
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
From 47435fd62520bb447d52a1814de43b2824593245 Mon Sep 17 00:00:00 2001
From: Gregor Best g...@intepi.net
Date: Sun, 19 Jul 2009 22:01:15 +0200
Subject: [PATCH] widget.graph/progressbar: add layout parameter to new()
Signed-off-by: Gregor Best g...@intepi.net
---
lib/awful/widget/graph.lua.in |3 +++
lib/awful/widget/progressbar.lua.in |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib/awful/widget/graph.lua.in b/lib/awful/widget/graph.lua.in
index 4f0ff91..4802a0d 100644
--- a/lib/awful/widget/graph.lua.in
+++ b/lib/awful/widget/graph.lua.in
@@ -10,6 +10,7 @@ local math = math
local table = table
local capi = { image = image,
widget = widget }
+local layout = require(awful.widget.layout)
--- A graph widget.
module(awful.widget.graph)
@@ -221,6 +222,8 @@ function new(args)
graph[set_ .. prop] = _M[set_ .. prop]
end
+graph.layout = args.layout or layout.horizontal.leftright
+
return graph
end
diff --git a/lib/awful/widget/progressbar.lua.in
b/lib/awful/widget/progressbar.lua.in
index 2f15145..652a949 100644
--- a/lib/awful/widget/progressbar.lua.in
+++ b/lib/awful/widget/progressbar.lua.in
@@ -9,6 +9,7 @@ local ipairs = ipairs
local math = math
local capi = { image = image,
widget = widget }
+local layout = require(awful.widget.layout)
--- A progressbar widget.
module(awful.widget.progressbar)
@@ -171,6 +172,8 @@ function new(args)
pbar[set_ .. prop] = _M[set_ .. prop]
end
+pbar.layout = args.layout or layout.horizontal.leftright
+
return pbar
end
--
1.6.3.3
pgp3541j43Iox.pgp
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
On Thu, Jul 16, 2009 at 10:52:36AM +0200, Julien Danjou wrote: [...] I don't think promptbox need a layout since there's only one widget inside the returned table. (same remark for the awful.widget.promptbox patch). [...] Well, but that poses some usability problems. If we rely on the default layout for the promptbox, it will always be placed at (0,0), i.e. it will be aligned to the left edge of its available place. If a user now wants his/her promptbox to be aligned to the right side of the available place, they'd have to set the layout after creating the widget. This way is just bit more user-friendly, I think. [...] Isn't there a way (you can say no) to merge the awful.widget.layout.default and the C code doing the same thing? (I ask because I can't think a way right now). [...] If I could've, I would've :) No really, I tried to come up with a way which isn't totally confusing, but I couldn't think of anything. I'd say we leave it as it is, and if someone finds a good way later, we can just remove awful.widget.layout.default. As that's not supposed to be explicitly set by users anyway, the patch would be relatively low impact. Feedback welcome, once again :) Btw.: have fun at the beach and don't let the jellyfish sting you :P -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgp08bLaW5P9A.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At 1247840226 time_t, Gregor Best wrote: Btw.: have fun at the beach and don't let the jellyfish sting you :P Seems I really need some beach time yeah, just got what you meant with your explanation on IRC. Thanks for your losing your time with me. :) I've merged the whole patchset. Congrats, and much thanks for this huge works. See you next weeks fellows, Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // This is the end of my signature. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
I've updated to see what its like and apart of my widgetbar being a mess, but I have a problem with the naughty patch which renders it unusable under certain condition: W: awesome: event_handle_key:549: error running function: /usr/share/awesome/lib/naughty.lua:385: attempt to perform arithmetic on field 'border_width' (a nil value) that should be s/config.border_width/border_width: lib/naughty.lua.in | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/naughty.lua.in b/lib/naughty.lua.in index ce17024..7ed0769 100644 --- a/lib/naughty.lua.in +++ b/lib/naughty.lua.in @@ -380,17 +380,17 @@ function notify(args) -- position the wibox if iconbox and iconbox.image.height textbox:extents()[height] then -notification.height = iconbox.image.height + (2 * config.border_width) +notification.height = iconbox.image.height + (2 * border_width) else -notification.height = textbox:extents()[height] + (2 * config.border_width) +notification.height = textbox:extents()[height] + (2 * border_width) end -notification.width = (iconbox and iconbox:extents()[width] or 0) + textbox:extents()[width] + (2 * config.border_width) +notification.width = (iconbox and iconbox:extents()[width] or 0) + textbox:extents()[width] + (2 * border_width) if capi.screen[screen].workarea.width notification.width then -notification.width = capi.screen[screen].workarea.width - (2 * config.border_width) - (2 * config.padding) +notification.width = capi.screen[screen].workarea.width - (2 * border_width) - (2 * config.padding) end if capi.screen[screen].workarea.height notification.height then -notification.height = capi.screen[screen].workarea.height - (2 * config.border_width) - (2 * config.padding) +notification.height = capi.screen[screen].workarea.height - (2 * border_width) - (2 * config.padding) end BUT when i corrected that (so it shows some notifications), after displaying one it seems to segfault. havent investigated closer, but i'm wondering if it works for other people. kk -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
Hi Gregor,
At 1247706265 time_t, Gregor Best wrote:
Everything seems fine to me! I just have a couple of question:
for s = 1, screen.count() do
-- Create a promptbox for each screen
-mypromptbox[s] = awful.widget.prompt({ align = left })
+mypromptbox[s] = awful.widget.prompt({ layout =
awful.widget.layout.leftright })
I don't think promptbox need a layout since there's only one widget
inside the returned table.
(same remark for the awful.widget.promptbox patch).
Isn't there a way (you can say no) to merge the
awful.widget.layout.default and the C code doing the same thing?
(I ask because I can't think a way right now).
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// And thinking so much differently.
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
Oh, I forgot to mention, the two flavors of the vertical layout have been merged into one. The layout is now called awful.widget.layout.vertical.flex, as that's essentially what it is (a flex vertical layout) -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpHL0Gp5l09h.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
On Mon, Jul 13, 2009 at 01:55:55PM +0200, Julien Danjou wrote:
[...]
{
layout = rightleft,
mytasklist,
}
with mytasklist.layout = flex
would not align the tasklist on the right using flex layout for all
elements?
[...]
See bottom :)
[...]
I can't see why.
If you have (pseudo code):
p = progressbar()
g = graph()
{
p,
g,
layout = topdown,
}
p and g are tables with no layouts, so the default function (render all
elem inside the table on top of each other (z-axis)). Basically, since
there's only one drawable widget in p and g, this is not a problem.
Then p and g (i.e. their only widget inside) are drawn top to bottom.
I can't see why you need to inherit layout. In the case I used above,
this is even useless, since there's only widget in p or g to draw.
Can you provide me an example where this IS required? :)
[...]
I can provide arguments why your idea is suboptimal :) At the moment,
from the C point of view we simply have a table with, say, 20 widgets
(including things like tag- and tasklists). After calling the layout
function, the C code expects a Lua table with 20 elements on the stack
top, where the association w[i] = g[i], where w is the widget table and
g the geometry table. If we don't call a layout function (as p and g are
tables without layout keys), no geometry gets pushed to the stack. Thus,
we are missing at least two geometries in your example, which makes
telling which of the 20 widgets doesn't have a geometry assigned a bit
hard :)
That would be
impossible, because the layout can't easily be overridden (well, it can
be, but IMHO that cuts a lot of usability and makes a lot of things
redundant). The notion here was that every subtable is a widget box,
as in GTK, the layout of which is defined by the .layout field. IMHO
this carries the principle of least surprise, as I myself would expect
the following to result in a taglist aligned to the right wibox edge:
{
mytaglist[s],
layout = awful.widget.layout.horizontal.rightleft
}
whereas, when we define the layout in mytaglist[s] itself and not use
the parent layout, it might be aligned to the left edge of the wibox,
despite me specifying it should not.
Hum. I either disagree or miss your point.
If you specify mytaglist.layout = flex, then inside, they are all
aligned to left with the same space (this is what flex is about).
But the whole element (i.e. all the tag text/iconboxes) are aligned to
the right (which has only sense if there's another widget at the same level
of mytaglist), since you specified rightleft.
[...]
Hum, that makes sense. Imho it'd then be right to set the default layout
to flex for things like the tasklist, but still allow propagation of the
layout key to child tables if the children don't have a layout key
themselves.
As said, this implements the principle of least surprise, as to the
user, the graph and the imagebox are both simple widgets, where it
wouldn't make sense to set a layout on one and not on another, which
would be needed if we'd forbid passing the layout from parent to child
if no child layout is set.
I'm awaiting feedback, mainly because I don't really have much
experience designing end user compatible interfaces and because the
way it currently is (with maybe presetting sane default values for the
tasklist or similar widgets) seems to be the most logical to me.
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
pgpwTx78x4wrd.pgp
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At 1247583756 time_t, Gregor Best wrote: I can provide arguments why your idea is suboptimal :) At the moment, from the C point of view we simply have a table with, say, 20 widgets (including things like tag- and tasklists). After calling the layout function, the C code expects a Lua table with 20 elements on the stack top, where the association w[i] = g[i], where w is the widget table and g the geometry table. If we don't call a layout function (as p and g are tables without layout keys), no geometry gets pushed to the stack. Thus, we are missing at least two geometries in your example, which makes telling which of the 20 widgets doesn't have a geometry assigned a bit hard :) I understand what you say, but that's rather sounds like a (small) design flaw than a real argument. :) In fact, I think the problem is in the Lua layout function that calls .layout function: they assume that if there's no .layout, the widget is part of them. Correct me if I'm wrong. Whereas the C part assume that if there's no widget, it's a Z-topbottom rendering (there's nothing to inherit). Ok, I'm just thinking out loud actually. Hum, that makes sense. Imho it'd then be right to set the default layout to flex for things like the tasklist, but still allow propagation of the layout key to child tables if the children don't have a layout key themselves. As said, this implements the principle of least surprise, as to the user, the graph and the imagebox are both simple widgets, where it wouldn't make sense to set a layout on one and not on another, which would be needed if we'd forbid passing the layout from parent to child if no child layout is set. I'm awaiting feedback, mainly because I don't really have much experience designing end user compatible interfaces and because the way it currently is (with maybe presetting sane default values for the tasklist or similar widgets) seems to be the most logical to me. As I said, the only thing that disturb me is that, AFAIU, the flex layout assume that subtable are using flex also if there's no other layout. I think there should be a default layout (like the C one), doing a Z-axis-stacking rendering and used when a layout does not find a subtable layout. And, as you said, widget like task and taglists should set flex by default. User can still change it then, anyway. I think it's not a big change and worth doing it right now rather than having problem later. What do you think, Gregor? Is there any real problem or side effect that I miss with such a change? Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // The more we fly, the more we climb, the more we know that heaven is a lie. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
On Tue, Jul 14, 2009 at 05:31:35PM +0200, Julien Danjou wrote: At 1247583756 time_t, Gregor Best wrote: I can provide arguments why your idea is suboptimal :) At the moment, from the C point of view we simply have a table with, say, 20 widgets (including things like tag- and tasklists). After calling the layout function, the C code expects a Lua table with 20 elements on the stack top, where the association w[i] = g[i], where w is the widget table and g the geometry table. If we don't call a layout function (as p and g are tables without layout keys), no geometry gets pushed to the stack. Thus, we are missing at least two geometries in your example, which makes telling which of the 20 widgets doesn't have a geometry assigned a bit hard :) I understand what you say, but that's rather sounds like a (small) design flaw than a real argument. :) [...] Hehe, well, having a 1:1 association was the most straighforward thing to implement :) In fact, I think the problem is in the Lua layout function that calls .layout function: they assume that if there's no .layout, the widget is part of them. Correct me if I'm wrong. Whereas the C part assume that if there's no widget, it's a Z-topbottom rendering (there's nothing to inherit). Ok, I'm just thinking out loud actually. [...] As I said, the only thing that disturb me is that, AFAIU, the flex layout assume that subtable are using flex also if there's no other layout. I think there should be a default layout (like the C one), doing a Z-axis-stacking rendering and used when a layout does not find a subtable layout. [...] Hmm, not a bad idea. Actually I implemented the first thing that came to my mind, but having a default layout which simply mimics the fallback layout is a good idea. And, as you said, widget like task and taglists should set flex by default. User can still change it then, anyway. I think it's not a big change and worth doing it right now rather than having problem later. What do you think, Gregor? Is there any real problem or side effect that I miss with such a change? I'd say it's worth a try. I'd rather have a rockstable patchset released a few days late than a half working, totally confusing one released right now :) I'll write a patch, so we have something substantial to discuss instead of mere thoughts :D -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpwOXmsyz2hv.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gregor Best wrote: On Tue, Jul 14, 2009 at 05:31:35PM +0200, Julien Danjou wrote: At 1247583756 time_t, Gregor Best wrote: I can provide arguments why your idea is suboptimal :) At the moment, from the C point of view we simply have a table with, say, 20 widgets (including things like tag- and tasklists). After calling the layout function, the C code expects a Lua table with 20 elements on the stack top, where the association w[i] = g[i], where w is the widget table and g the geometry table. If we don't call a layout function (as p and g are tables without layout keys), no geometry gets pushed to the stack. Thus, we are missing at least two geometries in your example, which makes telling which of the 20 widgets doesn't have a geometry assigned a bit hard :) I understand what you say, but that's rather sounds like a (small) design flaw than a real argument. :) [...] Hehe, well, having a 1:1 association was the most straighforward thing to implement :) Feel free to kill, but what do you think about adding a :draw() function to widgets that is only valid while a layout function is called? (globalconf.we_are_running_a_layout_function_and_this_needs_a_better_name) That way that whole IMHO ugly 1:1 association between different tables goes away.. Uli - -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKXMjmAAoJECLkKOvLj8sGpwkH/jsD5svkucqz+IFBK7oLqRAA +nXZQAdRBi9IvyA33l8jjgebv7TCBK3BS2BQreRHzhSqhzigmdaUw64/pz1QtcBG 3lgaFZRLgA1ELv0rHXB1iUC4LAkzvYYmnuRxXWLU9Zyhlflsa/S+YI7NsnE3hmjp 6AWXmkBIpe0llH+KhpgHZfXYYfYdLVyZDUkVA1l4rEfGRxfCZvlmCn+G7bcttwYy aNhwOW2LzBPv8gHIwQ3JK6k1b0/Vxwu54ykQA0f49i8de4wbfU3FAMgHK4ziwOWZ jRMXoR2nu46zoZIN6X4alpsTZSXirgAekUTBzIzI11Mkfsj61DAiHQjO8L5llMg= =cXSz -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
At 1247485510 time_t, Gregor Best wrote:
That could be the same problem I fixed in the horizontal layouts. I'll
take a look at that.
Many thanks in advance. :)
This should be useless. As far as I understand, mytasklist[s] is a
table, which has _no_ layout. If flex is applying because mytasklist is
a sub-table of the table is is inside (am I clear?), this seems like a
potential designe problem. To me, it seems the layout should be set
inside mytasklist[s]. Same thing for taglist.
[...]
Hmm, for now, if the subtable doesn't have a layout, it is assumed it
should have the same layout as the parent table. This allows for things
like aligning the tasklist to the right of the screen.
And:
{
layout = rightleft,
mytasklist,
}
with mytasklist.layout = flex
would not align the tasklist on the right using flex layout for all
elements?
Also, this allows
for more flexibility with i.e. the layoutbox or the graph and
progressbar widgets, as those are also tables. If we were to set their
layout inside the table themselves, we would run into problems where for
example people want to progressbars on top of each other.
I can't see why.
If you have (pseudo code):
p = progressbar()
g = graph()
{
p,
g,
layout = topdown,
}
p and g are tables with no layouts, so the default function (render all
elem inside the table on top of each other (z-axis)). Basically, since
there's only one drawable widget in p and g, this is not a problem.
Then p and g (i.e. their only widget inside) are drawn top to bottom.
I can't see why you need to inherit layout. In the case I used above,
this is even useless, since there's only widget in p or g to draw.
Can you provide me an example where this IS required? :)
That would be
impossible, because the layout can't easily be overridden (well, it can
be, but IMHO that cuts a lot of usability and makes a lot of things
redundant). The notion here was that every subtable is a widget box,
as in GTK, the layout of which is defined by the .layout field. IMHO
this carries the principle of least surprise, as I myself would expect
the following to result in a taglist aligned to the right wibox edge:
{
mytaglist[s],
layout = awful.widget.layout.horizontal.rightleft
}
whereas, when we define the layout in mytaglist[s] itself and not use
the parent layout, it might be aligned to the left edge of the wibox,
despite me specifying it should not.
Hum. I either disagree or miss your point.
If you specify mytaglist.layout = flex, then inside, they are all
aligned to left with the same space (this is what flex is about).
But the whole element (i.e. all the tag text/iconboxes) are aligned to
the right (which has only sense if there's another widget at the same level
of mytaglist), since you specified rightleft.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// This is the end of my signature.
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
On Thu, Jul 09, 2009 at 02:03:43PM +0200, Uli Schlachter wrote: Julien Danjou wrote: At 1247139117 time_t, Uli Schlachter wrote: Where exactly is that endless loop? I can't seem to find it. And frankly said, if you use looping tables for your widgets, you shouldn't be surprised :P You get what you deserve.. ok, you win Clearly. Somehow I wonder if luaA_isloop() is even worth keeping around. If you do bad stuff, you're screwed. We're not going to check everything the use does in Lua. We're not a sand box. A warn()ing is way more informative and easier to debug than awesome using 100% cpu. Plus I like sandboxes, it's a lot of fun to play with them... Uli I just noticed, in luaA_wibox_newindex, the wibox already checks the widget table for whether it is a loop and prints a warning and returns without setting the widget table. So I'd say, in this regard we're absolutely save. -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgp7XZYVKsXDT.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
I noticed a few essential noops in my patch, a fixed version is attached
Yay for code-shrinkage :)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
From 2e02de81c85e30c83fcd9c563155b6450f0d1630 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Sun, 12 Jul 2009 17:24:14 +0200
Subject: [PATCH 02/10] wtable: update on change, regardless of what was changed
this simplifies the code a bit and allows us to react to changes on
wtable entries that are neither tables nor widgets (for example the
layout function)
---
luaa.c | 22 ++
1 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/luaa.c b/luaa.c
index 992c6ae..2c3ab79 100644
--- a/luaa.c
+++ b/luaa.c
@@ -379,32 +379,14 @@ luaA_wtable_index(lua_State *L)
static int
luaA_wtable_newindex(lua_State *L)
{
-bool invalid = false;
-
-/* push key on top */
-lua_pushvalue(L, 2);
-/* get current key value in content table */
-lua_rawget(L, lua_upvalueindex(1));
-/* if value is a widget, notify change */
-if(lua_istable(L, -1) || luaA_toudata(L, -1, widget))
-invalid = true;
-
-lua_pop(L, 1); /* remove value */
-
-/* if new value is a widget or a table */
+/* if new value is a table, update the wibox widget table */
if(lua_istable(L, 3))
-{
luaA_table2wtable(L);
-invalid = true;
-}
-else if(!invalid luaA_toudata(L, 3, widget))
-invalid = true;
/* upvalue 1 is content table */
lua_rawset(L, lua_upvalueindex(1));
-if(invalid)
-luaA_wibox_invalidate_byitem(L, lua_topointer(L, 1));
+luaA_wibox_invalidate_byitem(L, lua_topointer(L, 1));
return 0;
}
--
1.6.3.3
pgpHaGYmYdcMX.pgp
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
I noticed a fluke in the last patch in the current series (which adds
layout support to the titlebars). A fixed version is attached, it
removes the changeset which modifies awful.widget.layout.horizontal
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
From ed6eb2cde5e4e5e9485fd773d671039c3d2c2da2 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Thu, 2 Jul 2009 01:41:26 +0200
Subject: [PATCH 10/10] titlebar: add widget layout support
Signed-off-by: Gregor Best farha...@googlemail.com
---
lib/awful/titlebar.lua.in | 47 +++-
1 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/lib/awful/titlebar.lua.in b/lib/awful/titlebar.lua.in
index e1a90ee..f99fe51 100644
--- a/lib/awful/titlebar.lua.in
+++ b/lib/awful/titlebar.lua.in
@@ -24,6 +24,7 @@ local util = require(awful.util)
local widget = require(awful.widget)
local mouse = require(awful.mouse)
local client = require(awful.client)
+local layout = require(awful.widget.layout)
--- Titlebar module for awful
module(awful.titlebar)
@@ -93,8 +94,8 @@ function add(c, args)
-- data[c].button_sets for late updates and add the
-- individual buttons to the array part of the widget
-- list
-local widget_list = { appicon = appicon, title = title }
-local iw = #widget_list
+local widget_list = { layout = layout.horizontal.rightleft }
+local iw = 1
local is = 1
data[c].button_sets = {}
for i = 1, #button_groups do
@@ -109,7 +110,16 @@ function add(c, args)
end
end
-tb.widgets = widget_list
+tb.widgets = {
+widget_list,
+{
+appicon = appicon,
+title = title,
+layout = layout.horizontal.flex
+},
+layout = layout.horizontal.leftright
+}
+
c.titlebar = tb
update(c)
@@ -122,13 +132,13 @@ function update(c, prop)
if type(c) == client and c.titlebar and data[c] then
local widgets = c.titlebar.widgets
if prop == name then
-if widgets.title then
-widgets.title.text = span font_desc=' .. data[c].font ..
+if widgets[2].title then
+widgets[2].title.text = span font_desc=' .. data[c].font ..
' .. util.escape(c.name) .. /span
end
elseif prop == icon then
-if widgets.appicon then
-widgets.appicon.image = c.icon
+if widgets[2].appicon then
+widgets[2].appicon.image = c.icon
end
end
if capi.client.focus == c then
@@ -328,14 +338,6 @@ end
--Finally the last parameter is the action for mouse
--button 1
-local close_buttons = button_group(close,
- { align = left },
- select_state_focus,
- { idx = n, img = normal,
- action = function (w, t) t.client:kill()
end },
- { idx = f, img = focus,
- action = function (w, t) t.client:kill()
end })
-
local ontop_buttons = button_group(ontop,
{ align = right },
function(c,p) return select_state(c, p,
ontop) end,
@@ -375,6 +377,15 @@ local maximized_buttons = button_group(maximized,
{ idx = f/a, img = focus_active,
action = function(w, t)
t.client.maximized_horizontal = false
t.client.maximized_vertical = false end })
+
+local close_buttons = button_group(close,
+ { align = left },
+ select_state_focus,
+ { idx = n, img = normal,
+ action = function (w, t) t.client:kill()
end },
+ { idx = f, img = focus,
+ action = function (w, t) t.client:kill()
end })
+
local function floating_update(w, t)
client.floating.toggle(t.client)
end
@@ -387,11 +398,11 @@ local floating_buttons = button_group(floating,
{ idx = n/a, img = normal_active,
action = floating_update },
{ idx = f/a, img = focus_active,
action = floating_update })
-button_groups = { ontop_buttons,
+button_groups = { close_buttons,
+ ontop_buttons,
sticky_buttons,
maximized_buttons,
- floating_buttons,
- close_buttons }
+ floating_buttons }
-- Register standards hooks
Re: [Draft] Introduction of Widget Layouts
Man, by the time these goddamn features land in master, they'll be bug free at this rate! What the heck are you doing?! Honestly: the Awesome project's code review system is much more extensive than any software company I've worked at. Cut it out you guys, you're making everyone everywhere look bad! ;) Hhahaa, cheers. -AGT -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
At 1247090952 time_t, Gregor Best wrote: It does, because it removes the calculation of the actual text position from C. Without that, widget_geometries isn't fully functional, as text doesn't get drawn where the layout function decides it should. Okay. Premature optimization is the root of all evil :) I can't disagree. +lua_insert(globalconf.L, lua_gettop(globalconf.L) - 1); +lua_pop(globalconf.L, 1); I think we said that's totally noop, no? [...] It is not. lua_insert() needs an absolute stack position, which is why the lua_gettop() is used there (-1 would be a relative position). These two lines exchange the two top stack elements and then remove the new top, effectively removing the second element from the top (which is the layout function, it's not needed anymore and it would taint the stack if it stayed on top of it). Yeah, actually I reread your code, and it can be simplified to: lua_insert(L, -2); lua_pop(L, 1); Which also can be simplified to: lua_remove(L, -2); AFAICT. I'll do. Basically, we get the size we want the systray to be drawn at upon drawing the tray, thus removing the query to the xcb_get_geometry function. As all windows embedded in the systray are squares, their size is equal to their height, so we simply force the size to be wibox_height * n x wibox_height, where n is the number of embedded windows, instead of deriving it from the largest embedded window (which, for example in the case of wicd, would be 200x200, way too much for one window on a regular wibox). I'm not sure you can assume all systray icons are square. But well, I guess you have a pragmatic approach, so it should work right now. If something happens, we'll know and we'll fix it. :) Totally. This would ease up the implementation quite a bit, I'll do it. I'm glad that even ease your work. :-) It does indeed brake resizable imageboxes, and frankly, I have no idea how we could replace that. I think the best idea would be to have things settle down and then take a closer look at it. I agree. Would be very nice :) This bastard does not sounds interested. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gregor Best wrote:
Once again, I'm very thankful for every little bit of advice, so please
review :)
From a93c80d17c649446b2d80477db8b1dfa7cece886 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Fri, 29 May 2009 01:31:57 +0200
Subject: [PATCH 3/9] systray: don't crap up on odd-sized windows
I'll do. Basically, we get the size we want the systray to be drawn at
upon drawing the tray, thus removing the query to the xcb_get_geometry
function. As all windows embedded in the systray are squares, their size
is equal to their height, so we simply force the size to be
wibox_height * n x wibox_height, where n is the number of embedded windows,
instead of deriving it from the largest embedded window (which, for example
in the case of wicd, would be 200x200, way too much for one window on a
regular wibox).
Signed-off-by: Gregor Best farha...@googlemail.com
---
Uhm... I'll do in the beginning of a commit message? Copypaste is nice, but
don't forget grammar and context. :P
From 4bc0fcc388c5e3251f3fa95261967a60731891e5 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Thu, 2 Jul 2009 02:10:32 +0200
Subject: [PATCH 4/9] awful.widget: add layouts
Signed-off-by: Gregor Best farha...@googlemail.com
---
+++ b/lib/awful/widget/layout/horizontal.lua.in
+--- Horizontal widget layout
+module(awful.widget.layout.horizontal)
+
+local function horizontal(direction, bounds, widgets, screen)
+local geometries = { }
+local x = 0
+
+-- we are only interested in tables and widgets
+local keys = util.table.keys_filter(widgets, table, widget)
Uhm... Why? What are you trying to get rid of? Since util.table.keys_filter()
doesn't filter the table recursivly, other stuff can still be hidden in there.
Oh and the for loop below checks via type() anyway and ignores all other stuff..
Oh and: Does the C code catch loops in the table? If not I just found an endless
loop below...
+for _, k in ipairs(keys) do
+local v = widgets[k]
+if type(v) == table then
+local layout = v[layout] or function (...) return
horizontal(direction, ...) end
+local g = layout(bounds, v, screen)
+for _, v in ipairs(g) do
+v.x = v.x + x
+table.insert(geometries, v)
+end
+bounds = g.free
+x = x + g.free.x
+elseif type(v) == widget then
+local g
+if v.visible then
+g = v:extents(screen)
+else
+g = {
+width = 0,
+height = 0,
+}
+end
Can't the C code filter invisible widgets or something like that...? (I guess
not)
Why can widgets be made invisible at all? :(
+function flex(bounds, widgets, screen)
[..]
+nelements = (nelements == 0) and 1 or nelements
I read this twice and then thought:
if nelements == 0 then nelements = 1 end
--- /dev/null
+++ b/lib/awful/widget/layout/vertical.lua.in
@@ -0,0 +1,108 @@
[snip]
+local function vertical(direction, bounds, widgets, screen)
[snip]
+-- we are only interested in tables and widgets
+local keys = util.table.keys_filter(widgets, table, widget)
+local nelements = #keys
+local height = math.floor(bounds.height / nelements)
What if nelements is 0?
Subject: [PATCH 5/9] awesomerc.lua: add support for widget layouts
Subject: [PATCH 6/9] naughty: add support for widget layouts
Subject: [PATCH 7/9] awful.menu: add support for widget layouts
Subject: [PATCH 8/9] invaders: add support for widget layouts
Subject: [PATCH 9/9] titlebar: add widget layout support
More than half your patches fix things which you broke, well done! ;)
Uli
- --
Do you know that books smell like nutmeg or some spice from a foreign land?
-- Faber in Fahrenheit 451
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBCAAGBQJKVbAfAAoJECLkKOvLj8sGhWEIAISgYOJhWZhnIt7hhEjn9vrA
Mpjg2Hw5lRTFS3b3+vFvbFfkmXe6cawrEAk8sIwijLyFfZWM1Qmb+4QMJSjl+mM6
Iq5rE1yG0Wj2f3F1yj2xZNsCmAT2FwV1kbGotZZ3nAzKu2rsJXV7AMG77w9GydJf
MSrMlhGHwK5tFycxgCURNLnTw5d9l78grgO5PZOBTeEJtQfMun6XQc7z14WG3hwt
NPBBJnSMYgW6+UZEXTGcqJ0TpdzgCgoRYdCAjwonbZk3yQtvPROJVwN758GVirhV
xAhdIdS8Tl4my8ZrL0AmX/+nUYyQVm8WDhSXMVRmKs58SscQ+uleEfsg9cIc4C4=
=LGOQ
-END PGP SIGNATURE-
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
At 1247096479 time_t, Gregor Best wrote:
The layouts now
use the bounds parameter only to determine the available width and
height they can put their widgets into, the X and Y coordinates are
modified by the calling functions. (A much cleaner approach, why didn't
I think of that? :)
Don't know. Why do you keep this bounds?
You seems to only use them to check if the widgets does not try to
render outside the wibox/layouts. That's not the work of the layout.
If the widget, even packed, does not fit, well, too bad, it will be
drawn outside of the wibox, i.e. not shown.
Subject: [PATCH 1/9] widgets: add bool widget_geometries(wibox_t *)
@@ -276,7 +315,6 @@ widget_render(wibox_t *wibox)
for(int i = 0; i widgets-len; i++)
if(widgets-tab[i].widget-isvisible)
{
-widgets-tab[i].geometry.y = 0;
widgets-tab[i].widget-draw(widgets-tab[i].widget,
ctx, widgets-tab[i].geometry,
wibox);
}
You can kill the brackets.
--- a/widgets/graph.c
+++ b/widgets/graph.c
@@ -148,13 +148,13 @@ graph_plot_get(graph_data_t *d, const char *title)
}
static area_t
-graph_geometry(widget_t *widget, screen_t *screen, int height, int
width)
+graph_geometry(widget_t *widget, int screen)
{
area_t geometry;
graph_data_t *d = widget-data;
geometry.x = geometry.y = 0;
-geometry.height = height;
+geometry.height = d-width;
geometry.width = d-width;
Seems wrong to me. Why the graph would be a square?
Subject: [PATCH 2/9] widgets: get rid of align attribute
OK.
Subject: [PATCH 3/9] systray: don't crap up on odd-sized windows
OK.
Subject: [PATCH 4/9] awful.widget: add layouts
OK.
Subject: [PATCH 5/9] awesomerc.lua: add support for widget layouts
OK.
Subject: [PATCH 6/9] naughty: add support for widget layouts
OK.
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// My root password is
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Julien Danjou wrote: At 1247096479 time_t, Gregor Best wrote: The layouts now use the bounds parameter only to determine the available width and height they can put their widgets into, the X and Y coordinates are modified by the calling functions. (A much cleaner approach, why didn't I think of that? :) Don't know. Why do you keep this bounds? You seems to only use them to check if the widgets does not try to render outside the wibox/layouts. That's not the work of the layout. If the widget, even packed, does not fit, well, too bad, it will be drawn outside of the wibox, i.e. not shown. I guess the flex layout needs the bounds and since one can nest layouts, the other ones have to keep that bounds table up-to-date, too... I guess Uli - -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKVcHvAAoJECLkKOvLj8sGDTwIAMH4htwQ8vDFYnDqi+pA0Bd0 peYe7z9iNtrwLfZu9G9DC0rsWC+4IeXY6rAs8wFd7jahJM5itG8wFkeNOBiRkAZv 4HpcvDl4xGKDUy/WH0gHQ1HVyO2/UZblFwq0CiOenlQa6TP5gLQuOfjUjRn5LFay Ouo8hyjve8yl4LbUQY6FsvFvRq3/uFfgxKKVR2EyScn3op6BKg0QDacnIijVifi3 4osHNSN6ATa+QSaSCUjX2UlYt2WSJYYLd6/BBDnXFBX2TGoOxRVXXXQLdlxaOGyh NBkiY/3H9aPhSlQfQdpm6HWcL4oyD6PQ5WHcR5H3W7JG1FtM+Kwb8OIG+zwWg0c= =0EgX -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
At 1247134192 time_t, Uli Schlachter wrote: I guess the flex layout needs the bounds and since one can nest layouts, the other ones have to keep that bounds table up-to-date, too... I guess Make sense. I take back what I said. It's fine finally. :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1247130536 time_t, Julien Danjou wrote:
--- a/widgets/graph.c
+++ b/widgets/graph.c
@@ -148,13 +148,13 @@ graph_plot_get(graph_data_t *d, const char *title)
}
static area_t
-graph_geometry(widget_t *widget, screen_t *screen, int height, int
width)
+graph_geometry(widget_t *widget, int screen)
{
area_t geometry;
graph_data_t *d = widget-data;
geometry.x = geometry.y = 0;
-geometry.height = height;
+geometry.height = d-width;
geometry.width = d-width;
Seems wrong to me. Why the graph would be a square?
I just wait for clarification on this point from Gregor.
I encourage people to test the patch set. Then, it's more than probable
that everything will be merged.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// When I get sad, I stop being sad and be awesome instead. True story.
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
On Thu, Jul 09, 2009 at 10:53:52AM +0200, Uli Schlachter wrote:
[...]
Uhm... I'll do in the beginning of a commit message? Copypaste is nice, but
don't forget grammar and context. :P
[...]
In my defence: It was late at night :)
[...]
+-- we are only interested in tables and widgets
+local keys = util.table.keys_filter(widgets, table, widget)
Uhm... Why? What are you trying to get rid of? Since util.table.keys_filter()
doesn't filter the table recursivly, other stuff can still be hidden in there.
Oh and the for loop below checks via type() anyway and ignores all other
stuff..
[...]
Child tables will be filtered in their own layout functions. We
basically filter here because widget tables can contain other stuff, for
example boolean values (i.e. if you conditionally include a widget in
one wibox, but not in another) or functions (as was the case with the
titlebars). If we took those into account, the height calculation would
be messed up, as it needs the number of elements that will really be
placed onto the wibox.
[...]
Oh and: Does the C code catch loops in the table? If not I just found an
endless
loop below...
+for _, k in ipairs(keys) do
+local v = widgets[k]
+if type(v) == table then
+local layout = v[layout] or function (...) return
horizontal(direction, ...) end
+local g = layout(bounds, v, screen)
+for _, v in ipairs(g) do
+v.x = v.x + x
+table.insert(geometries, v)
+end
+bounds = g.free
+x = x + g.free.x
+elseif type(v) == widget then
+local g
+if v.visible then
+g = v:extents(screen)
+else
+g = {
+width = 0,
+height = 0,
+}
+end
Can't the C code filter invisible widgets or something like that...? (I guess
not)
Why can widgets be made invisible at all? :(
[...]
Where exactly is that endless loop? I can't seem to find it. And
frankly said, if you use looping tables for your widgets, you shouldn't
be surprised :P
Making widgets invisible is quite nice e.g. for laptops. You'd need some
widgets, for example UMTS signal strength, only while the laptop is
mobile, so you can simply hide that widget while it is on AC instead of
doing tricks with two widget tables or something the like.
[...]
+function flex(bounds, widgets, screen)
[..]
+nelements = (nelements == 0) and 1 or nelements
I read this twice and then thought:
if nelements == 0 then nelements = 1 end
[...]
It keeps consistence with the functions in e.g. awful.util. Those also
use
foo = foo or 1
instead of
if not foo then foo = 1 end
IMHO it's a matter of taste
[...]
--- /dev/null
+++ b/lib/awful/widget/layout/vertical.lua.in
@@ -0,0 +1,108 @@
[snip]
+local function vertical(direction, bounds, widgets, screen)
[snip]
+-- we are only interested in tables and widgets
+local keys = util.table.keys_filter(widgets, table, widget)
+local nelements = #keys
+local height = math.floor(bounds.height / nelements)
What if nelements is 0?
[...]
Good catch, I'll fix that.
[...]
Subject: [PATCH 5/9] awesomerc.lua: add support for widget layouts
Subject: [PATCH 6/9] naughty: add support for widget layouts
Subject: [PATCH 7/9] awful.menu: add support for widget layouts
Subject: [PATCH 8/9] invaders: add support for widget layouts
Subject: [PATCH 9/9] titlebar: add widget layout support
More than half your patches fix things which you broke, well done! ;)
[...]
Pssh :P
Thanks a lot for your time :)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
pgpaTPdFVzcZv.pgp
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
On Thu, Jul 09, 2009 at 11:08:56AM +0200, Julien Danjou wrote: At 1247096479 time_t, Gregor Best wrote: The layouts now use the bounds parameter only to determine the available width and height they can put their widgets into, the X and Y coordinates are modified by the calling functions. (A much cleaner approach, why didn't I think of that? :) Don't know. Why do you keep this bounds? You seems to only use them to check if the widgets does not try to render outside the wibox/layouts. That's not the work of the layout. If the widget, even packed, does not fit, well, too bad, it will be drawn outside of the wibox, i.e. not shown. But how would we then implement things like the flex layout or the rightleft layout? Those two absolutely need to know the available space, and IMHO it's the job of the widget layout to partition the available space among the widgets it contains. [...] You can kill the brackets. [...] Thy will be done :) [...] Seems wrong to me. Why the graph would be a square? [...] To be honest, I couldn't come up with a better sounding solution. If we say graphs always want a 4:3 aspect ratio, there will be people asking why would the graph be 4:3?. This is basically so that in the worst case, i.e. if the layout decides to simply take the widgets wish as granted, we draw the graph so that everything it contains is visible. I'm not really happy with that solution, but as graph widgets are destined to perish soon anyway, I for one think we should waste too much brainpower on that. -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpOCE7cOtCZu.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gregor Best wrote: On Thu, Jul 09, 2009 at 10:53:52AM +0200, Uli Schlachter wrote: Where exactly is that endless loop? I can't seem to find it. And frankly said, if you use looping tables for your widgets, you shouldn't be surprised :P You get what you deserve.. ok, you win Making widgets invisible is quite nice e.g. for laptops. You'd need some widgets, for example UMTS signal strength, only while the laptop is mobile, so you can simply hide that widget while it is on AC instead of doing tricks with two widget tables or something the like. You win again. [...] +function flex(bounds, widgets, screen) [..] +nelements = (nelements == 0) and 1 or nelements I read this twice and then thought: if nelements == 0 then nelements = 1 end [...] It keeps consistence with the functions in e.g. awful.util. Those also use foo = foo or 1 instead of if not foo then foo = 1 end foo = foo or 1 nelements = (nelements == 0) and 1 or nelements Are you really comparing the two? Well.. IMHO it's a matter of taste ..you win again. Thanks a lot for your time :) Rechnung kommt! :P Uli - -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKVdUrAAoJECLkKOvLj8sG9CsH/3tO1zJc9EoszF2B+rBxb679 ePPNwPhhoEQkzXSVNyfVKFe0wFWog4GIrpAxZ144zO/AaQlHnNlB7OTtEWK1f5VO tPD41MTS9wJMnjV1GoV0095p3Kiw9UyGEcU6Q2D9L9e4U/wCwreI5cnv4trTfjNN e983m0rgTRklV4TBzqhq4ZV0ttYtTWLchTk+K1y7syEaLpyc7nUZ2PKRWdWRXSe2 FLMx3sk+HhQmlJrLXcrEDUoLrjYJMF8F3f15krxEoBgprQjyCnEoZThEeg3wZDed j1SgLdYlzpC1LZWWI21616cWzerFcI7dbC48y6KXY7OG5N7vG4EJdLcv4Z6PP7k= =wDX0 -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
At 1247139117 time_t, Uli Schlachter wrote: Where exactly is that endless loop? I can't seem to find it. And frankly said, if you use looping tables for your widgets, you shouldn't be surprised :P You get what you deserve.. ok, you win Clearly. Somehow I wonder if luaA_isloop() is even worth keeping around. If you do bad stuff, you're screwed. We're not going to check everything the use does in Lua. We're not a sand box. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1247137243 time_t, Gregor Best wrote: But how would we then implement things like the flex layout or the rightleft layout? Those two absolutely need to know the available space, and IMHO it's the job of the widget layout to partition the available space among the widgets it contains. Yeah, Uli pointed that. It's ok. To be honest, I couldn't come up with a better sounding solution. If we say graphs always want a 4:3 aspect ratio, there will be people asking why would the graph be 4:3?. This is basically so that in the worst case, i.e. if the layout decides to simply take the widgets wish as granted, we draw the graph so that everything it contains is visible. I'm not really happy with that solution, but as graph widgets are destined to perish soon anyway, I for one think we should waste too much brainpower on that. I agree, but the solution is to also set a .height property. :-) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Tomorrow I was nothing, yesterday I'll be. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Julien Danjou wrote: At 1247139117 time_t, Uli Schlachter wrote: Where exactly is that endless loop? I can't seem to find it. And frankly said, if you use looping tables for your widgets, you shouldn't be surprised :P You get what you deserve.. ok, you win Clearly. Somehow I wonder if luaA_isloop() is even worth keeping around. If you do bad stuff, you're screwed. We're not going to check everything the use does in Lua. We're not a sand box. A warn()ing is way more informative and easier to debug than awesome using 100% cpu. Plus I like sandboxes, it's a lot of fun to play with them... Uli - -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKVdyeAAoJECLkKOvLj8sGrt0H/3EBXRv62NM09X6+0/R1Lark qWbwS5SQ0NQ7kpAfw+ppZe/SQlBwo2YoLt0IoeDO8FL7cB8yA8p/whCYpyZNsUxk gmw8QKv8g0bw7Ev7LUDyzLlWL990U5V22HtQxdrJTuSk88vyCzlRE66+UDgi6OTo mk847kosjM1ZuNubHgjVMSyxFRfJ0xXZdV8DktgDKD9Qr57H95T2f6bBcfEXDYG8 xLqJtYsK2r6pHohrSgISmpZsWobaf5OZMYxOzf4N/pkRuylbnUPHCaoQIldlbfYm 4T5kwYlAAvmFPJmLx20XgBM0ZhOtliWzJv7MVov8pf3xqXMDXh2SMLfz1Y1qlJc= =KhR8 -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
On Tue, Jul 07, 2009 at 11:38:25AM +0200, Julien Danjou wrote:
[...]
-y = area.y + (ctx-height - ext-height + 1) / 2 + margin-top;
+y = area.y + margin-top;
/* only honors alignment if enough space */
if(ext-width area.width)
I don't think this belongs to this patch. Would you mind splitting and
explaining it a little?
[...]
It does, because it removes the calculation of the actual text position
from C. Without that, widget_geometries isn't fully functional, as text
doesn't get drawn where the layout function decides it should.
[...]
+/** Retrieve a list of widget geometries using a Lua layout function.
+ * \param wibox The wibox.
+ * \return True is everything is ok, false otherwise.
+ * \todo What do we do if there's no layout defined?
+ */
Comments does not indicate it push a table on the stack. Would you mind
adding more comments?
[...]
Added :)
[...]
+bool
+widget_geometries(wibox_t *wibox)
+{
+/* get the layout field of the widget table */
+if (wibox-widgets_table != LUA_REFNIL)
+{
+lua_rawgeti(globalconf.L, LUA_REGISTRYINDEX, wibox-widgets_table);
+lua_getfield(globalconf.L, -1, layout);
+}else
+lua_pushnil(globalconf.L);
Put 'else' statement on its own line.
Also pushing nil might be useless, just going to the else after might
optimize a very very very little.
[...]
Premature optimization is the root of all evil :)
I'll do that once everything else has been ironed out.
[...]
+/* if the layout field is a function */
+if(lua_isfunction(globalconf.L, -1))
+{
+/* Push 1st argument: wibox geometry */
+area_t geometry = wibox-sw.geometry;
+geometry.x = 0;
+geometry.y = 0;
+/* we need to exchange the width and height of the wibox window if
it
+ * isn't at the top or bottom, so the layout function doesn't need
to
+ * care about that */
Wrong comment.
[...]
Agreed, I changed that.
+if(wibox-sw.orientation != East)
+{
+int i = geometry.height;
+geometry.height = geometry.width;
+geometry.width = i;
+}
+geometry.height -= 2 * wibox-sw.border.width;
+geometry.width -= 2 * wibox-sw.border.width;
+luaA_pusharea(globalconf.L, geometry);
I think this is bad. I'll comment on that later.
+/* Re-push 2nd argument: widget table */
+lua_pushvalue(globalconf.L, -3);
+/* Push 3rd argument: wibox screen */
+lua_pushnumber(globalconf.L,
screen_array_indexof(globalconf.screens, wibox-screen));
+/* call the layout function with 3 arguments (wibox geometry,
widget
+ * table, screen) and wait for one result */
+if(lua_pcall(globalconf.L, 3, 1, 0))
+{
+warn(error running layout function: %s,
+ lua_tostring(globalconf.L, -1));
+lua_pop(globalconf.L, 2);
+return false;
+}
Using luaA_dofunction() might be better.
[...]
+lua_insert(globalconf.L, lua_gettop(globalconf.L) - 1);
+lua_pop(globalconf.L, 1);
I think we said that's totally noop, no?
[...]
It is not. lua_insert() needs an absolute stack position, which is why
the lua_gettop() is used there (-1 would be a relative position). These
two lines exchange the two top stack elements and then remove the new
top, effectively removing the second element from the top (which is the
layout function, it's not needed anymore and it would taint the stack if
it stayed on top of it).
[...]
+warn(no layout function defined or layout function invalid,
falling back to simple default layout);
No warn please.
[...]
Agreed, I'll remove that.
[...]
Subject: [PATCH 05/15] systray: don't crap up on odd-sized windows
OK, but adding more explanation in the commit log would be nice, I did
not get everything.
[...]
I'll do. Basically, we get the size we want the systray to be drawn at
upon drawing the tray, thus removing the query to the xcb_get_geometry
function. As all windows embedded in the systray are squares, their size
is equal to their height, so we simply force the size to be wibox_height
* n x wibox_height, where n is the number of embedded windows, instead
of deriving it from the largest embedded window (which, for example in
the case of wicd, would be 200x200, way too much for one window on a
regular wibox).
[...]
Subject: [PATCH 10/15] awful.widget: add layouts
+local function horizontal(direction, bounds, widgets, screen)
That's here I comment about bounds.
I don't like this part of the implementation. IMHO, the layout should
have no idea what are the bounds it is drawn into.
It should assume that x,y = 0,0 and then compute everthings based on
that.
Then, if actually x,y are, let's say, 100,100, that's the work of the
callee to
Re: [Draft] Introduction of Widget Layouts
At 1246495186 time_t, Gregor Best wrote: diff --git a/widget.h b/widget.h index f2ca048..e9d9e7e 100644 --- a/widget.h +++ b/widget.h @@ -73,7 +73,7 @@ struct widget_node_t widget_t *widget_getbycoords(orientation_t, widget_node_array_t *, int, int, int16_t *, int16_t *); void widget_render(wibox_t *); -void luaA_table2widgets(lua_State *, widget_node_array_t *); +int luaA_widget_userdata_new(lua_State *, widget_t *); void widget_invalidate_bywidget(widget_t *); void widget_invalidate_bytype(widget_constructor_t *); I merged patches 1, 2, 6, 7, 8 and 9. 1 was amended without the + line of the diff above. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
I suggest being consistent with the other code and push the geometry to lua with borders included. Like the client code does, or change that, at least be consistent. Maarten. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
On Tue, Jul 07, 2009 at 02:56:04PM +0200, Maarten Maathuis wrote: I suggest being consistent with the other code and push the geometry to lua with borders included. Like the client code does, or change that, at least be consistent. Maarten. Good call, sounds totally reasonable. I guess I'll have some hacking to do tonight :) -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpix9c2J88iP.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At 1246971364 time_t, Maarten Maathuis wrote: I suggest being consistent with the other code and push the geometry to lua with borders included. Like the client code does, or change that, at least be consistent. Well, I suggested to not push any geometry, which seems far better. No? :) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
I just saw a fragment of code in my mailbox, if jd has a better suggestion, then by all means go ahead. Maarten. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
I just noticed a little glitch in patch #10, a fixed version is
attached.
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
From d4e448cc139887c5dc8fad59aa01c6314aced2ad Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Thu, 2 Jul 2009 02:10:32 +0200
Subject: [PATCH 10/15] awful.widget: add layouts
Signed-off-by: Gregor Best farha...@googlemail.com
---
lib/awful/widget/init.lua.in |1 +
lib/awful/widget/layout/horizontal.lua.in | 159 +
lib/awful/widget/layout/init.lua.in |7 ++
lib/awful/widget/layout/vertical.lua.in | 104 +++
4 files changed, 271 insertions(+), 0 deletions(-)
create mode 100644 lib/awful/widget/layout/horizontal.lua.in
create mode 100644 lib/awful/widget/layout/init.lua.in
create mode 100644 lib/awful/widget/layout/vertical.lua.in
diff --git a/lib/awful/widget/init.lua.in b/lib/awful/widget/init.lua.in
index 6d4b51c..db39ed5 100644
--- a/lib/awful/widget/init.lua.in
+++ b/lib/awful/widget/init.lua.in
@@ -12,6 +12,7 @@ require(awful.widget.prompt)
require(awful.widget.progressbar)
require(awful.widget.graph)
require(awful.widget.layoutbox)
+require(awful.widget.layout)
--- Widget module for awful
module(awful.widget)
diff --git a/lib/awful/widget/layout/horizontal.lua.in
b/lib/awful/widget/layout/horizontal.lua.in
new file mode 100644
index 000..cbdff21
--- /dev/null
+++ b/lib/awful/widget/layout/horizontal.lua.in
@@ -0,0 +1,159 @@
+-
+-- @author Gregor Best farha...@googlemail.com
+-- @copyright 2009 Gregor Best
+-- @release @AWESOME_VERSION@
+-
+
+-- Grab environment
+local ipairs = ipairs
+local type = type
+local table = table
+local math = math
+local util = require(awful.util)
+
+--- Horizontal widget layout
+module(awful.widget.layout.horizontal)
+
+local function horizontal(direction, bounds, widgets, screen)
+local geometries = { }
+
+if direction == rightleft then -- reverse widget table
+widgets = util.table.reverse(widgets)
+end
+
+-- we are only interested in tables and widgets
+local keys = util.table.keys_filter(widgets, table, widget)
+
+for _, k in ipairs(keys) do
+local v = widgets[k]
+if type(v) == table then
+local layout = v[layout] or function (...) return
horizontal(direction, ...) end
+local g = layout(bounds, v, screen)
+if direction == rightleft then
+g = util.table.reverse(g)
+end
+bounds = g.free
+for _, v in ipairs(g) do
+table.insert(geometries, v)
+end
+elseif type(v) == widget then
+local g
+if v.visible then
+g = v:extents(screen)
+else
+g = {
+[width] = 0,
+[height] = 0,
+}
+end
+g.ratio = 1
+if g.height 0 then
+g.ratio = g.width / g.height
+end
+if g.width bounds.width then
+g.width = bounds.width
+end
+g.height = bounds.height
+g.y = bounds.y
+
+if v.resize and g.width 0 then
+g.width = math.floor(g.height * g.ratio)
+end
+
+if direction == leftright then
+g.x = bounds.x
+bounds.x = bounds.x + g.width
+else
+g.x = bounds.x + bounds.width - g.width
+end
+bounds.width = bounds.width - g.width
+
+table.insert(geometries, g)
+end
+end
+
+if direction == rightleft then -- reverse geometries table
+geometries = util.table.reverse(geometries)
+end
+
+geometries.free = util.table.clone(bounds)
+
+return geometries
+end
+
+function flex(bounds, widgets, screen)
+local geometries = {
+free = util.table.clone(bounds)
+}
+geometries.free.width = 0
+
+-- we are only interested in tables and widgets
+local keys = util.table.keys_filter(widgets, table, widget)
+local nelements = 0
+
+for _, k in ipairs(keys) do
+local v = widgets[k]
+if type(v) == table then
+nelements = nelements + 1
+elseif type(v) == widget then
+local g = v:extents()
+if v.resize and g.width 0 and g.height 0 then
+bounds.width = bounds.width - bounds.height
+elseif g.width 0 and g.height 0 then
+nelements = nelements + 1
+end
+end
+end
+
+nelements = (nelements == 0) and 1 or nelements
+
+local x = bounds.x
+local width = math.floor(bounds.width / nelements)
+
+for _, k in
Re: [Draft] Introduction of Widget Layouts
At 1245973156 time_t, Gregor Best wrote: I just found a place where it makes sense to have non-integer keys in the widget table: the titlebars. Rewriting those to make use of integer keys will be quite hard, as they make excessive use of integer keys and it will make the code even less readable and understandable. I'm currently trying to think of some way to stabilize the order of non-integer keys. Would a simple table.sort() be enough? I'm not really sure here... Comments and suggestions are greatly appreciated :) If you're willing to take this road, you need to define a rule on how to order keys. table.sort() on non-numeric keys would be enough and will return always the same result (of course) so it's safe. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
Excerpts from Gregor Best's message of Thu Jun 25 19:39:16 -0400 2009: I just found a place where it makes sense to have non-integer keys in the widget table: the titlebars. Rewriting those to make use of integer keys will be quite hard, as they make excessive use of integer keys and it will make the code even less readable and understandable. I'm currently trying to think of some way to stabilize the order of non-integer keys. Would a simple table.sort() be enough? I'm not really sure here... Or do some hax where a table has both an index and named keys. Sort by index, use keys for whatever convenience. I'm not sure what magic would be involved, but sounds do-able. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
I forgot to mention, the patches apply onto latest git master -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpE9i3MF3sxp.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
This is review of patch #3.
At 1245932662 time_t, Gregor Best wrote:
-- vim:
filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/lib/awful/widget/init.lua.in b/lib/awful/widget/init.lua.in
index 6d4b51c..ae0cfb2 100644
--- a/lib/awful/widget/init.lua.in
+++ b/lib/awful/widget/init.lua.in
@@ -13,6 +13,8 @@ require(awful.widget.progressbar)
require(awful.widget.graph)
require(awful.widget.layoutbox)
+require(awful.widget.layout)
+
Drop the empty line above.
+for _, k in ipairs(util.table.ikeys(widgets)) do
I did not dig too far, but isn'y ipairs enough?
diff --git a/lib/awful/widget/taglist.lua.in b/lib/awful/widget/taglist.lua.in
index 00de38c..6117942 100644
--- a/lib/awful/widget/taglist.lua.in
+++ b/lib/awful/widget/taglist.lua.in
@@ -48,7 +48,7 @@ end
-- @param label Label function to use.
-- @param buttons A table with buttons binding to set.
function new(screen, label, buttons)
-local w = {}
+local w = { }
local widgets = { }
widgets.imagebox = { }
widgets.textbox = { [margin] = { [left] = 0,
diff --git a/lib/awful/widget/tasklist.lua.in
b/lib/awful/widget/tasklist.lua.in
index 0d0897c..883a12d 100644
--- a/lib/awful/widget/tasklist.lua.in
+++ b/lib/awful/widget/tasklist.lua.in
@@ -42,7 +42,7 @@ end
-- @param label Label function to use.
-- @param buttons A table with buttons binding to set.
function new(label, buttons)
-local w = {}
+local w = { }
local widgets = { }
widgets.imagebox = { align = flex }
widgets.textbox = { align = flex,
Remove that crap. :)
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Anna Molly! Anna Molly! Anna Molly!
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
On Thu, Jun 25, 2009 at 02:48:57PM +0200, Julien Danjou wrote:
[...]
+for _, k in ipairs(util.table.ikeys(widgets)) do
I did not dig too far, but isn'y ipairs enough?
[...]
Nope, because ipairs stops when it encounters a nil value. The following
table would be iterated over completely:
{
foo,
bar,
asdf
}
While the following would only iterate over the first two values:
{
foo,
bar,
nil,
asdf
}
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
pgpK092ex4ZVT.pgp
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All of the following stuff are proposals and small comments. Don't take me too
seriously and feel free to disagree wherever you disagree.
Gregor Best wrote:
Okay, I attached all patches I wrote so far (quite a few :).
Subject: [PATCH 01/12] wibox: rebuild table at every draw
diff --git a/wibox.c b/wibox.c
index eb092b2..30c85b2 100644
--- a/wibox.c
+++ b/wibox.c
@@ -541,9 +528,12 @@ luaA_wibox_invalidate_byitem(lua_State *L, const void
*item)
wibox_t *wibox = *w;
if(luaA_wibox_hasitem(L, wibox, item))
First..
{
-/* recompute widget node list */
-wibox_widgets_table_build(L, wibox);
-lua_pop(L, 1); /* remove widgets table */
+if(luaA_wibox_hasitem(L, wibox, item))
...and second call, one time should be enough
+{
+/* update wibox */
+wibox_need_update(wibox);
+lua_pop(L, 1); /* remove widgets table */
+}
}
}
Subject: [PATCH 02/12] widgets: add bool widget_geometries(wibox_t *)
--- a/draw.c
+++ b/draw.c
@@ -247,10 +247,7 @@ draw_text(draw_context_t *ctx, draw_text_context_t *data,
pango_layout_set_font_description(ctx-layout, globalconf.font-desc);
x = area.x + margin-left;
-/* + 1 is added for rounding, so that in any case of doubt we rather draw
- * the text 1px lower than too high which usually results in a better
type
- * face */
-y = area.y + (ctx-height - ext-height + 1) / 2 + margin-top;
+y = area.y + margin-top;
Nice, looks much saner ;)
--- a/widget.c
+++ b/widget.c
@@ -129,6 +129,95 @@ luaA_table2widgets(lua_State *L, widget_node_array_t
*widgets)
[snip]
-/* save left value */
-int fake_left = left;
+widgets-tab[i].geometry.x = luaA_getopt_number(L, -1, x,
wibox-sw.geometry.x);
+widgets-tab[i].geometry.y = luaA_getopt_number(L, -1, y,
wibox-sw.geometry.y);
+widgets-tab[i].geometry.width = luaA_getopt_number(L, -1, width,
1);
+widgets-tab[i].geometry.height = luaA_getopt_number(L, -1,
height, 1);
This will kill the processes if e.g. the x field is a table instead of a
number. luaA_getopt_number() should only ever be called from within lua_pcall()
(p as in protected for this exact reason ;) )
diff --git a/widgets/graph.c b/widgets/graph.c
index 2ff3048..878a1ac 100644
--- a/widgets/graph.c
+++ b/widgets/graph.c
Let's break the deprecated widgets *duck*.
Same here:
--- a/widgets/progressbar.c
+++ b/widgets/progressbar.c
@@ -133,12 +133,11 @@ progressbar_bar_get(bar_array_t *bars, const char
*title)
}
static area_t
-progressbar_geometry(widget_t *widget, screen_t *screen, int height, int
width)
+progressbar_geometry(widget_t *widget, int screen)
{
area_t geometry;
progressbar_data_t *d = widget-data;
-geometry.height = height;
if(d-vertical)
{
@@ -157,6 +156,7 @@ progressbar_geometry(widget_t *widget, screen_t *screen,
int height, int width)
}
geometry.width = pb_width + 2 * (d-border_width +
d-border_padding);
}
+geometry.height = geometry.width;
geometry.x = geometry.y = 0;
@@ -166,29 +166,7 @@ progressbar_geometry(widget_t *widget, screen_t *screen,
int height, int width)
static area_t
progressbar_extents(lua_State *L, widget_t *widget)
{
-area_t geometry;
-progressbar_data_t *d = widget-data;
-
-if (d-vertical)
-{
-int pb_width = (int) ((d-width - 2 * (d-border_width +
d-border_padding) * d-bars.len
- - d-gap * (d-bars.len - 1)) / d-bars.len);
-geometry.width = d-bars.len * (pb_width + 2 * (d-border_width +
d-border_padding)
- + d-gap) - d-gap;
-}else
-{
-int pb_width = d-width - 2 * (d-border_width + d-border_padding);
-if(d-ticks_count d-ticks_gap)
-{
-int unit = (pb_width + d-ticks_gap) / d-ticks_count;
-pb_width = unit * d-ticks_count - d-ticks_gap; /* rounded to
match ticks... */
-}
-geometry.width = pb_width + 2 * (d-border_width +
d-border_padding);
-}
-
-geometry.height = geometry.width;
-
-return geometry;
+return progressbar_geometry(widget, 0);
}
I haven't checked the source code, but this diff looks like it fixes some code
duplication. If you want to make jd really happy, you could move this to an
extra patch (and if I'm wrong you can ignore me). (Most likely this applies to
the other widgets, too?)
Subject: [PATCH 03/12] awful: add widget layouts (vertical and horizontal)
--- a/lib/awful/widget/init.lua.in
+++ b/lib/awful/widget/init.lua.in
@@ -13,6 +13,8 @@ require(awful.widget.progressbar)
require(awful.widget.graph)
require(awful.widget.layoutbox)
+require(awful.widget.layout)
+
--- Widget module for awful
Re: [Draft] Introduction of Widget Layouts
At 1245936340 time_t, Gregor Best wrote: Nope, because ipairs stops when it encounters a nil value. The following table would be iterated over completely: I got that, but why would you have nil value? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
On Thu, Jun 25, 2009 at 03:26:48PM +0200, Uli Schlachter wrote:
[...]
Subject: [PATCH 01/12] wibox: rebuild table at every draw
diff --git a/wibox.c b/wibox.c
index eb092b2..30c85b2 100644
--- a/wibox.c
+++ b/wibox.c
@@ -541,9 +528,12 @@ luaA_wibox_invalidate_byitem(lua_State *L, const void
*item)
wibox_t *wibox = *w;
if(luaA_wibox_hasitem(L, wibox, item))
First..
{
-/* recompute widget node list */
-wibox_widgets_table_build(L, wibox);
-lua_pop(L, 1); /* remove widgets table */
+if(luaA_wibox_hasitem(L, wibox, item))
...and second call, one time should be enough
+{
+/* update wibox */
+wibox_need_update(wibox);
+lua_pop(L, 1); /* remove widgets table */
+}
}
}
[...]
Agreed, I think that slipped in in one of the many rebases I did while
writing the patches. I'll amend that.
[...]
This will kill the processes if e.g. the x field is a table instead of a
number. luaA_getopt_number() should only ever be called from within
lua_pcall()
(p as in protected for this exact reason ;) )
[...]
True, that's what patch #09 is for, I guess I'll rebase in a way so that
patch #09 comes before this one.
[...]
Let's break the deprecated widgets *duck*.
[...]
Imho they should be patched as long as they are still in git master :)
[...]
WTF?
[...]
again: WTF? definitely not something which belongs into this patch.
[...]
True, slipped by my attention, thanks for catching that :)
[...]
Oh, here it is (see above). I guess you could drop this line from the last
patch
then...
[...]
Agreed, thy will be done :D
[...]
BTW: Why are you using '[layout] =' ? Doesn't 'layout =' have the same
effect
and look better? Dunno, I guess this is a matter of taste... (Again: Feel free
to ignore me)
[...]
It's an old habit of mine :P No really, I used to use that style back
when I started writing the patches, but of course it adds clutter. I'll
remove that.
Subject: [PATCH 07/12] invaders: add support for widget layouts
diff --git a/lib/invaders.lua.in b/lib/invaders.lua.in
+gamedata.highscore.window:geometry(gamedata.highscore.table:extents())
+gamedata.highscore.window:geometry({ x = gamedata.field.x +
math.floor(gamedata.field.w / 2) - 100,
+ y = gamedata.field.y +
math.floor(gamedata.field.h / 2) - 55 })
Uhm, drop that first :geometry call?
That's not possible. The first call to :geometry sets the right width
and height for the wibox and the second call sets the X and Y
coordinates. If you can think of an easier way, please let me know :)
[...]
Subject: [PATCH 09/12] luaA_getopt_number(): also return def if stack top
is neither number nor nil
diff --git a/luaa.h b/luaa.h
index ac99b0e..8c798ce 100644
--- a/luaa.h
+++ b/luaa.h
@@ -135,9 +135,10 @@ static inline lua_Number
luaA_getopt_number(lua_State *L, int idx, const char *name, lua_Number def)
{
lua_getfield(L, idx, name);
-lua_Number n = luaL_optnumber(L, -1, def);
+if (lua_isnil(L, -1) || lua_isnumber(L, -1))
+def = luaL_optnumber(L, -1, def);
lua_pop(L, 1);
-return n;
+return def;
}
Uhm, I think this fixes the problem I had with patch 1 or 2 (the one which
could
cause a lua error outside of lua_pcall()). Ask jd twice if this is ok. ;)
See above
Subject: [PATCH 10/12] systray: don't crap up on odd-sized windows
diff --git a/widgets/systray.c b/widgets/systray.c
index 0504be8..bd53ef6 100644
--- a/widgets/systray.c
+++ b/widgets/systray.c
@@ -32,32 +32,27 @@
#define _NET_SYSTEM_TRAY_ORIENTATION_HORZ 0
#define _NET_SYSTEM_TRAY_ORIENTATION_VERT 1
+typedef struct
+{
+/* systray height */
+int height;
+} systray_data_t;
+
Uhm, do we really need a struct for this?
I wanted to stay consistent with the rest of the widgets, but as the
number of widgets in the C core is reduced, that might not be neccessary
anymore. JD: comments?
Subject: [PATCH 11/12] awful.util: add table.clone
That's a nice, small patch, it's a candidate for merging independent of widget
layouts. :)
If you really need it :P
Subject: [PATCH 12/12] widget.layout.*: correctly stack nested layouts
A bugfix in the very first patch series? I'd propose to merge this stuff with
the patches which added this code
Agreed, these patches are my current working branch, so expect some
splitting and reordering.
I hope I didn't annoy you too much.
Nope, your feedback is very much appreciated, as well as everyone elses, thanks
a lot :)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
pgpQfks1btaWG.pgp
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gregor Best wrote:
On Thu, Jun 25, 2009 at 03:26:48PM +0200, Uli Schlachter wrote:
Subject: [PATCH 07/12] invaders: add support for widget layouts
diff --git a/lib/invaders.lua.in b/lib/invaders.lua.in
+gamedata.highscore.window:geometry(gamedata.highscore.table:extents())
+gamedata.highscore.window:geometry({ x = gamedata.field.x +
math.floor(gamedata.field.w / 2) - 100,
+ y = gamedata.field.y +
math.floor(gamedata.field.h / 2) - 55 })
Uhm, drop that first :geometry call?
That's not possible. The first call to :geometry sets the right width
and height for the wibox and the second call sets the X and Y
coordinates. If you can think of an easier way, please let me know :)
bla:geometry(awful.util.table.join(bla:extents(), { x = bla, y = bla })
On second thought... I suddenly like your version more. ;)
Thanks for agreeing with my comments and just so that you dont forget:
In the default config with sky theme, the awesome menu's text is a little
misplaced.
Cheers,
Uli
- --
Do you know that books smell like nutmeg or some spice from a foreign land?
-- Faber in Fahrenheit 451
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBCAAGBQJKQ60PAAoJECLkKOvLj8sGHpEH/AkCXmWzU8AMc+z+p9zvBlYM
iq3mMklkM68JpW+kdGPqmgWTmEdiVx0ry7BZ1sKA2F5/gl0IhiesO+n7MYUkCrT0
p8G19lUHW+Dqu/UMGGKRQ9Qryk4tFWxV54C+mjs5RzNrZNbKL6yVAbnRrJx4Aqmn
XXMBo5/E+/F/TqXqRACYMHlgUnnQHckSUr13pOGPW9d9zIfjI5QLIubcg2YN3c6M
trVhKQGj0UooM96VNztMnGeJqXGkCly9EuOwJNnpTlFRYFf+1/el6D4LyD6kDtmy
3B/VDSB3tXC67mMCYKn1W6k4uA8u+0M0n+v3pHVK3z9ND3gcz18nUnNxSeJd6cY=
=U64I
-END PGP SIGNATURE-
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
At 1245947013 time_t, Gregor Best wrote:
Subject: [PATCH 10/12] systray: don't crap up on odd-sized windows
diff --git a/widgets/systray.c b/widgets/systray.c
index 0504be8..bd53ef6 100644
--- a/widgets/systray.c
+++ b/widgets/systray.c
@@ -32,32 +32,27 @@
#define _NET_SYSTEM_TRAY_ORIENTATION_HORZ 0
#define _NET_SYSTEM_TRAY_ORIENTATION_VERT 1
+typedef struct
+{
+/* systray height */
+int height;
+} systray_data_t;
+
Uhm, do we really need a struct for this?
I wanted to stay consistent with the rest of the widgets, but as the
number of widgets in the C core is reduced, that might not be neccessary
anymore. JD: comments?
Actually, this struct is reduced to an int anyway since it only got
that inside. So there's not point code-wise speaking to change that
(i.e. there's no optimization to make).
I'd say leave it as it is, as a struct, 'cause there's always a chance
we'll need to store something more than the height. So there's a chance
we will re-add a struct later. And its somehow consistent with other
widgets, so it's not a problem to me.
Subject: [PATCH 11/12] awful.util: add table.clone
That's a nice, small patch, it's a candidate for merging independent of
widget
layouts. :)
If you really need it :P
Subject: [PATCH 12/12] widget.layout.*: correctly stack nested layouts
A bugfix in the very first patch series? I'd propose to merge this stuff
with
the patches which added this code
Agreed, these patches are my current working branch, so expect some
splitting and reordering.
I hope I didn't annoy you too much.
Nope, your feedback is very much appreciated, as well as everyone elses,
thanks a lot :)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// And thinking so much differently.
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Julien Danjou wrote:
At 1245947013 time_t, Gregor Best wrote:
Subject: [PATCH 10/12] systray: don't crap up on odd-sized windows
diff --git a/widgets/systray.c b/widgets/systray.c
index 0504be8..bd53ef6 100644
--- a/widgets/systray.c
+++ b/widgets/systray.c
@@ -32,32 +32,27 @@
#define _NET_SYSTEM_TRAY_ORIENTATION_HORZ 0
#define _NET_SYSTEM_TRAY_ORIENTATION_VERT 1
+typedef struct
+{
+/* systray height */
+int height;
+} systray_data_t;
+
Uhm, do we really need a struct for this?
I wanted to stay consistent with the rest of the widgets, but as the
number of widgets in the C core is reduced, that might not be neccessary
anymore. JD: comments?
Actually, this struct is reduced to an int anyway since it only got
that inside. So there's not point code-wise speaking to change that
(i.e. there's no optimization to make).
I'd say leave it as it is, as a struct, 'cause there's always a chance
we'll need to store something more than the height. So there's a chance
we will re-add a struct later. And its somehow consistent with other
widgets, so it's not a problem to me.
You could cast the height to (void*) and... *duck*
- --
Do you know that books smell like nutmeg or some spice from a foreign land?
-- Faber in Fahrenheit 451
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBCAAGBQJKQ7oYAAoJECLkKOvLj8sGqtAIAMGAShXUuARE/JdlRuIz/QZk
21/Q9WSPUwfkglXXuuPRPlleXNF2NAQucVmDU+5Ec1PqyJaUTUfXAY8hwuizSFlW
gw1Q+5UB2/HFFkg8dSeA0UR/aDcEi2nw6xjweuxgvvUmtkbEoyMg/+YrSk4ytWAu
enHr81FK/D9IhB0r5XwfKEaYINmYyWvY42CYkZbQYaydGGWqFM88UMfAIE51TpaP
gJ+ATE5TdoW4+2G+rehmn+n2dU7YArOlHbAYWAA3eM5gDJfu7Gtoz8wJAKZ92A9r
HCBbLl/4FGy2EJGjJ6N2vPLr6KPJHOKzcU2d/GjG19uzdsWqiJLYP2jdiIoKetY=
=B3cH
-END PGP SIGNATURE-
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Draft] Introduction of Widget Layouts
At 1245952537 time_t, Uli Schlachter wrote: You could cast the height to (void*) and... *duck* Please, recall me, where did you say you were living already? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
On Thu, Jun 25, 2009 at 10:07:50AM +0200, Julien Danjou wrote: At 1245885960 time_t, Gregor Best wrote: → Now, only widgets residing at integer indexes are supported, so you can't do stuff like w.widgets[bar] = foo, they'll simply get ignored. I did that because IIRC, the order of non-integer keys isn't stable in lua tables and it also conflicts with having [layout] as the key for the layout function (e.g. what happens if someone places their widgets at w.widgets[layout]?). That sounds like a reasonable limitation to me. [...] I just found a place where it makes sense to have non-integer keys in the widget table: the titlebars. Rewriting those to make use of integer keys will be quite hard, as they make excessive use of integer keys and it will make the code even less readable and understandable. I'm currently trying to think of some way to stabilize the order of non-integer keys. Would a simple table.sort() be enough? I'm not really sure here... Comments and suggestions are greatly appreciated :) -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpxaGwy01rYm.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
After a long time without updates (my apologies for that), I finally got most of the stuff needed done. Nested layouts are now handled correctly, the systray now works a bit better and I think it's quite usable. I threw away my idea of inventing a crazy algorithm for finding free space in a list of rectangles and changed the protocol so that layouts tell their parent which space they didn't use along with the widget geometries (much easier anyway, and probably faster :). A few things remain, but I guess I'll tackle them tomorrow: → Titlebars don't yet support widget layouts (they are unusable atm) → Updating a wibox when the layout changes isn't yet implemented Also, there are things which I don't really know how to handle (input very much welcome): → Now, only widgets residing at integer indexes are supported, so you can't do stuff like w.widgets[bar] = foo, they'll simply get ignored. I did that because IIRC, the order of non-integer keys isn't stable in lua tables and it also conflicts with having [layout] as the key for the layout function (e.g. what happens if someone places their widgets at w.widgets[layout]?). For those daring (especially psychon, please find more bugs :), the git repo at git://git.mercenariesguild.net/awesome contains a branch called `widget-layout'. Feedback of any kind is welcome, please give your thoughts :) -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best pgpcEnZ4f9P0a.pgp Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
Hi Gregor, At 1237584486 time_t, Gregor Best wrote: As every time, I'm eager to receive feedback :) First my apologies for getting back to you so late, but I'm a bit overbooked by real life theses days. I took some time in the train to review your branch. I did some test, and I was not able to make things crash or render bad things, so it seems to me we are on a damn good road. However your branch seems like a mess to me. I'll probably do some rebase before merging. The only thing missing from my pov, is the removal of the vertical alignement and the adding of the vertical layout. When that's done, we will work on merging this into master. What do you think, Gregor? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Ferns will rule the world. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At Thu, 26 Mar 2009 14:03:06 +0100
Julien Danjou wrote:
Hi Gregor,
At 1237584486 time_t, Gregor Best wrote:
As every time, I'm eager to receive feedback :)
First my apologies for getting back to you so late, but I'm a bit
overbooked by real life theses days.
I took some time in the train to review your branch. I did some test,
and I was not able to make things crash or render bad things, so it
seems to me we are on a damn good road.
However your branch seems like a mess to me. I'll probably do some
rebase before merging.
The only thing missing from my pov, is the removal of the vertical
alignement and the adding of the vertical layout.
When that's done, we will work on merging this into master.
What do you think, Gregor?
No problem, I'm young, I have lots of time :)
There are some little bits which I'm not sure whether they should be left like
this, my biggest concern is the Add empty table for a wibox on new thing.
This was done so the layout function doesn't need to care about whether a wibox
was just created (with a nil reference as its wibox table) or whether the
widgets table was emptied with foo.widgets = { }. I don't really like my
solution because it still allows doing things like foo.widgets = nil, so I
think I'll remove that thing and just make widget_geometries push an empty
table.
While pulling with --rebase, I also noticed my branch isn't the cleanest, I'll
try cleaning things up.
The vertical layout should be easily doable, since basically it's just another
horizontal layout with the widgets stacked on top of each other instead of next
to each other.
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
signature.asc
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At 1238077385 time_t, Gregor Best wrote:
was just created (with a nil reference as its wibox table) or whether the
widgets table was emptied with foo.widgets = { }. I don't really like my
solution because it still allows doing things like foo.widgets = nil, so I
think I'll remove that thing and just make widget_geometries push an empty
table.
Ack.
There's also something missing I just recall:
when you do w.widgets.layout = newlayout, it does not update.
You should add some check code that set need_update to true on a wibox
in the wtable code (luaa.c IIRC).
I can handle it if you want, but it should be very easy.
While pulling with --rebase, I also noticed my branch isn't the cleanest, I'll
try cleaning things up.
Thanks.
The vertical layout should be easily doable, since basically it's just another
horizontal layout with the widgets stacked on top of each other instead of
next
to each other.
Clearly. The challenge would be to do it with the less code possible pasted
from horizontal. :-P
Kudos for your work anyway.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// My root password is
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
Hi again from the land of widget layouts :)
I pushed another update onto git://git.mercenariesguild.net/awesome
widget-layout, this time with a little more bugfixes:
→ Wiboxes attached to the side of the screen (left / right) are now drawn
correctly
→ Titlebars work (though there's a barely noticeable glitch, for some reason
the close button seems to be too far to the right)
→ I removed the .align attribute for widgets, they are completely gone now
(except for .valign, but i guess that can go, too)
→ Hidden widgets now don't mess up stuff
→ You can use conditional inclusion in the widget list again, so things like
foo.widgets = {
screen.count() == 2 and systray or nil
}
work fine
→ The ugly imagebox hack is gone (now imageboxes get resized correctly, keeping
their aspect ratio)
→ Naughty now works fine, notifications now take exactly the space they need,
no more, no less, except if a notification would be to large to fit on the
screen, in that case, it's truncated
→ No more useless whitespaces :)
→ and maybe a few more little fixes I can't remember right now...
The branch applies onto naquadah/master
As every time, I'm eager to receive feedback :)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
signature.asc
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At Fri, 20 Mar 2009 22:28:06 +0100
Gregor Best wrote:
Hi again from the land of widget layouts :)
I pushed another update onto git://git.mercenariesguild.net/awesome
widget-layout, this time with a little more bugfixes:
→ Wiboxes attached to the side of the screen (left / right) are now drawn
correctly
→ Titlebars work (though there's a barely noticeable glitch, for some reason
the close button seems to be too far to the right)
→ I removed the .align attribute for widgets, they are completely gone now
(except for .valign, but i guess that can go, too)
→ Hidden widgets now don't mess up stuff
→ You can use conditional inclusion in the widget list again, so things like
foo.widgets = {
screen.count() == 2 and systray or nil
}
work fine
→ The ugly imagebox hack is gone (now imageboxes get resized correctly,
keeping their aspect ratio)
→ Naughty now works fine, notifications now take exactly the space they need,
no more, no less, except if a notification would be to large to fit on the
screen, in that case, it's truncated
→ No more useless whitespaces :)
→ and maybe a few more little fixes I can't remember right now...
The branch applies onto naquadah/master
As every time, I'm eager to receive feedback :)
Ah yeah, now that I sent that mail, I remember one important bugfix:
If no layout function is given, a table with simple geometries is pushed onto
the stack, the geometries have they x and y set to 0 and their width and height
to the widgets demands or the wibox dimensions, whichever is smaller
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
signature.asc
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At 1237076946 time_t, Gregor Best wrote: I just realized that my commit history is pretty dirty on that branch (a lot of merges and such), so i cleaned it a bit and put that into git://git.mercenariesguild.net/awesome widget-layout-clean that branch has a lot cleaner history and applies onto naquadah/main Actually, it's not perfect. I've reworked it a bit: - rebase on master - rebase -i with edit of patches that had whitespaces - rebase -i with edit of patches that had debug printf - rebase -i with squashing of patches that fixes previous commits (I don't need to know you fucked up the commit the first time[1]) - rebase -i with amending of commit descriptions[2] - Fixed a warning about uninit value in widget. - Remove test modification of awesomerc.lua.in I ran the code, and saw no error of any kind, just no tasklist at first glance. The branch seems pretty clean (as in that one could be merged), so I suggest you continue to work based on it, and rebase it on master regularly (don't git pull, but git pull --rebase). I won't touch it myself I just did some cleaning because it's better to do it now that latter. Since I might have broke some things, I'll let you check the state of what I did before we go on some debugging. Anyhow, thanks for this huge work, Gregor. [1] If you see that there's a bug in a previous commit, do not add another commit to fix it: as I said, I don't care you fucked the commit. You just have to run rebase -i commitid~, then change pick with edit on the bad patch. Edit the patch, git add filename, git rebase --continue, and you will have a set of brand new correct patches. And I won't see your ooops history :-) [2] I prefer to use awful.widget.tasklist rather than lib/awful/widget/tasklist. The description part of commits is just informative, you do not need neither to pu the filename (i.e. widget.c) you edited, git log show that. That just people following commit to see which part of awesome we did change (wibox, awful.something, etc). -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1237208479 time_t, Julien Danjou wrote: I ran the code, and saw no error of any kind, just no tasklist at first glance. Err, no it's ok, I must had some bad things in my build dir that broke it, now the default config works flawlessly. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
Okay, i could need some help here. It looks like everytime a wibox with a border is created (for example by naughty), the following error occurs: W: awesome: xerror:289: X error: request=CreatePixmap, error=BadAlloc W: awesome: xerror:289: X error: request=149, error=BadDrawable W: awesome: xerror:289: X error: request=149, error=164 W: awesome: xerror:289: X error: request=CopyArea, error=BadDrawable W: awesome: xerror:289: X error: request=CopyArea, error=BadDrawable W: awesome: xerror:289: X error: request=FreePixmap, error=BadPixmap W: awesome: xerror:289: X error: request=149, error=164 the easiest way to trigger this is to use naughty.notify() to spawn a notification, you'll see the screen flicker and that message appears on stderr. I'm pretty sure the reason for this has to do with borders, because if you remove the border setting from lib/naughty.lua, lines 369 and 370, the error doesn't show up and the screen does not flicker. Also, after some time with borders on and spawning new notifications in regular intervals (in my case a song change notification from cmus), the newly spawned wibox seems to steal some of the content from my regular wibox (i.e. it looks as if I did some copy and paste on the leftmost part of my status bar and pasted it below my clock) I'm totally out of ideas as to what could be causing this, so any help is appreciated greatly :) -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best signature.asc Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At Sun, 15 Mar 2009 01:07:00 +0100
Gregor Best wrote:
Hi people,
again I took some time to further refine widget layouts, and I think what I
have is now quite usable.
- widget.align is no longer neccessary. Where a widget is placed is now
exclusively defined by what layout function calculates its geometry
- I rewrote the flex alignment in lua as awful.widget.layout.horizontal.flex
it's usable at the moment, though with the limitation that only one group of
widgets can use the flex layout on a given wibox and nesting doesn't work
inside of the flex layout, i.e. nested layouts like
{
w1,
w2,
{
w3,
w4,
[layout] = awful.widget.layout.horizontal.leftright
}
[layout] = awful.widget.layout.horizontal.flex
}
result in all widgets { w1, w2, w3, w4 } being placed using the flex layout
- I didn't yet look into the imagebox resizing issue, all widget layouts still
make a square of the imagebox. I think there were some misunderstandings on
this previously, as this isn't done to force a certain size on the image,
but to keep the widget from occupying too much space (this can easily be seen
if the check for v.resize is removed from the widget layouts, have a look at
the taglist then, you'll notice the widgets occupy more horizontal space than
is neccessary for the image to be rendered)
Once again, all needed patches are on git://git.mercenariesguild/awesome,
branch widget-layout. I rebased them onto master, so a recent git HEAD from
git://git.naquadah.org/awesome or git://git.mercenariesguild.net/awesome is
neccessary for the patches to apply.
I'd greatly appreciate any input, wishes, bug reports, whatever :)
I just realized that my commit history is pretty dirty on that branch (a lot of
merges and such), so i cleaned it a bit and put that into
git://git.mercenariesguild.net/awesome widget-layout-clean
that branch has a lot cleaner history and applies onto naquadah/main
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
signature.asc
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At Tue, 10 Feb 2009 18:09:38 +0100 Julien Danjou wrote: At 1234284274 time_t, Gregor Best wrote: I created a patch to achieve this, it adds an :extents() function to each widget. It expects one argument, which is the container height. Also, if the widget is a systray, it expects a screen number as the second argument. If either of these is omitted, 1 is assumed instead. Seems rather good to me. I won't merge into master right now, so I advise you to keep it in your branch and continue working on it for now. Cheers, Okay kids, time for another update on this :) It's been some while since I updated last, but with a little help from Julien, I now present the first version of widget layouts in Lua I'd use myself. It's far from perfect, but surprisingly usable. Those who dare to try it can grab my latest git HEAD from git://git.mercenariesguild.net/awesome.git, the branch is called widget-layout. Things which are kinda hacky / not working as I'd like them to are: - With the example layout i added to awesomerc.lua, there's no flex alignment. If a widget uses the flex alignment, its geometry will be calculated as if it were left aligned. - For some reason, textboxes have their background drawn in wonderful background color as you'd expect, _unless_ they are used in the tasklist. I have no real explanation for this, as the task- and taglist basically use the very same function to set up their subwidgets and the problem doesn't appear on taglists. - To prevent the order in which your widgets appear on the wibox, you have to reorder right aligned widgets. They have to appear in the order they should appear on the wibox, but from _right to left_ as opposed to the usual left-to-right. - I see this as an ugly hack, but I couldn't come up with a better solution: If an imagebox has its resize field set to true, its width is changed to be equal to its height. I don't know how the old C code handled this, but i doubt this is an optimal solution to not waste space. - Taglist squares appear to be unusual small, I suspect an error in widgets/textbox.c:textbox_draw, lines 98 to 119 These are all things which are bugging me at the moment, but there might be more. -- GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+ e- h! r y+ Gregor Best signature.asc Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At 1235674575 time_t, Gregor Best wrote: Okay kids, time for another update on this :) It's been some while since I updated last, but with a little help from Julien, I now present the first version of widget layouts in Lua I'd use myself. It's far from perfect, but surprisingly usable. Those who dare to try it can grab my latest git HEAD from git://git.mercenariesguild.net/awesome.git, the branch is called widget-layout. Nice work Greg! Things which are kinda hacky / not working as I'd like them to are: - With the example layout i added to awesomerc.lua, there's no flex alignment. If a widget uses the flex alignment, its geometry will be calculated as if it were left aligned. I'm not even sure we want alignment. I'd really suggest to try to remove align attributes. I think we rather want things like packing. - I see this as an ugly hack, but I couldn't come up with a better solution: If an imagebox has its resize field set to true, its width is changed to be equal to its height. I don't know how the old C code handled this, but i doubt this is an optimal solution to not waste space. Well, the right hack IMHO is to return the image size. If the imagebox is for whatever reason rendered in a smaller box, then it would use its .resize flag to resize the image. Otherwise it will render a part of the image only. And if you want to have a smaller imagebox than the image, just resize the image, you've everything you need to do this in the image library. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust me. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1234284274 time_t, Gregor Best wrote: I created a patch to achieve this, it adds an :extents() function to each widget. It expects one argument, which is the container height. Also, if the widget is a systray, it expects a screen number as the second argument. If either of these is omitted, 1 is assumed instead. Seems rather good to me. I won't merge into master right now, so I advise you to keep it in your branch and continue working on it for now. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1233668296 time_t, Gregor Best wrote:
I'll try to write some demo-code for that either today or tomorrow, so we
can discuss this with some real code to work on.
Okay, as promised, here is a first, simple, draft. Right now, it works as
follows:
When we want to render a wibox, we just call widget_render(wibox_t *), as usual.
widget_render(wibox_t *) then calls widget_geometries(luaA_ref, area_t), which
gets a reference to the widget table of the wibox (which includes the layout
field) and the wibox geometry (so we know where on the screen the wibox is
placed and how big it is).
widget_geometries(luaA_ref, area_t) then calls the layout function with the
widget table as the first and the wibox geometry as the second argument.
The layout function calculates eachs widgets geometry as it wants and returns a
table with all geometries. Things like
{w1, w2, {w3, w4}} are flattened to
{w1, w2, w3, w4}
widget_render(wibox_t *) then simply pulls all geometries from the stack, one
after each other and sets the widget geometry.
I included a very simple example widget layout which just sets the widget width
to 50 and places them left to right one next to each other. If a table is
encountered and the table has a layout field, the function in that field is
called with the table as the first and a modified boundary as the second
argument. If no layout field exists, the function simply recurses. The return
value from that call will then be appended to the list of widget geometries
already calculated.
Again, share your thoughts :)
P.S. the attached patch works if applied against the widget-layouts branch, i
didn't try master, but i don't see why it wouldn't work there.
--
Gregor Best
From 1cf5bc3947f1bafcc018bc0b4f889819d9c4d5e4 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Wed, 4 Feb 2009 16:05:59 +0100
Subject: [PATCH] widget layouts: first try
Signed-off-by: Gregor Best farha...@googlemail.com
---
awesomerc.lua.in | 39 +++-
widget.c | 108 +++---
widget.h |1 +
3 files changed, 85 insertions(+), 63 deletions(-)
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index cc43e9f..eea931a 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -128,6 +128,41 @@ mytasklist.buttons = { button({ }, 1, function (c) client.focus = c; c:raise() e
button({ }, 4, function () awful.client.focus.byidx(1) end),
button({ }, 5, function () awful.client.focus.byidx(-1) end) }
+function widget_layout_test(widgets, bounds)
+local geometries = { }
+local pos = bounds
+
+for k, v in ipairs(widgets) do
+print(k, tostring(v))
+if type(v) == table then
+l = v[layout] or widget_layout_test
+local g = widget_layout_test(v, { [x] = pos.x,
+ [y] = pos.y,
+ [height] = bounds.height - pos.y,
+ [width] = bounds.width - pos.x })
+if #g 0 then
+pos.x = g[#g].x + g[#g].width
+pos.y = g[#g].y + g[#g].height
+end
+
+for _, w in pairs(g) do
+table.insert(geometries, w)
+end
+else
+local g = { [x] = pos.x,
+[y] = pos.y,
+[height] = pos.height,
+[width] = 50 }
+pos.x = pos.x + g.width
+table.insert(geometries, g)
+end
+end
+
+print(#geometries, geometries calculated)
+return geometries
+end
+
+
for s = 1, screen.count() do
-- Create a promptbox for each screen
mypromptbox[s] = widget({ type = textbox, align = left })
@@ -155,7 +190,9 @@ for s = 1, screen.count() do
mypromptbox[s],
mytextbox,
mylayoutbox[s],
- s == 1 and mysystray or nil }
+ s == 1 and mysystray or nil,
+ [layout] = widget_layout_test
+ }
mywibox[s].screen = s
end
-- }}}
diff --git a/widget.c b/widget.c
index 7f46197..e14a822 100644
--- a/widget.c
+++ b/widget.c
@@ -142,6 +142,26 @@ luaA_table2widgets(lua_State *L, widget_node_array_t *widgets)
}
}
+/** Get a list of widget geometries according to layout function
+ * \param wibox The widgets table (a lua ref)
+ */
+
+void
+widget_geometries(luaA_ref widgets_table, area_t wibox_geometry)
+{
+lua_State *L = globalconf.L;
+luaA_ref layout = LUA_REFNIL;
+
+lua_rawgeti(L, LUA_REGISTRYINDEX, widgets_table);
+lua_getfield(L, -1, layout);
+if (lua_isfunction(L, -1))
+luaA_registerfct(L, -1, layout);
+lua_pop(L, 1);
+
+luaA_pusharea(L, wibox_geometry);
+luaA_dofunction(globalconf.L, layout, 2, 1);
+}
+
Re: [Draft] Introduction of Widget Layouts
As usual, i noticed an error right after sending the patch :)
The recursion doesn't work in the patch i sent, a fixed version is attached.
--
Gregor Best
From 438abd4cbd56b4a05009db5b22f5c839c1a9e1e2 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Wed, 4 Feb 2009 16:05:59 +0100
Subject: [PATCH] widget layouts: first try
Signed-off-by: Gregor Best farha...@googlemail.com
---
awesomerc.lua.in | 39 +++-
widget.c | 108 +++---
widget.h |1 +
3 files changed, 85 insertions(+), 63 deletions(-)
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index cc43e9f..64a27fe 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -128,6 +128,41 @@ mytasklist.buttons = { button({ }, 1, function (c) client.focus = c; c:raise() e
button({ }, 4, function () awful.client.focus.byidx(1) end),
button({ }, 5, function () awful.client.focus.byidx(-1) end) }
+function widget_layout_test(widgets, bounds)
+local geometries = { }
+local pos = bounds
+
+for k, v in ipairs(widgets) do
+print(k, tostring(v))
+if type(v) == table then
+local l = v[layout] or widget_layout_test
+local g = l(v, { [x] = pos.x,
+ [y] = pos.y,
+ [height] = bounds.height - pos.y,
+ [width] = bounds.width - pos.x })
+if #g 0 then
+pos.x = g[#g].x + g[#g].width
+pos.y = g[#g].y + g[#g].height
+end
+
+for _, w in pairs(g) do
+table.insert(geometries, w)
+end
+else
+local g = { [x] = pos.x,
+[y] = pos.y,
+[height] = pos.height,
+[width] = 50 }
+pos.x = pos.x + g.width
+table.insert(geometries, g)
+end
+end
+
+print(#geometries, geometries calculated)
+return geometries
+end
+
+
for s = 1, screen.count() do
-- Create a promptbox for each screen
mypromptbox[s] = widget({ type = textbox, align = left })
@@ -155,7 +190,9 @@ for s = 1, screen.count() do
mypromptbox[s],
mytextbox,
mylayoutbox[s],
- s == 1 and mysystray or nil }
+ s == 1 and mysystray or nil,
+ [layout] = widget_layout_test
+ }
mywibox[s].screen = s
end
-- }}}
diff --git a/widget.c b/widget.c
index 7f46197..e14a822 100644
--- a/widget.c
+++ b/widget.c
@@ -142,6 +142,26 @@ luaA_table2widgets(lua_State *L, widget_node_array_t *widgets)
}
}
+/** Get a list of widget geometries according to layout function
+ * \param wibox The widgets table (a lua ref)
+ */
+
+void
+widget_geometries(luaA_ref widgets_table, area_t wibox_geometry)
+{
+lua_State *L = globalconf.L;
+luaA_ref layout = LUA_REFNIL;
+
+lua_rawgeti(L, LUA_REGISTRYINDEX, widgets_table);
+lua_getfield(L, -1, layout);
+if (lua_isfunction(L, -1))
+luaA_registerfct(L, -1, layout);
+lua_pop(L, 1);
+
+luaA_pusharea(L, wibox_geometry);
+luaA_dofunction(globalconf.L, layout, 2, 1);
+}
+
/** Render a list of widgets.
* \param wibox The wibox.
* \todo Remove GC.
@@ -149,6 +169,7 @@ luaA_table2widgets(lua_State *L, widget_node_array_t *widgets)
void
widget_render(wibox_t *wibox)
{
+lua_State *L = globalconf.L;
draw_context_t *ctx = wibox-sw.ctx;
int left = 0, right = 0;
area_t rectangle = { 0, 0, 0, 0 };
@@ -156,6 +177,9 @@ widget_render(wibox_t *wibox)
rectangle.width = ctx-width;
rectangle.height = ctx-height;
+widget_geometries(wibox-widgets_table, wibox-sw.geometry);
+
+//{{{
if(ctx-bg.alpha != 0x)
{
int x = wibox-sw.geometry.x, y = wibox-sw.geometry.y;
@@ -202,6 +226,7 @@ widget_render(wibox_t *wibox)
p_delete(prop_r);
}
}
+//}}}
widget_node_array_t *widgets = wibox-widgets;
@@ -209,71 +234,30 @@ widget_render(wibox_t *wibox)
widget_node_array_init(widgets);
lua_rawgeti(globalconf.L, LUA_REGISTRYINDEX, wibox-widgets_table);
luaA_table2widgets(globalconf.L, widgets);
+lua_pop(L, 1);
/* compute geometry */
+if (lua_istable(L, -1))
+fprintf(stderr, stack top is table\n);
+fprintf(stderr, placing %d widgets for wibox %p\n, widgets-len, wibox);
for(int i = 0; i widgets-len; i++)
-if(widgets-tab[i].widget-align == AlignLeft widgets-tab[i].widget-isvisible)
-{
-widgets-tab[i].geometry = widgets-tab[i].widget-geometry(widgets-tab[i].widget,
-wibox-screen, ctx-height,
-
Re: [Draft] Introduction of Widget Layouts
Hi Gregor,
At 1233760478 time_t, Gregor Best wrote:
When we want to render a wibox, we just call widget_render(wibox_t *), as
usual.
So far, so good.
widget_render(wibox_t *) then calls widget_geometries(luaA_ref, area_t), which
gets a reference to the widget table of the wibox (which includes the layout
field) and the wibox geometry (so we know where on the screen the wibox is
placed and how big it is).
widget_geometries(luaA_ref, area_t) then calls the layout function with the
widget table as the first and the wibox geometry as the second argument.
The layout function calculates eachs widgets geometry as it wants and returns
a
table with all geometries. Things like
{w1, w2, {w3, w4}} are flattened to
{w1, w2, w3, w4}
Well, that'd be ok for now, but you'll need to recursive later.
widget_render(wibox_t *) then simply pulls all geometries from the stack, one
after each other and sets the widget geometry.
I included a very simple example widget layout which just sets the widget
width
to 50 and places them left to right one next to each other. If a table is
encountered and the table has a layout field, the function in that field is
called with the table as the first and a modified boundary as the second
argument. If no layout field exists, the function simply recurses. The
return
value from that call will then be appended to the list of widget geometries
already calculated.
Again, share your thoughts :)
The current implementation seems fine so far.
I'd just add some things:
- Start right now by adding a patch to export each $widget_geometry()
function on Lua side. Layouts functions will require it to know how
much space a layout need. The $widget_geometry() function will have to
return the *real* *needed* geometry. If it can then only renders a
part of its content, good for it. (i.e. textbox can by using
ellipsize).
- Split your commits right now; or you'll send me a 2K SLOC patches and
I'll yell at you to split it, and you'll hate me. :)
- If needed drop/replace/change/whatever the align stuff. I'm not sure
we'll be happy to have them for ever.
- Take a look at the GTK layout system. It's a bit what you are writing
here (request geometry, then draw with a computed geometry).
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
Hi Gregor,
I'm happy you launch that topic!
At 1233588224 time_t, Gregor Best wrote:
a while ago, Julien mentioned widget layouts to me, i.e. deciding where to
render a widget with some lua function instead of a hardcoded calculation,
similar to how clients are laid out with lua functions. Today, i took a few
minutes and created a first draft on how we could accomplish this:
[...]
please share your thoughts :)
Well, when I though about this, I had a somewhat different approach.
Register layout function for wibox:
wibox.widgets = { widget1, widget2, layout = awful.widget.layout.foo }
Allowing such things:
wibox.widgets = { widget1,
widget2,
{ widget3, widget4, layout =
awful.widget.layout.horizontal }
layout = awful.widget.layout.vertical }
Still, you'll have to watch out for recursions, but we already have some
code for that AFAIK.
This keep the widgets attributes of wiboxes being a simple DAG[1] with
only a special key added, `layout', which is a special function to
handle this.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At Tue, 3 Feb 2009 10:44:04 +0100
Julien Danjou wrote:
Well, when I though about this, I had a somewhat different approach.
Register layout function for wibox:
wibox.widgets = { widget1, widget2, layout = awful.widget.layout.foo }
Allowing such things:
wibox.widgets = { widget1,
widget2,
{ widget3, widget4, layout =
awful.widget.layout.horizontal } layout = awful.widget.layout.vertical }
Still, you'll have to watch out for recursions, but we already have some
code for that AFAIK.
This keep the widgets attributes of wiboxes being a simple DAG[1] with
only a special key added, `layout', which is a special function to
handle this.
Cheers,
Hmm, that'd be an even better idea, if we were to do it this way, we (at least
for the beginning) wouldn't have to care for the a wibox in a wibox scenario,
as the same could be accomplished like your example.
I'll try to write some demo-code for that either today or tomorrow, so we can
discuss this with some real code to work on.
--
Gregor Best
signature.asc
Description: PGP signature
Re: [Draft] Introduction of Widget Layouts
At 1233668296 time_t, Gregor Best wrote: Hmm, that'd be an even better idea, if we were to do it this way, we (at least for the beginning) wouldn't have to care for the a wibox in a wibox scenario, as the same could be accomplished like your example. I'll try to write some demo-code for that either today or tomorrow, so we can discuss this with some real code to work on. That'd be lovely. I've push a patch in the `widget-layout' branch that might be useful to you. Don't worry if you don't see why it's useful right now, you might see it later. :-) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
