Re: Plan E (was: [RFC] Titlebar code)
On Tue, 15 Sep 2009 00:06:19 +0200 (CEST) lukash lukk...@email.cz wrote: Lastly, if clients and widgets have common properties inherited from windows, how will these properties be handled on, for example, the icon widget in the example above, ie. in a widget inside a widget? Seems like a bit of an inconsistency here (maybe top-level widgets should be differentiated after all... we could call them... a wibox, maybe? :D). I just realized the exactly same thing happens to clients too. Top-level clients have window-like properties while child clients don't. A simple solution would be to have a window object, which would hold the windows properties, and would serve as parent to clients and widgets. And only windows could have root window (or screen[N]) as their parent. But this adds an unnecesary level of reparentation... Maybe an attribute .type = window (or, as we only have 2 states, it could be .is_window = true) would work too, giving the widget/client window-like properties, and defining whether it can be parented only to root window or only to another widget. Any better ideas? :) lukash -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #622 - Awesome keeps loading default theme
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#622 - Awesome keeps loading default theme User who did this - koniu (koniu) Reason for closing: Duplicate Additional comments about closing: Duplicate of FS#611 http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=611 More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=622 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Plan E (was: [RFC] Titlebar code)
Hi lukash,
It'd be nice if your MUA can wrap lines at ~72 chars. :)
At 1252965979 time_t, lukash wrote:
2. - that would need the .widgets table where you would set the layout, which
you (jd) want to remove. IMHO, you should have this information anyway,
either only as an array in C that would list all child widgets belonging to
the parent widget, and probably also as a read-only table in LUA. You need
this in the layout function and maybe for other things too. The child list
would be maintained by setting the .parent to the child. As it should be read
only (or should it?) in lua, you'd need to go the 1. way anyway :)
Yes, getting children would be a wibox method, so you can arrange all
its children as you please.
I think it would be good to have the layouts written in C, although it may be
a bit harder to write them, but it will be faster, and there is no other
reason to have them in lua? (except someone would wanna write his own, but it
should not be needed :)
Having layout written in C is just more limiting than having them in Lua
and brings nothings but less extendability (is this a word?).
Also, note that since you remove the nested tables in .widgets, you'll need
to nest widgets to create complex layouts, eg. a window with a titlebar:
window = wibox{ parent = screen[1].root, layout = topdown }
titlebar = wibox{ parent = window, layout = leftright }
icon = wibox{ parent = titlebar }
title = wibox{ parent = titlebar }
...
c = client{ parent = window }
Here, the titlebar widget is just a container for the pieces... I guess its
ok. (btw, .layout on widgets without children should be ignored, thats ok too
I think)
Yes, it's ok. Wibox can be containers, or can have things drawn inside.
Or even both (might not render very good but YMMV).
Lastly, if clients and widgets have common properties inherited from
windows, how will these properties be handled on, for example, the icon
widget in the example above, ie. in a widget inside a widget? Seems like a
bit of an inconsistency here (maybe top-level widgets should be
differentiated after all... we could call them... a wibox, maybe? :D).
It's really not inconsistent. It's how X works after all. :)
Anyway, I love the idea! I'm looking forward to it :) btw, I've been messing
with the layouts that Gregor sent, now I'm not sure I should go on, as it
seems it will be replaced soon now, and the basic layouts are working anyway..
AFAICT, it will not be replaced. It will probably be adapted and used in
a little different way, but not simply removed. So you can go on. :)
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: Plan E (was: [RFC] Titlebar code)
On 15.9.2009 10:47:47 Julien Danjou jul...@danjou.info wrote: It'd be nice if your MUA can wrap lines at ~72 chars. :) Yes, I'll try :) I'm sorry Having layout written in C is just more limiting than having them in Lua and brings nothings but less extendability (is this a word?). Except for less extendability (I think it is :) it brings speed. I'm not sure if you have any experience with lua speed in awesome, I just found this: http://www.timestretch.com/FractalBenchmark.html showing lua is about 30 times slower than C (the actual ratio in this case may vary by as much as 50% IMHO). The layout function could be called a lot (again I'm not sure how much though), its a bit long and with complex layouts is called recursively.. and so it could have an impact on slower mashines (and awesome is supposed to be lightweight..). you don't think it could be an issue? It's really not inconsistent. It's how X works after all. :) I'm not convinced :P (see my last mail, windows parented to root and those parented to wibox both have quite different sets of properties) AFAICT, it will not be replaced. It will probably be adapted and used in a little different way, but not simply removed. So you can go on. :) I will, and I'll also put a counter in there to see how much it gets called :) Anyway, just my 2 cents... lukash -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Plan E (was: [RFC] Titlebar code)
At 1253017547 time_t, lukk...@email.cz wrote: Except for less extendability (I think it is :) it brings speed. Speed? Why do you want to bring speed? Is it currently slow? Speed for speed brings nothing. I'm not sure if you have any experience with lua speed in awesome, I just found this: http://www.timestretch.com/FractalBenchmark.html showing lua is about 30 times slower than C (the actual ratio in this case may vary by as much as 50% IMHO). The layout function could be called a lot (again I'm not sure how much though), its a bit long and with complex layouts is called recursively.. and so it could have an impact on slower mashines (and awesome is supposed to be lightweight..). you don't think it could be an issue? No, I don't think so. Yes Lua is probably 30 times slower than C, but it's still damn fast. When things will get too slow for a proper usage on any modern computer (sorry, I don't target 75 MHz processor) we'll see. So far, the profiling we did never pointed out any point of slowness in Lua. We rather have speed issue with cairo being a bit slow to render things. And I trust *real usage profiling*. I don't trust special case benchmarking. I'm not convinced :P (see my last mail, windows parented to root and those parented to wibox both have quite different sets of properties) That's a different issue. What we do with windows is not X problem, but ours. And we'll find a clean and correct solution to handle such the design we are starting to implement. :) 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
Mouse motion detection
Hi there, I am trying to write a little odometer widget to have mouse coordinates displayed somewhere in the status bar for example (a very unuseful so indispensable stuff ;-)) There are many way to do this: - use a timer: each X seconds grab the mouse coordinates using the capi mouse.coords() function pros: Simple and easy. cons: Would be overkill in case of inactivity. Some events can be lost due to the X seconds granularity. - Add a mouse::mouse signal: This would be the most elegant solution. pros: Updates are only done if necessary. Events could be used by any Lua object. cons: Need to modify the C-side code. Need to redesign some part of code (?) - Other ? Does any one have any opinion or idea regarding that problematic ? Thanks Cheers -- Sébastien Gross -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Mouse motion detection
On Tue, Sep 15, 2009 at 04:46:04PM +0200, jul...@danjou.info wrote: Thanks for the quick answer. And you can miss events anyway. If you update every 0.1 seconds, maybe the pointer is at the same place or very near but the user did a very fast movement. :) Anyway, using such a short timer resolution wouldn't let awesome spend time on that particular timer function ? Yes, I've downloaded kodo source code, an old KDE odometer (part of kde 3.5, but not part of KDE 4 anymore AFAICS). And the solution used is the timer one. :) This was my first option. I guess this is the most less worst one ;-). Thanks Cheers -- Sébastien Gross -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Mouse motion detection
At 1253027134 time_t, Sébastien Gross wrote: Anyway, using such a short timer resolution wouldn't let awesome spend time on that particular timer function ? It'll wake awesome very often, which is bad for CPU sleeping and all power management stuff, but that's your problem. ;-) I don't think it'll add any disruptive behaviour. Unless you wake awesome every 0.1 second to do 5 second long computing. Then you'll break it. -- 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: Plan E (was: [RFC] Titlebar code)
Hi again, I've started to dig further into this plan, and will add a number of ideas/concepts/how-it-will-be things. Feel free to discuss. - We cares about tags only on top level object in the hierarchy: +--+ | root win | +--+ | +--+--+ | | ++++ | client || wibox | -- top level windows ++++ | ++ || ++ ++ | wibox | | client | ++ ++ That means all client/wibox objects can have tags, but we will only honor the top level windows one. - On .parent setting, wibox creates a X window attached to the requested parent window and is unmapped. To be mapped they should be .visible or have a tag if they are parented to a root window. - Wibox will be destroyed on .parent = nil. If they have a client as child, the client will be reparented to the root window. (Otherwise it would be destroy by the X server.) I'm thinking about having only one Lua type for wibox and client, and not use inheritance at all. The only difference would be a little flag (if needed, but I think it will), and that the xcb_window_t window will be: - in client case, created/destroyed by the application - in wibox case, created_destroyed by awesome Currently unresolved issue: - How to handle EWMH request, like fullscreen, sticky, etc? -- 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
[RFC Patch] Move c:raise() to the focus signal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
what do you guys think about the attached patch? I haven't test this at all yet,
but it seems as if it makes sense to me. Testing the default config is icky. :(
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)
iQEcBAEBCAAGBQJKr9unAAoJECLkKOvLj8sGgQkIAL396tyrCFeyzIZ0trWZa7HL
vGEjdkOUenzn56Y1hNeeWDxtLkSf+KG2/5xFWrRncPjZQ6cCvS4oKow7UI/yd60J
0S4FZzNisdJJL1PnilrXRSCU+h38IL2SJyhLzigYcH2cRH8ZqVa0nG4Qlji7ombV
RyDgTaumbIrod0xm4ugrHTnG+zqKQgr7FmSOJMwl0eWLZJJxeWCEmvHIkqJh6uLI
wz1m5gHX7RPf33ZInD99WmHKW18/p0AaR0qEqjWJN2TTYF/jxhLnMe5W3Cta6FgR
jHAhRmhUBB3oGNnHQh/fzwN1NGG1a1DOn+Bb48U06BmcWYixC69nduUnK6UpRWs=
=y25C
-END PGP SIGNATURE-
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 7c0360b..e8ce71b 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -92,7 +92,6 @@ mytasklist.buttons = awful.util.table.join(
awful.tag.viewonly(c:tags()[1])
end
client.focus = c
- c:raise()
end),
awful.button({ }, 3, function ()
if instance then
@@ -104,11 +103,9 @@ mytasklist.buttons = awful.util.table.join(
end),
awful.button({ }, 4, function ()
awful.client.focus.byidx(1)
- if client.focus then client.focus:raise() end
end),
awful.button({ }, 5, function ()
awful.client.focus.byidx(-1)
- if client.focus then client.focus:raise() end
end))
for s = 1, screen.count() do
@@ -166,12 +163,10 @@ globalkeys = awful.util.table.join(
awful.key({ modkey, }, j,
function ()
awful.client.focus.byidx( 1)
-if client.focus then client.focus:raise() end
end),
awful.key({ modkey, }, k,
function ()
awful.client.focus.byidx(-1)
-if client.focus then client.focus:raise() end
end),
awful.key({ modkey, }, w, function () mymainmenu:show(true)end),
@@ -181,13 +176,7 @@ globalkeys = awful.util.table.join(
awful.key({ modkey, Control }, j, function () awful.screen.focus_relative( 1) end),
awful.key({ modkey, Control }, k, function () awful.screen.focus_relative(-1) end),
awful.key({ modkey, }, u, awful.client.urgent.jumpto),
-awful.key({ modkey, }, Tab,
-function ()
-awful.client.focus.history.previous()
-if client.focus then
-client.focus:raise()
-end
-end),
+awful.key({ modkey, }, Tab, awful.client.focus.history.previous),
-- Standard program
awful.key({ modkey, }, Return, function () awful.util.spawn(terminal) end),
@@ -267,7 +256,7 @@ for i = 1, keynumber do
end
clientbuttons = awful.util.table.join(
-awful.button({ }, 1, function (c) client.focus = c; c:raise() end),
+awful.button({ }, 1, function (c) client.focus = c end),
awful.button({ modkey }, 1, awful.mouse.client.move),
awful.button({ modkey }, 3, awful.mouse.client.resize))
@@ -315,6 +304,8 @@ client.add_signal(manage, function (c, startup)
-- awful.client.setslave(c)
end)
+client.add_signal(focus, function(c) c:raise() end)
+
client.add_signal(focus, function(c) c.border_color = beautiful.border_focus end)
client.add_signal(unfocus, function(c) c.border_color = beautiful.border_normal end)
-- }}}
Re: [RFC Patch] Move c:raise() to the focus signal
On Tue, 15 Sep 2009, Uli Schlachter wrote: Hi, Testing the default config is icky. :( I can confirm that it works, and nothing is broken. -- Adrian C. (anrxc) | anrxc..sysphere.org | PGP ID: D20A0618 PGP FP: 02A5 628A D8EE 2A93 996E 929F D5CB 31B7 D20A 0618 -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [RFC Patch] Move c:raise() to the focus signal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adrian C. wrote: On Tue, 15 Sep 2009, Uli Schlachter wrote: Hi, Testing the default config is icky. :( I can confirm that it works, and nothing is broken. In that case feel free to steal it and sign it off for jd. Thanks for doing my testing work. :D Else I'll submit this after the release... 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) iQEcBAEBCAAGBQJKr+MNAAoJECLkKOvLj8sG81MH/j62iSqTcyCNOK7p27olf0Tu 2ao74vlrfgxiXEzlyeBZ/PbGuXaMAqnt+PdycevQd3X2cQ2pcxP5stfbIibEq2cK gv4BbbZX8+4IxFEx3Xlh105qt7HKZD+x5Lvg8t/sbXyuOsPSHazc9gOtY9URItdn wqmrjS3SxxxfeZV4APQ0NADk1qZLu2G55yWqkZ4yJAsjJ6eTqK6wBdjnWbB2WrCS Vnfs+60W/8rvu5Nh1EQr+gNmrcGs1o9g+Iiz6fx9yJXvCIezaqXHyf5nSrYeIDgC sGVjbznaY/UBh8iZyn9X41v4z3HZFkYwLl+m7/vZWqWIpNy9296Hkazl2B3ERLI= =2Oa/ -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [RFC Patch] Move c:raise() to the focus signal
On Tue, 15 Sep 2009, Uli Schlachter wrote:
I can confirm that it works, and nothing is broken.
In that case feel free to steal it and sign it off for jd. Thanks
for doing my testing work. :D
Ok, it is attached.
--
Adrian C. (anrxc) | anrxc..sysphere.org | PGP ID: D20A0618
PGP FP: 02A5 628A D8EE 2A93 996E 929F D5CB 31B7 D20A 0618
From 6a06ae74268d52c8fe617f60b0806422e6230038 Mon Sep 17 00:00:00 2001
From: Adrian C. (anrxc) an...@sysphere.org
Date: Tue, 15 Sep 2009 20:59:29 +0200
Subject: [PATCH] Move c:raise() to the focus signal
Signed-off-by: Adrian C. (anrxc) an...@sysphere.org
---
awesomerc.lua.in | 17 -
1 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 7c0360b..e8ce71b 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -92,7 +92,6 @@ mytasklist.buttons = awful.util.table.join(
awful.tag.viewonly(c:tags()[1])
end
client.focus = c
- c:raise()
end),
awful.button({ }, 3, function ()
if instance then
@@ -104,11 +103,9 @@ mytasklist.buttons = awful.util.table.join(
end),
awful.button({ }, 4, function ()
awful.client.focus.byidx(1)
- if client.focus then
client.focus:raise() end
end),
awful.button({ }, 5, function ()
awful.client.focus.byidx(-1)
- if client.focus then
client.focus:raise() end
end))
for s = 1, screen.count() do
@@ -166,12 +163,10 @@ globalkeys = awful.util.table.join(
awful.key({ modkey, }, j,
function ()
awful.client.focus.byidx( 1)
-if client.focus then client.focus:raise() end
end),
awful.key({ modkey, }, k,
function ()
awful.client.focus.byidx(-1)
-if client.focus then client.focus:raise() end
end),
awful.key({ modkey, }, w, function () mymainmenu:show(true)
end),
@@ -181,13 +176,7 @@ globalkeys = awful.util.table.join(
awful.key({ modkey, Control }, j, function ()
awful.screen.focus_relative( 1) end),
awful.key({ modkey, Control }, k, function ()
awful.screen.focus_relative(-1) end),
awful.key({ modkey, }, u, awful.client.urgent.jumpto),
-awful.key({ modkey, }, Tab,
-function ()
-awful.client.focus.history.previous()
-if client.focus then
-client.focus:raise()
-end
-end),
+awful.key({ modkey, }, Tab,
awful.client.focus.history.previous),
-- Standard program
awful.key({ modkey, }, Return, function ()
awful.util.spawn(terminal) end),
@@ -267,7 +256,7 @@ for i = 1, keynumber do
end
clientbuttons = awful.util.table.join(
-awful.button({ }, 1, function (c) client.focus = c; c:raise() end),
+awful.button({ }, 1, function (c) client.focus = c end),
awful.button({ modkey }, 1, awful.mouse.client.move),
awful.button({ modkey }, 3, awful.mouse.client.resize))
@@ -315,6 +304,8 @@ client.add_signal(manage, function (c, startup)
-- awful.client.setslave(c)
end)
+client.add_signal(focus, function(c) c:raise() end)
+
client.add_signal(focus, function(c) c.border_color = beautiful.border_focus
end)
client.add_signal(unfocus, function(c) c.border_color =
beautiful.border_normal end)
-- }}}
--
1.6.4.3
Re: Plan E (was: [RFC] Titlebar code)
On Tue, 15 Sep 2009 14:34:13 +0200 (CEST) Julien Danjou jul...@danjou.info wrote: [...] Ok, I surrender :) I know I know nothing... Just keep it awesome! :) thanks lukash -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Multiple wibox on same 'position'
Hi,
As some may know, two wiboxes cannot be created with same 'position' field
in awesome 3.4, when in 3.3, the second declared wibox would appear just
under the first.
I worked on a small patch which modifies screen.c and awful/wibox.lua. Seems
to be working for me so far (I work with one wibox for various widgets + one
for tasks but I also tested it with two wiboxes top and one bottom).
However I admit not being really familiar with the project's code, I tried
several things and it finally worked out. Furthermore this patch could
conflict with planned rewrittings/cleanings of awesome's api.
Thus, I'm here asking for opinions on this patch's usefulness and
implementation.
Thanks in advance,
olcc
From 10df6c994c1a4976a7a4de72e7edb4087d709d91 Mon Sep 17 00:00:00 2001
From: olcc laurent.of...@gmail.com
Date: Mon, 14 Sep 2009 18:34:20 +0200
Subject: [PATCH] multiple wibox handling : first try
---
lib/awful/wibox.lua.in | 27 +++
screen.c | 16
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/lib/awful/wibox.lua.in b/lib/awful/wibox.lua.in
index 1bae18b..185979a 100644
--- a/lib/awful/wibox.lua.in
+++ b/lib/awful/wibox.lua.in
@@ -48,18 +48,37 @@ end
function set_position(wibox, position, screen)
local screen = screen or wibox.screen or 1
local area = capi.screen[screen].geometry
+local pos = { x = area.x, y = area.y, height = area.height, width = area.width }
+
+for _, wprop in ipairs(wiboxes) do
+if wprop.wibox ~= wibox then
+if wprop.postion == right then
+pos.width = pos.width - wprop.wibox.width - 2 * wprop.wibox.border_width
+elseif wprop.position == left then
+pos.x = pos.x + wprop.wibox.width + 2 * wprop.wibox.border_width
+pos.width = pos.width - wprop.wibox.width - 2 * wprop.wibox.border_width
+elseif wprop.position == bottom then
+pos.height = pos.height - wprop.wibox.height - 2 * wprop.wibox.border_width
+elseif wprop.position == top then
+pos.y = pos.y + wprop.wibox.height + 2 * wprop.wibox.border_width
+pos.height = pos.height - wprop.wibox.height - 2 * wprop.wibox.border_width
+end
+else
+break
+end
+end
-- The length of a wibox is always chosen to be the optimal size
-- (non-floating).
-- The width of a wibox is kept if it exists.
if position == right then
-wibox.x = area.x + area.width - (wibox.width + 2 * wibox.border_width)
+wibox.x = pos.x + pos.width - (wibox.width + 2 * wibox.border_width)
elseif position == left then
-wibox.x = area.x
+wibox.x = pos.x
elseif position == bottom then
-wibox.y = (area.y + area.height) - (wibox.height + 2 * wibox.border_width)
+wibox.y = (pos.y + pos.height) - (wibox.height + 2 * wibox.border_width)
elseif position == top then
-wibox.y = area.y
+wibox.y = pos.y
end
for _, wprop in ipairs(wiboxes) do
diff --git a/screen.c b/screen.c
index 96a1a7a..8884483 100644
--- a/screen.c
+++ b/screen.c
@@ -179,30 +179,30 @@ screen_area_get(screen_t *screen, bool strut)
if((o)-strut.top_start_x || (o)-strut.top_end_x || (o)-strut.top) \
{ \
if((o)-strut.top) \
-top = MAX(top, (o)-strut.top); \
+top = top + (o)-strut.top; \
else \
-top = MAX(top, ((o)-geometry.y - area.y) + (o)-geometry.height); \
+top = top + ((o)-geometry.y - area.y) + (o)-geometry.height; \
} \
if((o)-strut.bottom_start_x || (o)-strut.bottom_end_x || (o)-strut.bottom) \
{ \
if((o)-strut.bottom) \
-bottom = MAX(bottom, (o)-strut.bottom); \
+bottom = bottom + (o)-strut.bottom; \
else \
-bottom = MAX(bottom, (area.y + area.height) - (o)-geometry.y); \
+bottom = bottom + (area.y + area.height) - (o)-geometry.y; \
} \
if((o)-strut.left_start_y || (o)-strut.left_end_y || (o)-strut.left) \
{ \
if((o)-strut.left) \
-left = MAX(left, (o)-strut.left); \
+left = left + (o)-strut.left; \
else \
-left = MAX(left, ((o)-geometry.x - area.x) + (o)-geometry.width); \
+left = left + ((o)-geometry.x - area.x) + (o)-geometry.width; \
} \
if((o)-strut.right_start_y || (o)-strut.right_end_y || (o)-strut.right) \
{ \
if((o)-strut.right) \
-right = MAX(right, (o)-strut.right); \
+right = right + (o)-strut.right; \
else \
-right = MAX(right, (area.x + area.width) - (o)-geometry.x); \
+right = right + (area.x + area.width) - (o)-geometry.x; \
} \
}
--
1.6.4.3
Re: [PATCH] rules: placement and geometry
For rules I created two table: data.set and data.postset. They
contains setters and post setters. Postset is processed after set. I
hope it solve problem with focus and dimenssion not applied in the
good order.
I renamed switchtotag in the same patch as it's a pretty new stuff and
the old beahaviour was harder to get working (now it doesnt not need
to access the table of all rules). Selecttag is a simple function not
depending on the rules table: tag is specified as value.
What do you think about that?
I hope this look cleaner
On Mon, Sep 14, 2009 at 4:18 PM, Julien Danjou jul...@danjou.info wrote:
At 1252937539 time_t, Cedric GESTES wrote:
placement.get_percentage(value, min, max) ?
And probably a set_geometry_percentage also? :)
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Don't give up.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkquUM4ACgkQpGK1HsL+5c1rfwCeJpQR1FvDg+HXpU3wovBmXOPy
AkkAn1McF8ZLCyTK3z6v5AM1nn9FxtnS
=zLv8
-END PGP SIGNATURE-
From bf63622d4a3b8e036afa94789ae749f6defbe77c Mon Sep 17 00:00:00 2001
From: Cedric GESTES cta...@gmail.com
Date: Tue, 15 Sep 2009 20:39:59 +0200
Subject: [PATCH 1/3] placement: add set_geometry_percentage
Signed-off-by: Cedric GESTES cta...@gmail.com
---
lib/awful/placement.lua.in | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/lib/awful/placement.lua.in b/lib/awful/placement.lua.in
index 8fa5a05..76d3945 100644
--- a/lib/awful/placement.lua.in
+++ b/lib/awful/placement.lua.in
@@ -9,6 +9,7 @@ local ipairs = ipairs
local pairs = pairs
local math = math
local table = table
+local type = type
local capi =
{
screen = screen,
@@ -225,4 +226,34 @@ function center_vertical(c, p)
end
+--- Get value from percentage, or just return value
+...@param value The value, could be a percentage or an absolute value
+...@param min The minimum (used for percentage)
+...@param max The maximum (used for percentage)
+...@return An integer value between min and max
+function geometry_percentage(value, min, max)
+if type(value) == string then
+val,percent = value:match((%d*) *(%%*))
+if val and percent == % then
+return ((max - min) * val / 100) + min
+end
+end
+return value
+end
+
+
+--- Set a gemetry property on a client (apply a percentage based on the screen size)
+-- @param c The client
+-- @param property The property name
+-- @param value The value to set
+-- @param screenprop Optional screen property to calculate the percent with
+-- @return true is the property match
+function set_geometry_percentage(c, property, value, screenprop)
+local geo = c:geometry();
+local screenp = screenprop or property
+geo[property] = geometry_percentage(value, 0, capi.screen[c.screen].workarea[screenp])
+c:geometry(geo)
+end
+
+
-- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
--
1.6.4.2
From bd8bae680c13a0e18451f1cca2021564ab517b8c Mon Sep 17 00:00:00 2001
From: Cedric GESTES cta...@gmail.com
Date: Tue, 15 Sep 2009 20:43:04 +0200
Subject: [PATCH 2/3] rules: rework
Signed-off-by: Cedric GESTES cta...@gmail.com
---
lib/awful/rules.lua.in | 83 +--
1 files changed, 58 insertions(+), 25 deletions(-)
diff --git a/lib/awful/rules.lua.in b/lib/awful/rules.lua.in
index 8b6151f..db77e0c 100644
--- a/lib/awful/rules.lua.in
+++ b/lib/awful/rules.lua.in
@@ -1,5 +1,6 @@
---
-- @author Julien Danjou lt;jul...@danjou.infogt;
+-- @author Cedric Gestes lt;cta...@gmail.comgt;
-- @copyright 2009 Julien Danjou
-- @release @AWESOME_VERSION@
---
@@ -11,6 +12,10 @@ local ipairs = ipairs
local pairs = pairs
local aclient = require(awful.client)
local atag = require(awful.tag)
+local aplacement = require(awful.placement)
+local capi = {
+screen = screen
+}
--- Apply rules to clients at startup.
module(awful.rules)
@@ -44,7 +49,14 @@ module(awful.rules)
-- br/
-- code
-- { rule = { class = Emacs }
--- properties = { tag = mytagobject, switchtotag = true } }
+-- properties = { selecttag = mytagobject } }
+-- /code
+-- /p
+-- pIf you want to put Emacs floating, centered with a width of 60% and a height of 200px:
+-- br/
+-- code
+-- { rule = { class = Emacs }
+-- properties = { width = 60%, floating = true, height = 200 , placement = centered } }
-- /code
-- /p
-- pNote that all rule entries need to match. If any of the entry does not
@@ -57,6 +69,26 @@ module(awful.rules)
-- @name rules
rules = {}
+
+data= {}
+--- Table of setter functions
+data.set= {}
+--- Table of post setter functions
+data.postset= {}
+
+data.set.floating = function(c, p, v)
