Man won't uby gas for at least 31 days
emulsionize.jpg
Re: Problem with 3.3-rc3 and functions using ... and arg
At 1243188456 time_t, Tassilo Horn wrote: Ah, now I've looked that up in the lua spec. In 5.0 `arg' is used to access varargs, but in 5.1 `...' is used instead. Because awesome uses so many bleeding edge libs anyway, I'd say that one could switch to using lua 5.1 syntax... Thanks, that should be fixed, for sure. -- 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: next branch keybinding weirdness
At 1243147563 time_t, koniu wrote:
My best conclusion so far is that when re-setting root.keys with
different length tables (note that I still run root.keys({ ... }) even
when switching A1-A2 and it works fine) something goes wrong and the
keybinding/function is done twice.
The thing is that when you call root.keys(), awesome lies down the table
passed as argument, and fill an array of key object (globalconf.keys).
So when awesome receive an key event, it look through from 0 to
globalconf.keys.len and check each element of the array. When a
key matches, it run its callback function.
So if one of this function modifies the array, while the loop was
checking for example key object 5 on 200, it will still go through key
number 6 which can be ... the same as 5 if you pushed an elememnt in
from of your table in the previously called callback function from
object number 5.
In fact it can be anything else, and you can do very bad things modifying
key bindings while a key binding is pressed, like infinite loop.
(This can be a false problem, since awesome is able to finish such a loop in
matter of miliseconds of course *g*)
Seriously, this has been discussed previously, and no solution has been
found.
I just though about something that IIRC had not been proposed.
What we can try is to go through the loop and look for matching key from
globalconf.key. Then, rather then calling callback function each time we
match (since that can break things (TM)) we store key object temporarly.
_Then_, we call all matched key's callback function. If one of them
modify the root.keys(), we just do not care, we already finished
looping.
What do you people think?
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: [PATCH] 0001-hooks-add-exit-hook
At 1243184445 time_t, Gregor Best wrote: You wouldn't need such a hook. Just append all stuff which needs to be started to the end of your rc.lua Except that it's not very easy to use when you just want to add that code in a module. You can't access rc.lua and telling user to add code ia PITA. 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: Problem with 3.3-rc3 and functions using ... and arg
At 1243245445 time_t, Tassilo Horn wrote: In the meantime I've discovered that lua 5.1.4 allows to use those deprecated features by default, but my distro (Gentoo) disables them if the deprecated USE flag is not set. This explains why nobody except me complained till now. So for now I recompiled lua with the 5.0 vararg style enabled and awesome 3.3-rc3 is running fine. Fine, anyway it's fixed in git now AFAICT. 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: [PATCH] 0001-hooks-add-exit-hook
At 1243177021 time_t, koniu wrote: and the patch :P Pushed. -- 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: [Patches] Fix some minor compiler warnings found in rc3
At 1243166412 time_t, Uli Schlachter wrote: gogonkt reported some compiler warnings in #awesome with gentoo's gcc 4.2.4 (And he also had an error trying to build the docs, but no idea about that one. Merged. Cheers, -- 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
Los Angeles open-air reservoir covered with plastic balls to protect wataer
bench.jpg
Re: next branch keybinding weirdness
At Mon, 25 May 2009 11:42:37 +0200
Julien Danjou wrote:
At 1243147563 time_t, koniu wrote:
My best conclusion so far is that when re-setting root.keys with
different length tables (note that I still run root.keys({ ... }) even
when switching A1-A2 and it works fine) something goes wrong and the
keybinding/function is done twice.
The thing is that when you call root.keys(), awesome lies down the table
passed as argument, and fill an array of key object (globalconf.keys).
So when awesome receive an key event, it look through from 0 to
globalconf.keys.len and check each element of the array. When a
key matches, it run its callback function.
So if one of this function modifies the array, while the loop was
checking for example key object 5 on 200, it will still go through key
number 6 which can be ... the same as 5 if you pushed an elememnt in
from of your table in the previously called callback function from
object number 5.
In fact it can be anything else, and you can do very bad things modifying
key bindings while a key binding is pressed, like infinite loop.
(This can be a false problem, since awesome is able to finish such a loop in
matter of miliseconds of course *g*)
Seriously, this has been discussed previously, and no solution has been
found.
I just though about something that IIRC had not been proposed.
What we can try is to go through the loop and look for matching key from
globalconf.key. Then, rather then calling callback function each time we
match (since that can break things (TM)) we store key object temporarly.
_Then_, we call all matched key's callback function. If one of them
modify the root.keys(), we just do not care, we already finished
looping.
What do you people think?
Cheers,
Sounds like a good idea
--
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: [PATCH] 0001-hooks-add-exit-hook
At Mon, 25 May 2009 11:44:25 +0200 Julien Danjou wrote: At 1243184445 time_t, Gregor Best wrote: You wouldn't need such a hook. Just append all stuff which needs to be started to the end of your rc.lua Except that it's not very easy to use when you just want to add that code in a module. You can't access rc.lua and telling user to add code ia PITA. Cheers, Agreed, I didn't think of 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 signature.asc Description: PGP signature
Re: Problem with 3.3-rc3 and functions using ... and arg
Julien Danjou jul...@danjou.info writes: Hi Julien, Ah, now I've looked that up in the lua spec. In 5.0 `arg' is used to access varargs, but in 5.1 `...' is used instead. Because awesome uses so many bleeding edge libs anyway, I'd say that one could switch to using lua 5.1 syntax... Thanks, that should be fixed, for sure. In the meantime I've discovered that lua 5.1.4 allows to use those deprecated features by default, but my distro (Gentoo) disables them if the deprecated USE flag is not set. This explains why nobody except me complained till now. So for now I recompiled lua with the 5.0 vararg style enabled and awesome 3.3-rc3 is running fine. Bye, Tassilo -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Patch] simplewindow / wibox stuff (nothing major ;)
At 1243258659 time_t, Uli Schlachter wrote: this is v2 of Re: [Patch] Allow setting wibox.opacity if wibox.screen is nil which I sent some time ago (or rather: this is completly unrelated to that other patch, but also fixes that bug). There is also some other stuff in there, but everything is wibox/simplewindow related. I've merged it, but edit to inline opacity helpers function. (and added to my TODO to merge wibox and swindows :) 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: c.hide broken in next
At 1243264813 time_t, koniu wrote: jd_, u mess with all those properties :) Did I? :) I've amended the commit responsible of that. 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: next branch keybinding weirdness
At 1243268501 time_t, koniu wrote: This can be tested/reproduced by adding this to default rc's awful.hooks.tags function: if view == select root.keys(globalkeys) end This is not a major issue but makes me think that there could be some improvement to be made in the way properties/hooks/events are handled there. I can't reproduce such a behaviour even adding this to default config. Maybe some profiling may help? -- 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
focus problem in next
Hello, here's me complaining about next again :P The issue, in general terms, seems to be sloppy focus somehow taking precedence over manage focus. Here's the steps: 1. go to an empty tag (tile layout) 2. open a terminal 3. type something (eg. 111) in, so you know which client is which 4. open another one and type in 222 5. move the mouse cursor over the top part of 111 client 6. open another terminal (without moving the mouse) 7. focus ends up on 222 client instead of the last terminal opened Reproducible with default rc.lua. k -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: c.hide broken in next
On Mon, May 25, 2009 at 16:28, Julien Danjou jul...@danjou.info wrote: At 1243264813 time_t, koniu wrote: jd_, u mess with all those properties :) Did I? :) I've amended the commit responsible of that. Fixed, thanks. Can you do the same magic for c.minimized (same issue)? cheers kk -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: c.hide broken in next
At 1243272624 time_t, koniu wrote: Fixed, thanks. Can you do the same magic for c.minimized (same issue)? Should be ok. 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
[Patch] warning in setlocale()
Shows a warning if the locale cannot be set. I attach the patch. NOTE: In Xlib you have a function called XSupportsLocale(), I didn't find anything similar in xcb.
Re: c.hide broken in next
On Mon, May 25, 2009 at 20:39, Julien Danjou jul...@danjou.info wrote: At 1243272624 time_t, koniu wrote: Fixed, thanks. Can you do the same magic for c.minimized (same issue)? Should be ok. Confirmed. Btw, build of current next (6c1d20) went kuku, see patch. From 36fab45e55efad297f0c6ec56c7fd9fa3b5d0c53 Mon Sep 17 00:00:00 2001 From: koniu gkusni...@gmail.com Date: Mon, 25 May 2009 21:47:33 +0100 Subject: [PATCH] fix typo Signed-off-by: koniu gkusni...@gmail.com --- tag.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/tag.c b/tag.c index e3e6123..1d206f4 100644 --- a/tag.c +++ b/tag.c @@ -69,7 +69,6 @@ tag_view(tag_t *tag, bool view) lua_pushliteral(globalconf.L, select); else lua_pushliteral(globalconf.L, unselect); -luaA_dofunction(globalconf.L, globalconf.hooks.tags, 3, 0); luaA_dofunction_from_registry(globalconf.L, globalconf.hooks.tags, 3, 0); } } -- 1.6.3.1
tag history broken in next
With the new select/unselect events the history is always empty? I've attempted to hack a better tag history implementation which would be multi-level and allowed a variable number of tags. The problem I keep facing is that eg. each tag switch with viewonly() triggers a bunch of unselect's by running viewnone() which results in useless history entries with all tags unselected. Any hints welcome :) k -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
