[PATCH] Error out when creating a simplewindow with invalid geometries

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There is an integer overflow in the simplewindow code. If you try to create a
window with e.g. height = 50 and border_width = 30, this would create a X
window with real_height = height - 2 * border_width = (uint_16_t) -10.
This caused a BadAlloc error reply which is hard to trace down.

With this patch applied, simplewindow_init() now lowers the border_width of the
new window to avoid this integer overflow and additionally prints a error on
stderr. This is still not good, but at least it's better than a BadAlloc error.

This was found via the following lua fragment:
 naughty.config.border_width = 50
 naughty.notify({ text = test })

Signed-off-by: Uli Schlachter psyc...@znc.in
- ---
 swindow.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/swindow.c b/swindow.c
index 487ad8e..423d174 100644
- --- a/swindow.c
+++ b/swindow.c
@@ -83,6 +83,20 @@ simplewindow_init(simple_window_t *sw,
 const uint32_t gc_mask = XCB_GC_FOREGROUND | XCB_GC_BACKGROUND;
 const uint32_t gc_values[2] = { s-black_pixel, s-white_pixel };

+if (MIN(geometry.width, geometry.height) = 2 * border_width)
+{
+/* The border_width is so big that there would be no space left in the
+ * window. This now adjusts border_width so that there is at least 1px
+ * space inside the window, except when we were already called with a
+ * width/height of 0, in which case this will likely lead to a X
+ * protocol error.
+ */
+border_width = MIN(geometry.width, geometry.height) / 2;
+if (border_width  0)
+border_width--;
+fprintf(stderr, error: Attempted to create a window with too large
border_width / too small size\n);
+}
+
 sw-geometry.x = geometry.x;
 sw-geometry.y = geometry.y;
 sw-geometry.width = geometry.width;
- --
1.6.2

- --
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)

iEYEARECAAYFAkm/yEgACgkQABixOSrV998jAQCg1Un3JbyQPOLTiEazEJIltN4d
IjUAnAknOWz+/eaibHaCObWTqGgNfrof
=uiIu
-END PGP SIGNATURE-

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

[PATCH] awesome-client: Don't go into an endless loop if awesome dies

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This patch makes awesome-client give up after 10 tries when it lost the
connection to awesome. Also it now waits for some time between reconnect
attempts.
I like the behaviour of this, but some of the code seems a little icky...

Signed-off-by: Uli Schlachter psyc...@znc.in
- ---
 awesome-client.c |   46 +++---
 1 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/awesome-client.c b/awesome-client.c
index c55f0d7..c7c84fa 100644
- --- a/awesome-client.c
+++ b/awesome-client.c
@@ -84,34 +84,54 @@ sockets_reconnect(void)
 sockets_init();
 }

- -/** Send a message to awesome.
+/** Send a message to awesome without handling retries.
  * \param msg The message.
  * \param msg_len The message length.
- - * \return The errno of sendto().
+ * \return The errno of send().
  */
 static int
- -send_msg(const char *msg, ssize_t msg_len)
+send_msg_raw(const char *msg, ssize_t msg_len)
 {
 #ifndef __FreeBSD__
- -if(send(csfd, msg, msg_len, MSG_NOSIGNAL | MSG_EOR) == -1)
+return send(csfd, msg, msg_len, MSG_NOSIGNAL | MSG_EOR);
 #else
- -if(send(csfd, msg, msg_len, MSG_NOSIGNAL | MSG_EOF) == -1)
+return send(csfd, msg, msg_len, MSG_NOSIGNAL | MSG_EOF);
 #endif
+}
+
+/** Send a message to awesome.
+ * \param msg The message.
+ * \param msg_len The message length.
+ * \return The errno of send().
+ */
+static int
+send_msg(const char *msg, ssize_t msg_len)
+{
+int try = 10;
+
+while (try  send_msg_raw(msg, msg_len) == -1)
 {
 switch (errno)
 {
- -  case ENOENT:
- -warn(can't write to %s, addr-sun_path);
- -break;
   case EPIPE:
   case ENOTCONN:
   case ECONNRESET:
 sockets_reconnect();
- -return send_msg(msg, msg_len);
+try--;
+break;
+  case ENOENT:
+warn(can't write to %s, addr-sun_path);
+return errno;
   default:
 warn(error sending packet: %s, strerror(errno));
+return errno;
 }
- -return errno;
+usleep(10);
+}
+if(!try)
+{
+warn(giving up.);
+return EXIT_FAILURE;
 }

 return EXIT_SUCCESS;
@@ -201,12 +221,16 @@ main(int argc, char **argv)
 while((msg = readline(prompt)))
 if((msg_len = a_strlen(msg)))
 {
+int result;
 add_history (msg);
 p_realloc(msg, msg_len + 2);
 msg[msg_len] = '\n';
 msg[msg_len + 1] = '\0';
- -if(send_msg(msg, msg_len + 2) == EXIT_SUCCESS)
+result = send_msg(msg, msg_len + 2);
+if(result == EXIT_SUCCESS)
 recv_msg();
+else if(result == EXIT_FAILURE)
+break;
 p_delete(msg);
 }
 }
- --
1.6.2

- --
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)

iEYEARECAAYFAkm/z5QACgkQABixOSrV9982WQCcD1Ius5QtFWNx5Afo1DD7dS3/
IQwAoN0ME0yU8BbFlA5uDj59jG65grvu
=ubkJ
-END PGP SIGNATURE-

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

Re: openafs+awesome bug

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alex Cornejo wrote:
 Hi ppl,
 
 A lot of universities (and corporations) use kerberos for authentication
 and OpenAFS to host the folders. However, it is not possible to create
 sockets on OpenAFS (this is probably true for other remote/distributed
 file systems).
 
 Currently awesome reports its unable to bind a socket (with permission
 denied) and continues normaly. However this means the user is unable to
 control awesome using awesome-client or similar.
 
 A simple workaround for this is to fall back to /tmp/.awesome-ctl before
 giving up after ~/.awesome-ctl failed. The following patch does precisly
 this, it works perfectly on my desktop (on openafs) and my laptop
 (regular ext3).
 
 PS: As a bonus I attached a path to merge two loops in the keybinding
 section of aweseomerc.lua into 1, I see no reason to spam the list again
 for such a small patch.
 
 Cheers,
 
 Alex
 

Hi,

one small comment on that patch:
IMHO you should not hardcode /tmp but use $TMPDIR instead or at least try
$TMPDIR before /tmp (if they are different).
There is e.g. a pam module on linux (perhabs on other OS too) which does some
namespace magic and sets $TMPDIR to a directory which is only mounted for the
current user.

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)

iEYEARECAAYFAknBFBUACgkQABixOSrV9993YQCgiKOdyAa6UzpCAispu0bup1uW
ME0AnRwU1lzVxaJ0oUu4F3e2m1Af1nWD
=OKsR
-END PGP SIGNATURE-

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

Leaking FDs to childs started by awful.util.spawn() and close-on-exec

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

recently I noticed that all my processes had a pipe as FD 3 and 4 which seemed
to come from awesome. Some investigation revealed that they come from my
.xsession (I don't know why yet), but I also found cases where awesome leaked
FDs to child processes (sockets to awesome-clients, to be exact).

I wrote a couple of patches to address this. strace showed that this patch
causes the close-on-exec flag to be set multiple times on some sockets, but I
think it's better to be safe. If it's libev which sometimes sets the flag (which
I suspect), then I don't know why the sockets to awesome-clients don't get this
flag.

For testing that this is real, I started an xterm through awesome-client.
ls -l /proc/self/fd told me that fd 10 was the only socket it had and
echo test 10 displayed test in awesome-client when I ran the next command.

Cheers,
Uli

P.S.: I'm sending the patches by hand, no idea how fast I'll be.
- --
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)

iEYEARECAAYFAknUmjMACgkQABixOSrV99/HMgCfW1NdzEJsqq6pR4FJ4ql6qh4U
5AgAoJfm1oyPx/PX6aYXPZOmqG999gKi
=NgZN
-END PGP SIGNATURE-

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

[PATCH 2/4] Make the sockets which listens for new awesome-clients close-on-exec

[Uli Schlachter]

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 common/socket.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/common/socket.c b/common/socket.c
index a8d148f..7d6e461 100644
--- a/common/socket.c
+++ b/common/socket.c
@@ -122,6 +122,8 @@ socket_getclient(void)
 if(csfd  0)
 warn(error opening UNIX domain socket: %s, strerror(errno));

+socket_close_on_exec(csfd);
+
 return csfd;
 }

-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

[PATCH 3/4] Mark the connection to the X server as close-on-exec

[Uli Schlachter]

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 awesome.c |4 
 luaa.c|2 --
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/awesome.c b/awesome.c
index 26bd86c..507fcbe 100644
--- a/awesome.c
+++ b/awesome.c
@@ -44,6 +44,7 @@
 #include common/version.h
 #include common/atoms.h
 #include common/xcursor.h
+#include common/socket.h
 #include config.h

 awesome_t globalconf;
@@ -442,6 +443,9 @@ main(int argc, char **argv)
 ev_check_start(globalconf.loop, xcheck);
 ev_unref(globalconf.loop);

+/* Mark the file descriptor for the X connection as close-on-exec */
+socket_close_on_exec(xfd);
+
 /* Allocate a handler which will holds all errors and events */
 xcb_event_handlers_init(globalconf.connection, globalconf.evenths);
 xutil_error_handler_catch_all_set(globalconf.evenths, xerrorstart, NULL);
diff --git a/luaa.c b/luaa.c
index afe249e..f624841 100644
--- a/luaa.c
+++ b/luaa.c
@@ -623,8 +623,6 @@ luaA_spawn(lua_State *L)
 {
 if(fork() == 0)
 {
-if(globalconf.connection)
-xcb_disconnect(globalconf.connection);
 setsid();
 a_exec(cmd);
 warn(execl '%s' failed: %s\n, cmd, strerror(errno));
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

[PATCH 4/4] Mark new sockets to awesome-clients as close-on-exec

[Uli Schlachter]

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 luaa.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/luaa.c b/luaa.c
index f624841..74a32fd 100644
--- a/luaa.c
+++ b/luaa.c
@@ -1100,6 +1100,11 @@ luaA_conn_cb(EV_P_ ev_io *w, int revents)
 ev_io *csio_conn = p_new(ev_io, 1);
 int csfd = accept(w-fd, NULL, NULL);

+if (csfd  0)
+return;
+
+socket_close_on_exec(csfd);
+
 ev_io_init(csio_conn, luaA_cb, csfd, EV_READ);
 ev_io_start(EV_DEFAULT_UC_ csio_conn);
 ev_unref(EV_DEFAULT_UC);
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

[PATCH 1/4] Add socket_close_on_exec() for marking sockets as close-on-exec

[Uli Schlachter]

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 common/socket.c |   13 +
 common/socket.h |1 +
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/common/socket.c b/common/socket.c
index 80e1438..a8d148f 100644
--- a/common/socket.c
+++ b/common/socket.c
@@ -25,6 +25,7 @@
 #include sys/socket.h
 #include sys/un.h
 #include unistd.h
+#include fcntl.h

 #include xcb/xcb.h

@@ -123,4 +124,16 @@ socket_getclient(void)

 return csfd;
 }
+
+/** Mark a socket as close-on-exec
+ */
+void socket_close_on_exec(int fd)
+{
+int flags = fcntl(fd, F_GETFD, 0);
+if (flags  0)
+// Ignore errors, nothing we can do about them
+return;
+fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+}
+
 // vim:
filetype=c:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/common/socket.h b/common/socket.h
index d46ed28..33a6c69 100644
--- a/common/socket.h
+++ b/common/socket.h
@@ -30,6 +30,7 @@ typedef enum

 struct sockaddr_un *socket_open(const int, const socket_mode_t);
 int socket_getclient(void);
+void socket_close_on_exec(int);

 #endif
 // vim:
filetype=c:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

Re: [PATCH 3/4] Mark the connection to the X server as close-on-exec

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 At 1238670195 time_t, Uli Schlachter wrote:
 
 Useless, libxcb already does it.
 
 Cheers,

Then... why does awesome still close that socket by hand?

- --
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)

iEYEARECAAYFAknUrwwACgkQABixOSrV998b2wCeP5I71kq4t/1ga/f+c/SE+cZx
mogAnjoSTDkIX7IXhHMAotcosZ2alyd9
=xafe
-END PGP SIGNATURE-

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

[PATCH] luaA_isloop() should only check for tables appearing multiple times

[Uli Schlachter]

For example, without this patch, the following table would be said
to be looping:
  { a = asd, b = asd }

I think this could also be triggered if a widget appeared twice
in a wibox.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 luaa.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/luaa.c b/luaa.c
index df26432..e3a834f 100644
--- a/luaa.c
+++ b/luaa.c
@@ -575,7 +575,7 @@ luaA_isloop_check(lua_State *L, void_array_t *elems)
 lua_pushnil(L);
 while(luaA_next(L, -2))
 {
-if(!luaA_isloop_check(L, elems))
+if(lua_istable(L, -1)  !luaA_isloop_check(L, elems))
 {
 /* remove key and value */
 lua_pop(L, 2);
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

Re: [PATCH] luaA_isloop() should only check for tables appearing multiple times

[Uli Schlachter]

Julien Danjou wrote:
 At 1238751148 time_t, Uli Schlachter wrote:
 For example, without this patch, the following table would be said
 to be looping:
   { a = asd, b = asd }

 I think this could also be triggered if a widget appeared twice
 in a wibox.
 
 Hum, yeah. Fixed it in an other way. Can you check?

Seems fine, my widget-layouts branch still works and looping tables are reported
correctly.

Cheers,
Uli

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

Re: [PATCH] why hardcode the 'default' tag

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

koniu wrote:
 Hi,
 
 I was wondering if there's a strong reason for having the hardcoded
 bit forcing default tag to be created if there are no tags in the
 screen. I think that this should be left to lua side - with the
 current default rc.lua never even touching the problem (static tags)
 and users/libraries (like shifty) possibly knowing what they're doing.
 
 I've been using the attached patch for the whole of today and haven't
 hit any issues.
 
 thanks
 koniu
 

Hi,

if you restart awesome and the rc.lua doesnt create any tags at all, what
happens? When I was using shifty I used to lose a couple of windows across
awesome restart. They just disappeared, but the app was still running.

Would this patch cause something like this to happen more easily? Is this issue
completely unrelated and I should report it instead of blaming myself for the
lost windows?
So many questions...

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)

iEYEARECAAYFAkndlHgACgkQABixOSrV99+U5wCfXMXYoNYD47Kxjg6IiR3tDmye
Wf4An0oFbaoM/VAtDug8QlYM74g9feKV
=MrpH
-END PGP SIGNATURE-

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

Re: [PATCH] why hardcode the 'default' tag

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

koniu wrote:
 Hi,
 
 if you restart awesome and the rc.lua doesnt create any tags at all, what
 happens? When I was using shifty I used to lose a couple of windows across
 awesome restart. They just disappeared, but the app was still running.
 
 If rc.lua doesn't create tags when awesome is restarted, by default,
 there will be no tags. Shifty deals with this situation by attaching
 its match() function to the 'manage' hook which is executed for each
 client (window) that is opened. match() function should place the
 client in a relevant tag which either exist (then the client is merely
 moved to the tag) or not (in which case shifty will create the tag and
 then move the client there).
 
 Would this patch cause something like this to happen more easily? Is this 
 issue
 completely unrelated and I should report it instead of blaming myself for the
 lost windows?
 
 Having said that, shifty is still fairly experimental and some
 glitches may occur. With the current version I haven't had any windows
 vanishing but if it does happen then there' a bug which should be
 fixed. If you're experiencing such behavior you should post a report
 with detailed information as to what gets lost in what circumstances,
 with what configuration values (and hopefully a reproducible test
 case). This way we can try to hunt the issue down.
 
 thanks,
 koniu
 

Reported as bug #494.
Oh and I just remembered this also happens when less tags are created, not only
when no tags are created...
Anyway, I don't think this is a shifty bug.

psychon

- --
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)

iEYEARECAAYFAkneAKIACgkQABixOSrV998GOACgpHGQk7qFmHJI/XnF+gxH8Mqt
OnEAn24uTwgyJth+xwTMElDctCzyNTy1
=qKdu
-END PGP SIGNATURE-

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

[PATCH] Rename LAYER_OUTOFSPACE to LAYER_MAX

[Uli Schlachter]

The name LAYER_OUTOFSPACE suggests that this is a real layer on which windows
can be put, but it's only used as an integer which describes the maximum
allowed / used layer.
Therefor, renaming it to LAYER_MAX and adding a comment which describes this
might make sense.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 client.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/client.c b/client.c
index 0144c91..86ce39e 100644
--- a/client.c
+++ b/client.c
@@ -305,7 +305,8 @@ typedef enum
 LAYER_ABOVE,
 LAYER_FULLSCREEN,
 LAYER_ONTOP,
-LAYER_OUTOFSPACE
+/** This one only used for counting and is not a real layer */
+LAYER_MAX
 } layer_t;

 /** Get the real layer of a client according to its attribute (fullscreen, …)
@@ -379,7 +380,7 @@ client_stack()
 }

 /* then stack clients */
-for(layer = LAYER_BELOW; layer  LAYER_OUTOFSPACE; layer++)
+for(layer = LAYER_BELOW; layer  LAYER_MAX; layer++)
 for(node = last; node; node = node-prev)
 if(client_layer_translator(node-client) == layer)
 config_win_vals[0] = client_stack_above(node-client,
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

[PATCH] wibox: Don't display garbage when a wibox is made visible

[Uli Schlachter]

I did the following and the wibox displayed garbage:

local w = wibox({ position = floating, bg = #ff })
w.visible = false
w.screen = 1
do some other stuff
w.visible = true

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 wibox.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/wibox.c b/wibox.c
index 5acd03a..1de7e78 100644
--- a/wibox.c
+++ b/wibox.c
@@ -561,6 +561,8 @@ wibox_setvisible(wibox_t *wibox, bool v)
 {
 if(wibox-isvisible)
 {
+/* draw it right now once to avoid garbage shown */
+wibox_draw(wibox);
 xcb_map_window(globalconf.connection, wibox-sw.window);
 simplewindow_refresh_pixmap(wibox-sw);
 /* stack correctly the wibox */
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

[PATCH] client_stack(): Only stack windows once per mainloop

[Uli Schlachter]

I was creating 2000 wiboxes in a loop (don't ask) and creating them took
forever. According to callgrind, there were about 2 million calls to
xcb_configure_window() and most (if not all) of them were from client_stack().
Awesome spent 70% of its cpu time in these client_stack() calls.

client_stack() is O(N^2) on the number of clients (it walks the list of clients
itself twice and each call to client_stack_above() walks the list too) and O(N)
on the number of wiboxes (it walks the wibox list twice). So obviously calls to
it should be rare.

This patch makes client_stack() only set a flag which is later checked. This
should reduce the number of restacks to the bare minimum. With this patch,
neither xcb_configure_window() nor anything else client_stack() related shows
up as having a lot of calls or using much cpu time.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 client.c |   21 ++---
 client.h |1 +
 event.h  |2 ++
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/client.c b/client.c
index 86ce39e..6633fa6 100644
--- a/client.c
+++ b/client.c
@@ -35,6 +35,7 @@
 #include common/atoms.h

 extern awesome_t globalconf;
+static int client_need_stack = 0;

 DO_LUA_NEW(extern, client_t, client, client, client_ref)
 DO_LUA_EQ(client_t, client, client)
@@ -342,12 +343,18 @@ client_layer_translator(client_t *c)
 return LAYER_NORMAL;
 }

+void
+client_stack()
+{
+client_need_stack = 1;
+}
+
 /** Restack clients.
  * \todo It might be worth stopping to restack everyone and only stack `c'
  * relatively to the first matching in the list.
  */
-void
-client_stack()
+static void
+client_real_stack(void)
 {
 uint32_t config_win_vals[2];
 client_node_t *node, *last = *client_node_list_last(globalconf.stack);
@@ -402,6 +408,15 @@ client_stack()
 }
 }

+void
+client_check_restack()
+{
+if (!client_need_stack)
+return;
+client_real_stack();
+client_need_stack = 0;
+}
+
 /** Manage a new client.
  * \param w The window.
  * \param wgeom Window geometry.
diff --git a/client.h b/client.h
index d2cd3e7..4c6bf44 100644
--- a/client.h
+++ b/client.h
@@ -79,6 +79,7 @@ void client_focus(client_t *);
 void client_focus_update(client_t *);
 void client_unfocus(client_t *);
 void client_unfocus_update(client_t *);
+void client_check_restack(void);

 int luaA_client_newindex(lua_State *);

diff --git a/event.h b/event.h
index 77cee2b..8f7279b 100644
--- a/event.h
+++ b/event.h
@@ -26,10 +26,12 @@

 #include wibox.h
 #include layout.h
+#include client.h

 static inline int
 awesome_refresh(xcb_connection_t *c)
 {
+client_check_restack();
 layout_refresh();
 wibox_refresh();
 return xcb_flush(c);
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

[PATCH] Rename LAYER_OUTOFSPACE to LAYER_COUNT

[Uli Schlachter]

The name LAYER_OUTOFSPACE suggests that this is a real layer on which windows
can be put, but it's only used as an integer which describes the maximum
allowed / used layer.
Therefor, renaming it to LAYER_COUNT and adding a comment which describes this
might make sense.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 client.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/client.c b/client.c
index 0144c91..16c5c61 100644
--- a/client.c
+++ b/client.c
@@ -305,7 +305,8 @@ typedef enum
 LAYER_ABOVE,
 LAYER_FULLSCREEN,
 LAYER_ONTOP,
-LAYER_OUTOFSPACE
+/** This one only used for counting and is not a real layer */
+LAYER_COUNT
 } layer_t;

 /** Get the real layer of a client according to its attribute (fullscreen, …)
@@ -379,7 +380,7 @@ client_stack()
 }

 /* then stack clients */
-for(layer = LAYER_BELOW; layer  LAYER_OUTOFSPACE; layer++)
+for(layer = LAYER_BELOW; layer  LAYER_COUNT; layer++)
 for(node = last; node; node = node-prev)
 if(client_layer_translator(node-client) == layer)
 config_win_vals[0] = client_stack_above(node-client,
-- 
1.6.2.1

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

[PATCH] Move the definition of globalconf into a header file

[Uli Schlachter]

Pretty much every single source file needs this struct, so it makes sense to
define it in a common header instead of in every single .c file.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 client.c  |2 --
 dbus.c|2 --
 draw.c|2 --
 event.c   |2 --
 ewmh.c|2 --
 hooks.c   |2 --
 image.c   |2 --
 key.c |2 --
 keygrabber.c  |2 --
 layout.c  |2 --
 luaa.c|2 --
 mouse.c   |2 --
 mousegrabber.c|2 --
 property.c|3 ---
 screen.c  |2 --
 selection.c   |2 --
 spawn.c   |2 --
 stack.c   |2 --
 structs.h |2 ++
 swindow.c |2 --
 systray.c |2 --
 tag.c |2 --
 titlebar.c|2 --
 wibox.c   |2 --
 widget.c  |2 --
 widgets/graph.c   |2 --
 widgets/imagebox.c|2 --
 widgets/progressbar.c |2 --
 widgets/systray.c |2 --
 widgets/textbox.c |2 --
 window.c  |2 --
 31 files changed, 2 insertions(+), 61 deletions(-)

diff --git a/client.c b/client.c
index 0144c91..4e762b6 100644
--- a/client.c
+++ b/client.c
@@ -34,8 +34,6 @@
 #include wibox.h
 #include common/atoms.h

-extern awesome_t globalconf;
-
 DO_LUA_NEW(extern, client_t, client, client, client_ref)
 DO_LUA_EQ(client_t, client, client)
 DO_LUA_GC(client_t, client, client, client_unref)
diff --git a/dbus.c b/dbus.c
index 9b77683..69d114b 100644
--- a/dbus.c
+++ b/dbus.c
@@ -32,8 +32,6 @@

 #include widget.h

-extern awesome_t globalconf;
-
 static DBusError err;
 static DBusConnection *dbus_connection = NULL;
 ev_io dbusio = { .fd = -1 };
diff --git a/draw.c b/draw.c
index c9107df..3534eae 100644
--- a/draw.c
+++ b/draw.c
@@ -33,8 +33,6 @@

 #include common/tokenize.h

-extern awesome_t globalconf;
-
 /** Convert text from any charset to UTF-8 using iconv.
  * \param iso The ISO string to convert.
  * \param len The string size.
diff --git a/event.c b/event.c
index d3bd4d1..e5ebb68 100644
--- a/event.c
+++ b/event.c
@@ -41,8 +41,6 @@
 #include screen.h
 #include common/atoms.h

-extern awesome_t globalconf;
-
 /** Handle mouse button events.
  * \param c The client on which the event happened or NULL.
  * \param type Event type, press or release.
diff --git a/ewmh.c b/ewmh.c
index 43d1d28..892a5e2 100644
--- a/ewmh.c
+++ b/ewmh.c
@@ -35,8 +35,6 @@
 #include common/atoms.h
 #include common/buffer.h

-extern awesome_t globalconf;
-
 #define _NET_WM_STATE_REMOVE 0
 #define _NET_WM_STATE_ADD 1
 #define _NET_WM_STATE_TOGGLE 2
diff --git a/hooks.c b/hooks.c
index c5d8190..a440945 100644
--- a/hooks.c
+++ b/hooks.c
@@ -21,8 +21,6 @@

 #include structs.h

-extern awesome_t globalconf;
-
 #define HANDLE_HOOK(L, h) \
 do { \
 if(lua_gettop(L) == 1) \
diff --git a/image.c b/image.c
index 39e09e5..7be5849 100644
--- a/image.c
+++ b/image.c
@@ -21,8 +21,6 @@

 #include structs.h

-extern awesome_t globalconf;
-
 DO_LUA_NEW(extern, image_t, image, image, image_ref)
 DO_LUA_GC(image_t, image, image, image_unref)
 DO_LUA_EQ(image_t, image, image)
diff --git a/key.c b/key.c
index 84accb4..8b4e78d 100644
--- a/key.c
+++ b/key.c
@@ -25,8 +25,6 @@

 #include structs.h

-extern awesome_t globalconf;
-
 static void
 key_delete(keyb_t **kbp)
 {
diff --git a/keygrabber.c b/keygrabber.c
index 13b5765..ee71f31 100644
--- a/keygrabber.c
+++ b/keygrabber.c
@@ -25,8 +25,6 @@
 #include keygrabber.h
 #include key.h

-extern awesome_t globalconf;
-
 /** XCB equivalent of XLookupString which translate the keycode given
  * by PressEvent to a KeySym and a string
  * \todo use XKB!
diff --git a/layout.c b/layout.c
index ef8541a..4ffa69d 100644
--- a/layout.c
+++ b/layout.c
@@ -25,8 +25,6 @@
 #include screen.h
 #include titlebar.h

-extern awesome_t globalconf;
-
 /** Arrange windows following current selected layout
  * \param screen the screen to arrange
  */
diff --git a/luaa.c b/luaa.c
index 583c6dd..d43ee26 100644
--- a/luaa.c
+++ b/luaa.c
@@ -46,8 +46,6 @@
 #include window.h
 #include common/xcursor.h

-extern awesome_t globalconf;
-
 extern const struct luaL_reg awesome_hooks_lib[];
 extern const struct luaL_reg awesome_dbus_lib[];
 extern const struct luaL_reg awesome_keygrabber_lib[];
diff --git a/mouse.c b/mouse.c
index d43b386..56a7fd1 100644
--- a/mouse.c
+++ b/mouse.c
@@ -27,8 +27,6 @@
 #include wibox.h
 #include common/xcursor.h

-extern awesome_t globalconf;
-
 DO_LUA_NEW(static, button_t, button, button, button_ref)
 DO_LUA_GC(button_t, button, button, button_unref)
 DO_LUA_EQ(button_t, button, button)
diff --git a/mousegrabber.c b/mousegrabber.c
index 2ebf871..2c3855e 100644
--- a/mousegrabber.c
+++ b/mousegrabber.c
@@ -25,8 +25,6 @@
 #include mousegrabber.h
 #include common/xcursor.h

-extern awesome_t globalconf

Re: [PATCH] wibox: Don't display garbage when a wibox is made visible

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 At 1239354821 time_t, Uli Schlachter wrote:
 local w = wibox({ position = floating, bg = #ff })
 w.visible = false
 w.screen = 1
 do some other stuff
 w.visible = true
 
 Good catch.
 
 ---
  wibox.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/wibox.c b/wibox.c
 index 5acd03a..1de7e78 100644
 --- a/wibox.c
 +++ b/wibox.c
 @@ -561,6 +561,8 @@ wibox_setvisible(wibox_t *wibox, bool v)
  {
  if(wibox-isvisible)
  {
 +/* draw it right now once to avoid garbage shown */
 +wibox_draw(wibox);
  xcb_map_window(globalconf.connection, wibox-sw.window);
  simplewindow_refresh_pixmap(wibox-sw);
  /* stack correctly the wibox */
 
 That's a solution, but I don't like it. But you spotted the bug
 correctly.
 
 I think we should make the wibox with need_update = true upon its
 creation so just after it will be drawn, and so will never have garbage.
 
 Can you try such a fix?
 

Hi,

attached is the new version of that patch. It adds a new function wibox_map()
which maps the wibox's window and makes sure it is correctly drawn. In my
testing this results in no garbage drawn at all.

This also removes the wibox_need_update() call for when a wibox is hidden,
because wibox_draw() skips those wiboxes anyway and doesn't clear their
need_update.

I don't know if the wibox_systray_refresh() call which wibox_draw() does for
these are important, but to me it looks like they don't do anything, so I
removed it.
If the wibox was hidden by setting .screen to nil, wibox_detach() already
cleaned up after the systray, else it's a new wibox which cant have anything
in its systray.

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)

iEYEARECAAYFAknfRf4ACgkQABixOSrV998EcwCeM6DkYd54JPnYJXlha/mOaoVy
2IIAnR3bK7ouApeHwmcjsQqViujN9VOC
=rmOD
-END PGP SIGNATURE-
From bb8503de4ff01949743ad228268b9bbb4392c66a Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Fri, 10 Apr 2009 11:04:32 +0200
Subject: [PATCH] wibox: Don't display garbage when a wibox is made visible

I did the following and the wibox displayed garbage:

local w = wibox({ position = floating, bg = #ff })
w.visible = false
w.screen = 1
do some other stuff
w.visible = true

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 wibox.c |   28 
 1 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/wibox.c b/wibox.c
index 5acd03a..a927502 100644
--- a/wibox.c
+++ b/wibox.c
@@ -42,6 +42,16 @@ wibox_need_update(wibox_t *wibox)
 }
 
 static void
+wibox_map(wibox_t *wibox)
+{
+xcb_map_window(globalconf.connection, wibox-sw.window);
+/* Make sure we don't display garbage */
+wibox_need_update(wibox);
+/* stack correctly the wibox */
+client_stack();
+}
+
+static void
 wibox_move(wibox_t *wibox, int16_t x, int16_t y)
 {
 if(wibox-sw.window)
@@ -560,12 +570,7 @@ wibox_setvisible(wibox_t *wibox, bool v)
 if(wibox-screen != SCREEN_UNDEF)
 {
 if(wibox-isvisible)
-{
-xcb_map_window(globalconf.connection, wibox-sw.window);
-simplewindow_refresh_pixmap(wibox-sw);
-/* stack correctly the wibox */
-client_stack();
-}
+wibox_map(wibox);
 else
 xcb_unmap_window(globalconf.connection, wibox-sw.window);
 
@@ -658,16 +663,7 @@ wibox_attach(wibox_t *wibox, screen_t *s)
 ewmh_update_workarea(screen_virttophys(s-index));
 
 if(wibox-isvisible)
-{
-/* draw it right now once to avoid garbage shown */
-wibox_draw(wibox);
-xcb_map_window(globalconf.connection, wibox-sw.window);
-simplewindow_refresh_pixmap(wibox-sw);
-/* stack correctly the wibox */
-client_stack();
-}
-else
-wibox_need_update(wibox);
+wibox_map(wibox);
 }
 
 /** Create a new wibox.
-- 
1.6.2.1

Re: [PATCH] wibox: Don't display garbage when a wibox is made visible

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 At 1239369215 time_t, Uli Schlachter wrote:
 attached is the new version of that patch. It adds a new function wibox_map()
 which maps the wibox's window and makes sure it is correctly drawn. In my
 testing this results in no garbage drawn at all.
 
 Your solution probably works but I still raise my previous point:
 We need to draw once the wibox on its creation so the content is by
 default the background and not garbage.
 
 Your patch force to redraw wibox upon each map, but mapping a windows
 does not mean we need to redraw it.

I threw some printf() in there and noticed that need_update is already always
set anyway. Since the code already did this before, I think it won't cause
anything bad if awesome continues to do this no-op. Plus I can't figure out any
working alternative atm.
wibox_draw() skips invisible windows, so setting need_update on creation wont do
anything. Calling widget_render() directly in luaA_wibox_new() caused a segfault
and I didn't really want to dig into it, my lua-C-api-fu is pretty weak.

Plus, rendering the wibox once when it's created seems kinda wrong, it's
background etc can still be changed. wibox_map() is the first place where we
really need to display this wibox, so it should be the first time a call to
wibox_draw() / widget_render() is made.

  static void
 +wibox_map(wibox_t *wibox)
 +{
 +xcb_map_window(globalconf.connection, wibox-sw.window);
 +/* Make sure we don't display garbage */
 +wibox_need_update(wibox);
 +/* stack correctly the wibox */
 +client_stack();
 +}
 
 Good if you remove wibox_need_update();
 
  if(wibox-isvisible)
 -{
 -/* draw it right now once to avoid garbage shown */
 -wibox_draw(wibox);
 
 That comes from your previous patch; be careful, if you fix a patch,
 does not think I'll apply the patch-fixing-the-patch; I want only one.

Nope, it doesn't. Read the patch again ;). There are two similar looking hunks.
The first one was missing this wibox_draw() call and the second one had it.
Since I added wibox_map() I made both places use it.

So I'd asked you to suggest a better alternative or to merge this patch.

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)

iEYEARECAAYFAknfZxYACgkQABixOSrV999yGwCg6/OxIbT1j04utfLxyfure+Tk
TwwAniAjXk6U3P6n528xnfH6N6JXsnSQ
=fCus
-END PGP SIGNATURE-

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

Re: [PATCH] client_stack(): Only stack windows once per mainloop

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 At 1239378506 time_t, Uli Schlachter wrote:
 Here is the new version of the patch, rebased on top of latest master.
 
 Pushed.
 
 PS: I'd suggest you publish a branch online so I can merge, since you are
 sending a lot of patch. I can then cherry-pick/merge easily.

But... but... there are already so many git repos on git.znc.in and I ran out of
patches anyway... Oh and I wouldn't be allowed to rebase my branches anymore. :(

You win.
http://git.znc.in/?p=psychon/awesome.git;a=summary

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)

iEYEARECAAYFAknfeEIACgkQABixOSrV998adQCg0he61BVYnCzYx1dEhx76SUwa
U1UAn0QOzhfmvnH0dG9Tuf1e62Aa918C
=JlUo
-END PGP SIGNATURE-

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

Re: [Patch] export image drawing routines to Lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 At 1239844131 time_t, Gregor Best wrote:
 +static int
 +luaA_image_draw_rectangle(lua_State *L)
 +{
 +size_t len;
 +xcolor_t color;
 +image_t *image = luaL_checkudata(L, 1, image);
 +int x = luaL_checkint(L, 2);
 +int y = luaL_checkint(L, 3);
 +int width  = luaL_checkint(L, 4);
 +int height = luaL_checkint(L, 5);
 +int fill = luaA_checkboolean(L, 6);
 +const char *buf = luaL_checklstring(L, 7, len);
 +xcolor_init_reply(xcolor_init_unchecked(color, buf, len));
 +
 +color.red /= 256;
 +color.green /= 256;
 +color.blue /= 256;
 +color.alpha /= 256;
 +
 +imlib_context_set_image(image-image);
 
 Please, think the world asynchronously.
 Your color request is fine, but you do it like an old Xlib guy pulled
 from the 80's.
 
 You should 1) Check Lua stuff 2) Send requests 3) Do stuff 4) Get reply
 as late as possible.
 So it should be:
 
 cookie = xcolor_init_unchecked(color, buf, len);
 imlib_context_set_image(image-image);
 xcolor_init_reply(cookie);
 color.red /= 255;
 etc...
 
 Cheers,

How bad would it be to add color objects to lua? They do xcolor_init_unchecked()
when they are created and the xcolor_init_reply() can be delayed until they are
actually used (or garbage collected). That way colors could be reused and we
wouldn't have to xcolor_init_unchecked() the same color over and over again.

On the other hand, this might be a little ugly on the lua API side

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)

iEYEARECAAYFAknm8QQACgkQABixOSrV99/1DQCg87FjMLYjgfKvzE/ykKVLGU6g
JdMAoKCN9/u32CU+bfLPnZCtAzFL9GSu
=pr5S
-END PGP SIGNATURE-

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

Re: [Patch] export image drawing routines to Lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 At 1239871750 time_t, Uli Schlachter wrote:
 How bad would it be to add color objects to lua? They do 
 xcolor_init_unchecked()
 when they are created and the xcolor_init_reply() can be delayed until they 
 are
 actually used (or garbage collected). That way colors could be reused and we
 wouldn't have to xcolor_init_unchecked() the same color over and over again.

 On the other hand, this might be a little ugly on the lua API side
 
 As you point, it would be a little bit overkill on the Lua API side.
 What we could do is store colors in a cache, i.e. use an ordered array
 (like keybinding_t) of colors and add them when we get new colors.
 Since users usually use a bunch of a dozen of colors, it should not be
 too memory consuming.
 
 On the other side, if the user uses all 2^24 colors it can grow
 up to 200 MB. ;-)
 
 Cheers,

Then... Simply limit the number of colors in the cache and kick out the oldest
one if there is too few space available. The results wouldnt be much worse than
what we have currently if a user uses many colors, but it would be much better
if there are only a few used colors.

psychon

- --
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)

iEYEARECAAYFAknnBnEACgkQABixOSrV999tqACfUWwmJj6WDK8qhn68Rv4mjLd5
Hz0AoIoMSwa/lQVSuYHjn22wd/9iEZF/
=FVfx
-END PGP SIGNATURE-

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

color management API thoughts

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

despite having no time I looked into the xcolor_t API. I noticed that for colors
like #123456 this code splits everything up into red / green / blue components
and then does a query to the X server for the pixel value which goes together
with this color, but most of the code doesn't care about the pixel value. In
fact, only simplewindow_border_color_set() uses the pixel value and everything
else is only interested in the color components.

This means that awesome needlessly requests the pixel value from the server and
the code then only uses the color components.

Attached is a header as a proposal for a new API. This splits xcolor_t up into
color_t and xcolor_t. A color_t only provides the color components and tries to
not involve the X server at all (it still has to for colors like white instead
of #ff).
On the other hand, xcolor_t asks the X server for the pixel value, but doesn't
provide the single color components (red / green / blue). I had to add the
components back for luaA_pushcolor(), but I am thinking about this as internal
values which the code shouldn't use. If it wants the color components, it can
use color_t.

This API could solve some of the problems a color cache would also solve, but it
would solve them more nicely. If we don't need the pixel value, we just don't
request it and so save the round-trip to the X server...

Thoughts on this API? Is it too ugly to be included? Or is it worth it?

psychon

P.S.: I haven't written any code for this yet, just the attached header.
- --
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)

iEYEARECAAYFAknnS1IACgkQABixOSrV998AYQCghee/RjsxOejKaZPcJbWMwpAt
6uIAn2j/ZiPqOEX66or/VrJDHgTaIvK7
=kM9r
-END PGP SIGNATURE-
/* If you need the red / green / blue / alpha components, use color_t. If you
 * need the pixel value for a color, use xcolor_t. Currently, the only code in
 * awesome which needs this pixel value is simplewindow_border_color_set() which
 * is only called from the wibox / titlebar code. Everything else needs the
 * color components.
 *
 * The reason why the color components and the pixel values are kept so
 * seperate, is that a color like #123456 can be parsed without a request to the
 * server if you only need the components and I expect most colors to be in this
 * format.
 *
 * color_t uses 8 bit per color, because nothing really needs those 16 bits
 * which the X protocol provides.
 *
 * Since simplewindow_border_color_set() does not use the alpha value of a
 * color, support for alpha values was dropped from xcolor_t.
 */

typedef struct
{
uint8_t red;
uint8_t green;
uint8_t blue;
uint8_t alpha;
bool initialized;
} color_t;

typedef struct
{
/* Internal magic: if color is NULL, color_init_unchecked() already did
 * everything that needs to be done and color_init_reply() will just return.
 */
color_t *color;
uint8_t alpha;
/* This cookie is only used if you specify colors like white instead of
 * #ff. This is the only case where this needs a request to the server.
 */
xcb_alloc_named_color_cookie_t cookie;
} color_init_cookie_t;

color_init_cookie_t color_init_unchecked(color_t *, const char *);
bool color_init_reply(color_init_cookie_t);

typedef struct
{
/* This struct works as it did before, only the alpha member was dropped */
union
{
xcb_alloc_color_cookie_t cookie_hexa;
xcb_alloc_named_color_cookie_t cookie_named;
};

xcolor_t *color;
bool is_hexa;
bool has_error;
const char *colstr;
} xcolor_init_request_t;

typedef struct
{
uint32_t pixel;
/* I'd love to kill the color component fields, but luaA_pushcolor() needs
 * them. Anyway, everything else should *not* use them. If you are
 * interested in the color components and not the pixel value, use color_t.
 */
uint16_t internal_red;
uint16_t internal_green;
uint16_t internal_blue;

bool initialized;
} xcolor_t;

/* There's no reason for an extra length argument, the code already expected
 * NULL-terminated strings before and a strlen() isn't that expensive.
 */
xcolor_init_request_t xcolor_init_unchecked(xcolor_t *, const char *);
bool xcolor_init_reply(xcolor_init_request_t);

Re: New color management API

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 Hi Uli,
 
 At 1239996846 time_t, Uli Schlachter wrote:
 
 First, thanks for your work.
 
 +/** Send a request to initialize a color.
 + * \param color color_t struct to store color into.
 + * \param colstr Color specification.
 + * \return request informations.
 + */
 +color_init_cookie_t color_init_unchecked(color_t *color, const char *colstr)
 +{
 +xcb_screen_t *s = xutil_screen_get(globalconf.connection, 
 globalconf.default_screen);
 +color_init_cookie_t req;
 +ssize_t len = strlen(colstr);
 
 Na na na:
 - Never call str*() function, use the ones redefined in common/util.h
   (a_strlen() in this case)
 - Don't simplify the function proto because you are lazy. You should let
   the ssize_t for coltr length, because most of the time we can get the
   string _and_ its length in a single call (luaL_checklstring) which
   saves us from a useless call to a_strlen().

Uhm... ok, will do that.

 +if(req.color == NULL)
 +return true;
 +
 +xcb_alloc_named_color_reply_t *named_color;
 +
 +if((named_color = xcb_alloc_named_color_reply(globalconf.connection,
 +  req.cookie, NULL)))
 +{
 +req.color-red   = named_color-visual_red;
 +req.color-green = named_color-visual_green;
 +req.color-blue  = named_color-visual_blue;
 +req.color-alpha = 0xff;
 +req.color-initialized = true;
 +p_delete(named_color);
 +return true;
 +}
 
 Hum. So actually, you mean that even for your color_t you need to send
 an X request. I did miss that when arguing that your solution was nice,
 since I can't see the benefits right now.
 Or do I miss something else?

Yeah, you miss something ;)

Colors like #aa77ee are parsed without asking the X server. Colors like green,
white and black are parsed via the named_color xcb API. I'd honestly like to
drop support for these named colors, but that *might* break some lua apps which
use them.

However, most people use the html color notation (#123456) and that one is
parsed without a query to the X server. In this case color_init_unchecked() does
all the work itself and sets req.color and so color_reply() just returns true:

+if(req.color == NULL)
+return true;

So this patch should eliminate the need to query the X server in 90% of cases
and if you allow me to not parse named colors, I can avoid it in all cases this
API is used.

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)

iEYEARECAAYFAknpc4MACgkQABixOSrV9988AACg2BsSohoe4JYp9UxD0bSCxhE2
PhgAn1z9FlkmsQvM5/2lXYlbfB3LURyP
=AUPz
-END PGP SIGNATURE-

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

[PATCH] Fix typo

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This was introduced in 21978546ebaa53200540c624e6d277f36edf63eb.
Looking at the diff, it seems obvious that this should have been
util.table.join instead of the non-existent util.join.

This bug was triggered by every notification with an icon.

Signed-off-by: Uli Schlachter psyc...@znc.in
- ---
Since thunderbird seems to wrap my patches again and I'm too lazy to attach it:

This patch is also available at:
git://git.znc.in/psychon/awesome.git naughty-fix

 lib/naughty.lua.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/naughty.lua.in b/lib/naughty.lua.in
index e17b68a..ee06e7d 100644
- --- a/lib/naughty.lua.in
+++ b/lib/naughty.lua.in
@@ -345,7 +345,7 @@ function notify(args)
 -- if we have an icon, use it
 if icon then
 iconbox = widget({ type = imagebox, align = left })
- -iconbox:buttons(util.join(button({ }, 1, run), button({ }, 3, 
die)))
+iconbox:buttons(util.table.join(button({ }, 1, run), button({ }, 3,
die)))
 local img
 if type(icon) == string then
 img = image(icon)
- --
1.6.2.1

- --
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)

iEYEARECAAYFAknpf9gACgkQABixOSrV99/PeQCgvxWfw3Z4iYQGVTAuCfMUTnLQ
OdkAnjO9ubgcG5cT5GpnS1i8ZBrffiim
=uc8d
-END PGP SIGNATURE-

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

Using rlwrap in awesome-client

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

the old C version of awesome-client used readline which provided nice line
editing and history. With the switch to a shell script as awesome-client, this
was lost.

Julien showed me rlwrap and I made a small patch to make awesome-client use
rlwrap, if it is available. This works fine here with both bash and dash.

Opinions? Is this merge worthy? (Is the color stuff merge worthy? ;)
Should it be documented somewhere that awesome-client can take advantage of
rlwrap? If yes, where?

Uli

P.S.:
git://git.znc.in/psychon/awesome.git rlwrap
and
http://git.znc.in/?p=psychon/awesome.git;a=commitdiff;h=60595c55c
- --
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)

iEYEARECAAYFAknprPgACgkQABixOSrV99/wjwCfQUPXYm8ekmNl32n19w3w5tqS
bAYAni9zKFfqNaIhzcjdvcFxJPBr5AWB
=KZiS
-END PGP SIGNATURE-
From 60595c55cbe64de8f34f5084b3517c85a1d7d1af Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Sat, 18 Apr 2009 12:26:31 +0200
Subject: [PATCH] awesome-client: Use rlwrap if it is available

This should make this more usable again. The old C version used readline, if
possible and now the new bash version does too. :)

The idea to use rlwrap is from jd and it's a good one.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 utils/awesome-client |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/utils/awesome-client b/utils/awesome-client
index 4b027cb..ea3971c 100755
--- a/utils/awesome-client
+++ b/utils/awesome-client
@@ -1,5 +1,13 @@
 #!/bin/sh
 
+# rlwrap provides readline to stuff which doesn't know readline by itself
+RLWRAP=`which rlwrap 2/dev/null`
+
+if [ $RLWRAP !=  ]  [ $A_RERUN =  ]
+then
+	A_RERUN=no exec $RLWRAP $0
+fi
+
 DBUS_SEND=dbus-send
 
 if ! which ${DBUS_SEND} /dev/null 21
-- 
1.6.2.1

Re: [RFC + PATCH] awful.doc

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien Danjou wrote:
 At 1240582243 time_t, koniu wrote:
 I'm not 100% sure what you mean here, you didn't give an explicit
 reason why it's but from what I understand you don't want the filter
 function hardcoded like this. We can give possibility of supplying a
 custom function like this (any better?):
 http://git.mercenariesguild.net/?p=awesome.git;a=commitdiff;h=ceb8555b2ec5ce510ab18610a6e678277dcc9bef
 
 I was thinking something like
 
 function list(filter)
 local ret = {}
 for k, v in pairs(data) do
 if filter(k, v) then
 -- filter return true, add k and v to ret
 ret[k] = v
 end
 end
 return ret
 end

I'd suggest a little extension:

function list(filter)
local ret = {}
if not filter then
filter = function() return true end
end
for k, v in pairs(data) do
if filter(k, v) then
-- filter return true, add k and v to ret
ret[k] = v
end
end
return ret
end

(or if filter and filter(k, v) or true, but I'm not sure if that works)

Oh and apropos, since I'm writing a mail anyway:
http://git.mercenariesguild.net/?p=awesome.git;a=commitdiff;h=25bb703cc607ef829809834535c5478e7cb59e67

local data = setmetatable({}, { __mode = 'k' })

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)

iEYEARECAAYFAknx0RAACgkQABixOSrV998J2QCgp2KyGR+IA7sKdEJzRzdaJS4W
bA4An33PpquSbBKBsaYam3kjPdX04alw
=/3xC
-END PGP SIGNATURE-

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

Speeding up awful.client.setslave() / tasklist

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

today I had some fun with wm_torture[1] thanks to jd_ and I also had some fun
with another profiler[2] for lua which produces callgrind-like files which can
be opened in kcachegrind.

The throughput test was interesting (tests done with awesome 3.2.1 in Xephyr):
Just Xephyr, no WM:  3642.12189  windows per second
Default config:14.000677 windows per second
My own config:  0.510808 windows per second

So, clearly my config was doing something weird and I had some fun with
callgrind and later with the lua-callgrind thingie from [1]. The result was that
 56% of it's lua-cpu-time (no idea what [1] actually measures) was spent inside
awful.client.setslave().

Here is what happens:

function setslave(c)
local cls = visible(c.screen)
for k, v in pairs(cls) do
c:swap(v)
end
end

setslave() calls c:swap() once for each visible window. Ok, what does :swap()
do? It is defined in client.c line 1433 and contains some O(N) stuff (N = number
of managed clients) and this interesting snippet:

1457 /* Call hook to notify list change */
1458 if(globalconf.hooks.clients != LUA_REFNIL)
1459 luaA_dofunction(L, globalconf.hooks.clients, 0, 0);

Uhm, ok, it calls into some lua code...
Which code is this?

$ git grep hooks.client | grep '\.lua'
lib/awful/widget/tasklist.lua.in:hooks.clients.register(u)

(for context: this is in awful.widget.tasklist.new() and u is:
 local u = function () tasklist_update(w, buttons, label, data, widgets) end)

So, each time the clients hook is called, each tasklist is updated. This is
fine by itself, but if we come back to awful.client.setslave() (which I happen
to call in my manage hook) this means that for each visible window, the tasklist
is updated once (and according to my callgrind tests from before, drawing all
that text repeatedly is quite expensive).

While I don't think we should optimize for an unrealistic benchmark[3], I wonder
if we can't do better. So, anyone got some ideas what could be done? Does the
innocent-looking (well, it still walks the list of all visible windows...)
really have to be this expensive?

So far, I only thought about moving awful.client.setslave() into the C code, but
that seems to be quite inflexible.
Another way would be adding another need_update-like variable to globalconf,
something like need_hooks_clients_and_also_a_better_name_for_this? ;)

Cheers,
Uli

[1] http://mail.gnome.org/archives/gnome-devel-list/2005-August/msg00014.html
[2] http://jan.kneschke.de/projects/profiling-lua-with-kcachegrind
[3] wm_torture's throughput test measures how long it takes to map 200 windows,
the latency test even maps 1000 windows (but one after another).
- --
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)

iEYEARECAAYFAkoEgNoACgkQABixOSrV99+4+wCffdyKHg+X1yKnWM0yVzn9vfxu
OuwAoNyaNOCohqoWKCGPpsndtHQudnY+
=p5vb
-END PGP SIGNATURE-

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

3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

no idea what exactly just happened, but awesome crashed when I pressed ctrl-q in
konqueror. Syslog says:

May  9 10:49:21 psytux kernel: [ 8809.790642] awesome[4487]: segfault at 257a000
ip 0032a5c7d511 sp 7fffbd55e868 error 4 in 
libc-2.9.so[32a5c0+149000]

(Any idea how I can find out what error 4 means?

Uhm, ok, so where is this?
 objdump -S  /lib/libc-2.9.so | vim -R -
And I let vim search for c7d511 (the last part of the instruction pointer 
shown):
 32a5c7d511:   4d 8b 44 24 10  mov0x10(%r12),%r8
Scrolling up a little revealed that the next visible symbol there is memcpy():
 0032a5c7ced0 memcpy:

I have no idea what caused this and it doesn't seem reproducible which is why I
won't open a bug report. I'm updating to rc2 now and I will run awesome in
valgrind. Let's see if I can find anything...

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)

iQEcBAEBCAAGBQJKBU3EAAoJECLkKOvLj8sGYYcH/3k6qnEY/TBJIMieqJ6/BloW
3NJgvC2kmcsDuPD6ETJt2ywA/xcCm/p8Li2lYUd1STs3DaML2vrL14HZdFhdU0DR
i5gz6HNzWXWx9d1a8544moWg3nsfRbnuRhV75FQtx2U8NN7ZSKgj20ElHKifKItf
2p61xMSNKI0/jlg0NZqcVwUPe6+eexsS1Ouqj5UBftxeTdCFpcNIn0BX0AcW6K9X
Cds+QkzcMEhNAZXMM4yafhti94cSXxAKv+4wNAgPTQ5QA+eMYVegxkh8Od+KqAwJ
xQpEFwUvq39L0hJd3flrZ199soIKQGQMl5iIRMs7MiOMSZfq1YPsLhIeBqI7F+0=
=MbhN
-END PGP SIGNATURE-

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

Re: 3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1241861577 time_t, Uli Schlachter wrote:
 I have no idea what caused this and it doesn't seem reproducible which is 
 why I
 won't open a bug report. I'm updating to rc2 now and I will run awesome in
 valgrind. Let's see if I can find anything...
 
 What I can suggest is to call ulimit -c unlimited before running awesome.
 At least you'll have a coredump.
 And if you can reproduce it, recompiling with -O0 -fno-inline can help
 to have a more complete bt.
 
 Cheers,

Well, I went with valgrind and now got this backtrace (man, I miss debugging
symbols... btw I still can't compile awesome due to some missing dependencies).
Anyone got some ideas what's going on? Proposals how to get my beloved debug
symbols? :(

==22611== Invalid read of size 1
==22611==at 0x4A09F9E: memmove (mc_replace_strmem.c:517)
==22611==by 0x439E24: (within /usr/bin/awesome)
==22611==by 0x430031: (within /usr/bin/awesome)
==22611==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x41A843: (within /usr/bin/awesome)
==22611==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==22611==  Address 0x8148ed8 is 0 bytes after a block of size 96 alloc'd
==22611==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==22611==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
==22611==by 0x41A923: (within /usr/bin/awesome)
==22611==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==22611==by 0x40DFDC: (within /usr/bin/awesome)
==22611==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==22611==by 0x40E8A6: main (in /usr/bin/awesome)
==22611==
==22611== Invalid read of size 1
==22611==at 0x4A09F90: memmove (mc_replace_strmem.c:517)
==22611==by 0x439E24: (within /usr/bin/awesome)
==22611==by 0x430031: (within /usr/bin/awesome)
==22611==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x41A843: (within /usr/bin/awesome)
==22611==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==22611==  Address 0x8148ed9 is 1 bytes after a block of size 96 alloc'd
==22611==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==22611==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
==22611==by 0x41A923: (within /usr/bin/awesome)
==22611==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==22611==by 0x40DFDC: (within /usr/bin/awesome)
==22611==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==22611==by 0x40E8A6: main (in /usr/bin/awesome)
==22611==
==22611== Invalid write of size 1
==22611==at 0x4A09F94: memmove (mc_replace_strmem.c:517)
==22611==by 0x439E24: (within /usr/bin/awesome)
==22611==by 0x430031: (within /usr/bin/awesome)
==22611==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
==22611==by 0x41A843: (within /usr/bin/awesome)
==22611==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==22611==  Address 0x8148ed8 is 0 bytes after a block of size 96 alloc'd
==22611==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==22611==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
==22611==by 0x41A923: (within /usr/bin/awesome)
==22611==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==22611==by 0x40DFDC: (within /usr/bin/awesome)
==22611==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==22611==by 0x40E8A6: main (in /usr/bin/awesome)
==22611==
==22611== More than 1000 total errors detected.  I'm not reporting any more.
==22611== Final error counts will be inaccurate.  Go fix your program!
==22611== Rerun with --error-limit=no to disable this cutoff.  Note
==22611== that errors may occur in your program without prior warning from
==22611

Re: 3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mariusz Ceier wrote:
 Uli Schlachter pisze:
 Julien Danjou wrote:
 At 1241861577 time_t, Uli Schlachter wrote:
 I have no idea what caused this and it doesn't seem reproducible which is 
 why I
 won't open a bug report. I'm updating to rc2 now and I will run awesome in
 valgrind. Let's see if I can find anything...
 What I can suggest is to call ulimit -c unlimited before running awesome.
 At least you'll have a coredump.
 And if you can reproduce it, recompiling with -O0 -fno-inline can help
 to have a more complete bt.
 Cheers,
 Well, I went with valgrind and now got this backtrace (man, I miss debugging
 symbols... btw I still can't compile awesome due to some missing 
 dependencies).
 Anyone got some ideas what's going on? Proposals how to get my beloved debug
 symbols? :(
 Hi,
   Do you have git version of xcb-proto ? If yes revert commit
 fe7b12db4fc0e95f3eef038581bf2154e1727c7a, Correct the length
 calculation for the value field of GetPropertyReply. ... and rebuild
 libxcb and xcb-util ... :p
 
 Mariusz Ceier
 

Nope, this debian testing + awesome 3.3* from unstable (which pulled in
libxcb-atom1, libxcb-keysyms1 and libxdg-basedir1 from unstable).

jd: I guess the debian version doesn't have this... bug?

- --
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)

iQEcBAEBCAAGBQJKBYjPAAoJECLkKOvLj8sG7PsIAIcCwC5mHNZcpTT+K4amAWVI
AfWqK9uWonDcB6ZRJlm19cCoTNb7x56aXXZzyUJwbDxDPhEk7e8UbtTEIGVuZ2JU
ObfZczyEmgdIe522nxLpYemSlX8USZLPqSGaxpfCF032CVfSFB7Ezgh7gav/gfZb
ijuq+xNf1qChjFJom1QuThMTuLnd8px+fcUEEAqOMu7UpH97AAAlKGJjaw4BAh+p
889QO+lSMyf1Tm1cRSWwC04yOeI7Iil525AagLMLAMpwqnrEQ+8DQ7NPVVXqMo7H
hrJvgQoQS+XXNT5d3iXkJoKIA2qdj5tcq8ZOln21eb9g5j777ci8xWztnxRDsmE=
=G88D
-END PGP SIGNATURE-

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

Pull request - random build stuff and some minor config cleanup

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

jd just showed me git request-pull. Since I think it's a nice command, I just
had to try it. ;)
Here's the result:

The following changes since commit 0a1bf94036aaa4201d7b2f0f869afe321088de9d:
  Julien Danjou (1):
build: remove useless check for libs

are available in the git repository at:

  git://git.znc.in/psychon/awesome.git for-jd

Uli Schlachter (8):
  Fix a wrong leading space in gperf.sh's shebang
  Remove some useless use of cat
  Fix a bashism in gperf.sh
  Use 'sh' instead of 'sh -e'
  Use tr [:lower:] [:upper:] instead of the a-z one
  Use _LDFLAGS instead of _LIBRARIES
  Get the shell for spawn_with_shell earlier
  Don't use obsolete table.foreach() in the default config

 awesomeConfig.cmake   |4 ++--
 awesomerc.lua.in  |   21 +++--
 build-utils/gperf.sh  |   17 +
 lib/awful/util.lua.in |6 ++
 4 files changed, 24 insertions(+), 24 deletions(-)
- --
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)

iQEcBAEBCAAGBQJKBdDCAAoJECLkKOvLj8sG41oH/26nzj786soKpnocKES+jryK
Yrzdq2Goz/fXyI54P35viVsZHy10tmn3PsAzX8Afe7qXLI6MPybfIvEyJLc7CfH8
5B1zNXHtBYK0Cah/sz40QAK8puoiMvZ25ecagobAtnXSUGw3P1FGQyxKwxYrpjZu
Vw1DPma6uxt9nXSDP9Kp9lvtD0zcGdaGPhHo3n+BBVM1j6z/JA13mRrJqLOFssnz
y2QqHBOiSI1d1wW4smVsMrmZn+xdufnWAsrdKdQdeW5e83S+V/PVepDpSV95YFpb
6/QLpTvlarNKpPFX6hh7+xDIgjI9maSK822Ew6QvW+7tcK1n8r2eUmhY+hx7eyo=
=MzQu
-END PGP SIGNATURE-

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

Re: 3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1241874772 time_t, Uli Schlachter wrote:
 Well, I went with valgrind and now got this backtrace (man, I miss debugging
 symbols... btw I still can't compile awesome due to some missing 
 dependencies).
 Anyone got some ideas what's going on? Proposals how to get my beloved debug
 symbols? :(
 
 http://naquadah.org/~jd/debian/awesome_3.3~rc2-1_nostrip-debug-noopt_amd64.deb
 

Hi,

now it crashed again and valgrind finally gave some more useful backtraces:

==4386== Invalid read of size 1
==4386==at 0x4A09F9E: memmove (mc_replace_strmem.c:517)
==4386==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
==4386==by 0x430031: luaA_widget_newindex (widget.c:490)
==4386==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x41A843: property_handle_net_wm_icon (luaa.h:261)
==4386==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==4386==  Address 0x5cde9b0 is 0 bytes after a block of size 96 alloc'd
==4386==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==4386==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
==4386==by 0x412EA2: client_manage (util.h:155)
==4386==by 0x417D90: event_handle_maprequest (event.c:645)
==4386==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
==4386==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==4386==by 0x40E8A6: main (awesome.c:536)
==4386==
==4386== Invalid read of size 1
==4386==at 0x4A09F90: memmove (mc_replace_strmem.c:517)
==4386==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
==4386==by 0x430031: luaA_widget_newindex (widget.c:490)
==4386==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x41A843: property_handle_net_wm_icon (luaa.h:261)
==4386==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==4386==  Address 0x5cde9b1 is 1 bytes after a block of size 96 alloc'd
==4386==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==4386==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
==4386==by 0x412EA2: client_manage (util.h:155)
==4386==by 0x417D90: event_handle_maprequest (event.c:645)
==4386==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
==4386==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==4386==by 0x40E8A6: main (awesome.c:536)
==4386==
==4386== Invalid write of size 1
==4386==at 0x4A09F94: memmove (mc_replace_strmem.c:517)
==4386==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
==4386==by 0x430031: luaA_widget_newindex (widget.c:490)
==4386==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x41A843: property_handle_net_wm_icon (luaa.h:261)
==4386==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==4386==  Address 0x5cde9b0 is 0 bytes after a block of size 96 alloc'd
==4386==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==4386==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
==4386==by 0x412EA2: client_manage (util.h:155)
==4386==by 0x417D90: event_handle_maprequest (event.c:645)
==4386==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
==4386==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==4386==by 0x40E8A6: main (awesome.c:536)
==4386==
==4386== Process terminating with default action of signal 11 (SIGSEGV)
==4386==  Bad permissions for mapped region at address 0x605B000
==4386==at 0x4A09F94: memmove (mc_replace_strmem.c:517)
==4386==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
==4386==by 0x430031: luaA_widget_newindex (widget.c:490)
==4386==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==4386==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==4386

Re: 3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 Julien Danjou wrote:
 At 1241874772 time_t, Uli Schlachter wrote:
 Well, I went with valgrind and now got this backtrace (man, I miss debugging
 symbols... btw I still can't compile awesome due to some missing 
 dependencies).
 Anyone got some ideas what's going on? Proposals how to get my beloved debug
 symbols? :(
 http://naquadah.org/~jd/debian/awesome_3.3~rc2-1_nostrip-debug-noopt_amd64.deb
 
 
 Hi,
 
 now it crashed again and valgrind finally gave some more useful backtraces:
 
 ==4386== Invalid read of size 1
 ==4386==at 0x4A09F9E: memmove (mc_replace_strmem.c:517)
 ==4386==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
 ==4386==by 0x430031: luaA_widget_newindex (widget.c:490)
 ==4386==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x41A843: property_handle_net_wm_icon (luaa.h:261)
 ==4386==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
 ==4386==  Address 0x5cde9b0 is 0 bytes after a block of size 96 alloc'd
 ==4386==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
 ==4386==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
 ==4386==by 0x412EA2: client_manage (util.h:155)
 ==4386==by 0x417D90: event_handle_maprequest (event.c:645)
 ==4386==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
 ==4386==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
 ==4386==by 0x40E8A6: main (awesome.c:536)

New day, new backtrace (why does it only ever crash once per day for me?).
Notice that the memory was allocated in 'property_handle_net_wm_icon
(util.h:155)'. util.h:155 ist xrealloc() which is only ever called from
p_realloc() which in turn is called from several places.
Looking through client_manage() I would expect either the call to
client_array_push() or the image_ref() call (which calls
luaA_ref_array_append()) to be the cause. So this all points to the code in
common/array.h, I guess, but I'd expect bugs in there to be more visible... :/

==4485== Invalid read of size 1
==4485==at 0x4A09F9E: memmove (mc_replace_strmem.c:517)
==4485==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
==4485==by 0x430031: luaA_widget_newindex (widget.c:490)
==4485==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
==4485==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
==4485==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
==4485==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
==4485==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
==4485==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
==4485==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
==4485==by 0x41A843: property_handle_net_wm_icon (luaa.h:261)
==4485==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==4485==  Address 0x8136948 is 0 bytes after a block of size 96 alloc'd
==4485==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==4485==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
==4485==by 0x41A923: property_handle_net_wm_icon (util.h:155)
==4485==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
==4485==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
==4485==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==4485==by 0x40E8A6: main (awesome.c:536)

Cheers,
Uli

P.S. I'm only posting this so that I can find all my backtraces in one place.
- --
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)

iQEcBAEBCAAGBQJKCR3/AAoJECLkKOvLj8sGvEAH/jPd7aPZFCXAfk55cC7i/DaL
i0F5SBz5ls5E+AUPxwCm04SN7XSD0jsUSf9X2Hop22d33+psrhJitayKsapj8lxT
wzZEn3rpNTMbxu1IWOJyWWaGN+XVyJXIdOGGssTYN5Fus070t2tvX58ergDfi6h2
kuXnrfshoUxkOhu3XLi3HQafJby8SDQxmh/9J/7GqOB2n73oyorZMBgWYOBolUBR
RziJpqo6XvXgAkOa3H+ufMwCReCGmaEY/nADelkcYUP4C+P/nIuaXjhN/fUEa3FM
pvj4hX6zy3hctv1s01o+gQ6YGc3WEIMso5jLhBPx5JTb87iYTFWRT6t4TEmSLWw=
=p9LU
-END PGP SIGNATURE-

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

Invalid _NET_WM_ICONs not properly caught

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

while trying to find a reason for the crash I've been seeing with rc2, I noticed
that awesome doesn't properly handle invalid _NET_WM_ICONs. It just assumes the
width and height reported in the property is valid, even if the property is much
shorter than those values would make you think.
The attached C app (which is based on some code from farhaven) shows this. It
sets some invalid _NET_WM_ICON property for it's window and this results in the
following under valgrind:

==18057== Source and destination overlap in memcpy(0x7E598E0, 0x7E597C0, 4092)
==18057==at 0x4A0954A: memcpy (mc_replace_strmem.c:402)
==18057==by 0x3B6F810924: imlib_create_image_using_copied_data (in
/usr/lib/libImlib2.so.1.4.2)
==18057==by 0x4317C7: image_new_from_argb32 (image.c:133)
==18057==by 0x41B8EF: ewmh_window_icon_get_reply (ewmh.c:667)
==18057==by 0x4129A5: client_manage (client.c:502)
==18057==by 0x417D90: event_handle_maprequest (event.c:645)
==18057==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
==18057==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==18057==by 0x40E8A6: main (awesome.c:536)
==18057==
==18057== Invalid read of size 1
==18057==at 0x4A09570: memcpy (mc_replace_strmem.c:402)
==18057==by 0x3B6F810924: imlib_create_image_using_copied_data (in
/usr/lib/libImlib2.so.1.4.2)
==18057==by 0x4317C7: image_new_from_argb32 (image.c:133)
==18057==by 0x41B8EF: ewmh_window_icon_get_reply (ewmh.c:667)
==18057==by 0x4129A5: client_manage (client.c:502)
==18057==by 0x417D90: event_handle_maprequest (event.c:645)
==18057==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
==18057==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==18057==by 0x40E8A6: main (awesome.c:536)
==18057==  Address 0x7e598df is 1 bytes before a block of size 4,092 alloc'd
==18057==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
==18057==by 0x3B6F810912: imlib_create_image_using_copied_data (in
/usr/lib/libImlib2.so.1.4.2)
==18057==by 0x4317C7: image_new_from_argb32 (image.c:133)
==18057==by 0x41B8EF: ewmh_window_icon_get_reply (ewmh.c:667)
==18057==by 0x4129A5: client_manage (client.c:502)
==18057==by 0x417D90: event_handle_maprequest (event.c:645)
==18057==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
==18057==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
==18057==by 0x40E8A6: main (awesome.c:536)

If no one comes up with a patch first, I'll give it a try on thursday (no time
before then).
So far it looks like ewmh_window_icon_get_reply() needs some check like this (+
handling integer overflows somehow):
 if (width * height + 2  length) error()

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)

iQEcBAEBCAAGBQJKCTp/AAoJECLkKOvLj8sG8QUH/3stzkdN25dyU3UOevRnwELA
/jHS012sKLEl2CwYkdlWWlDFq17DxvYlXRshzZNK0fB4U91r/qjV4RmJKXjalB5x
RENTdCPZBDUE2x1iSfkRH47V945bak2mj6eKhFQfyK7vy9TwOuJrCbM7GEnRHRnf
fwx555TaA0g1ADArI3c6RUqJtcDlN6ojrsJYXidpD/bTicv2spHGZ57JOhQXFFPS
35MDzU+v8a0dQyN5F98JyLlamlITD4fPEI7Dzyhef6FyEK0oPwLLPPzDfVbUc61F
KZAjBGlaeIDSf9+bdP43gH96hO9leQtT1XtL8M/R6VrxOwBnHw5XvvRDQuDx+eI=
=NrvI
-END PGP SIGNATURE-
/* stolen from wikipedia and modified a bit,
 * compile like this:
 * gcc -o test test.c -lxcb -std=c99
 */

#include xcb/xcb.h
#include stdio.h
#include stdlib.h
#include string.h

int main(int argc, char **argv)
{
int  i;
xcb_connection_t*c;
xcb_screen_t*s;
xcb_window_t w;
xcb_gcontext_t   g;
xcb_generic_event_t *e;
uint32_t mask;
uint32_t values[2];
int  done = 0;
xcb_rectangle_t  r = { 20, 20, 60, 60 };

const uint32_t data[5] = { 31, 33, 73, 13, 37 };
const char *CARD = CARDINAL;
const char *ICON = _NET_WM_ICON;
xcb_atom_t cardinal, icon;

c = xcb_connect(NULL,NULL);
if (xcb_connection_has_error(c))
{
printf(Cannot open display\n);
exit(1);
}

s = xcb_setup_roots_iterator( xcb_get_setup(c) ).data;
fprintf(stderr, width=%d height=%d\n, s-width_in_pixels, s-height_in_pixels);

cardinal = xcb_intern_atom_reply(c, xcb_intern_atom_unchecked(c, 0, strlen(CARD), CARD), NULL)-atom;
icon = xcb_intern_atom_reply(c, xcb_intern_atom_unchecked(c, 0, strlen(ICON), ICON), NULL)-atom;

mask = XCB_CW_BACK_PIXEL | XCB_CW_EVENT_MASK;
values[0] = s-white_pixel;
values[1] = XCB_EVENT_MASK_EXPOSURE | XCB_EVENT_MASK_KEY_PRESS;

w = xcb_generate_id(c);
xcb_create_window(c, s-root_depth, w, s-root,
(10 * i) % s-width_in_pixels, (10 * i) % s-height_in_pixels, 100, 100, 1,
XCB_WINDOW_CLASS_INPUT_OUTPUT, s-root_visual,
mask, values);

Re: 3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nikos Ntarmos wrote:
 Hi there.
 
 FWIW I've also been experiencing segfaults on FreeBSD/i386, however only
 when X goes down before awesome. A short look into this revealed it was
 due to widgets update hooks being scheduled for some time after
 awesome and X is down. I never got around to looking into this any
 further but it's still there in my todo list. If you disable any
 widgets, timers, etc. do you still get those backtraces?
 
 Cheers.
 
 \n\n

Hi,

Sorry that I didn't reply earlier, I kinda missed this. This sounds like a
completely different issue to me, since my crashes are during normal usage, nor
during shutdown.

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)

iQEcBAEBCAAGBQJKDHKPAAoJECLkKOvLj8sG83sH/jZ+mabrJkydEJumflbT72tc
9VdgnRz3L1ZmbgG5IFn7+q10Rm7QE9njxstkJJFziB0JnGO8Ll8KBmkUu5I5N8fI
DMb6Xj4amyCFr86OwVgQMd6fPlGHWWoyd+i3H274QWR8ARUrjiQXKDSlcm/I4xo/
isuqiwrj2soKQtTYGuvKL/uxRw/m+X6kKx86Xif8wpBg2tZkug6DfQQE8Z+XbUaN
EyGNDvL2WwRtNX0nD5seCuYimGYzezNndwwrMkTKnQyNj+7tLkuZEpk68oTZtqQs
+nt/0OV9g0xNVcFLgwpvCkPp8uDCdpiRbXNj1tzs/2hdp22X2KN3tFwh/LSJakg=
=A2xw
-END PGP SIGNATURE-

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

Re: 3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 Uli Schlachter wrote:
 Julien Danjou wrote:
 At 1241874772 time_t, Uli Schlachter wrote:
 Well, I went with valgrind and now got this backtrace (man, I miss 
 debugging
 symbols... btw I still can't compile awesome due to some missing 
 dependencies).
 Anyone got some ideas what's going on? Proposals how to get my beloved 
 debug
 symbols? :(
 http://naquadah.org/~jd/debian/awesome_3.3~rc2-1_nostrip-debug-noopt_amd64.deb
 
 Hi,
 
 now it crashed again and valgrind finally gave some more useful backtraces:
 
 ==4386== Invalid read of size 1
 ==4386==at 0x4A09F9E: memmove (mc_replace_strmem.c:517)
 ==4386==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
 ==4386==by 0x430031: luaA_widget_newindex (widget.c:490)
 ==4386==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
 ==4386==by 0x41A843: property_handle_net_wm_icon (luaa.h:261)
 ==4386==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
 ==4386==  Address 0x5cde9b0 is 0 bytes after a block of size 96 alloc'd
 ==4386==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
 ==4386==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
 ==4386==by 0x412EA2: client_manage (util.h:155)
 ==4386==by 0x417D90: event_handle_maprequest (event.c:645)
 ==4386==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
 ==4386==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
 ==4386==by 0x40E8A6: main (awesome.c:536)
 
 New day, new backtrace (why does it only ever crash once per day for me?).
 Notice that the memory was allocated in 'property_handle_net_wm_icon
 (util.h:155)'. util.h:155 ist xrealloc() which is only ever called from
 p_realloc() which in turn is called from several places.
 Looking through client_manage() I would expect either the call to
 client_array_push() or the image_ref() call (which calls
 luaA_ref_array_append()) to be the cause. So this all points to the code in
 common/array.h, I guess, but I'd expect bugs in there to be more visible... :/
 
 ==4485== Invalid read of size 1
 ==4485==at 0x4A09F9E: memmove (mc_replace_strmem.c:517)
 ==4485==by 0x439E24: luaA_imagebox_newindex (luaobject.h:39)
 ==4485==by 0x430031: luaA_widget_newindex (widget.c:490)
 ==4485==by 0x30AAE0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4485==by 0x30AAE0D028: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4485==by 0x30AAE173DB: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4485==by 0x30AAE0D084: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4485==by 0x30AAE0C706: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4485==by 0x30AAE0C784: (within /usr/lib/liblua5.1.so.0.0.0)
 ==4485==by 0x30AAE08093: lua_pcall (in /usr/lib/liblua5.1.so.0.0.0)
 ==4485==by 0x41A843: property_handle_net_wm_icon (luaa.h:261)
 ==4485==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
 ==4485==  Address 0x8136948 is 0 bytes after a block of size 96 alloc'd
 ==4485==at 0x4A0891E: malloc (vg_replace_malloc.c:207)
 ==4485==by 0x4A08AA7: realloc (vg_replace_malloc.c:429)
 ==4485==by 0x41A923: property_handle_net_wm_icon (util.h:155)
 ==4485==by 0x3565A00BE8: (within /usr/lib/libxcb-property.so.1.0.0)
 ==4485==by 0x40DFDC: a_xcb_check_cb (awesome.c:203)
 ==4485==by 0x32AE607216: ev_loop (in /usr/lib/libev.so.3.0.0)
 ==4485==by 0x40E8A6: main (awesome.c:536)
 
 Cheers,
 Uli
 
 P.S. I'm only posting this so that I can find all my backtraces in one place.

And another backtrace, this time with gdb...
The plan for is to finally use -O0 -fno-inline and see what happens. (btw yay,
finally done with school and I got time for this!) (Oh and another btw: I still
don't know any way to reproduce this, it just happens :( )

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fe166b55740 (LWP 4868)]
0x0032a5c7d4dc in ?? () from /lib/libc.so.6
#0  0x0032a5c7d4dc in ?? () from /lib/libc.so.6
No symbol table info available.
#1  0x0032a5c7b92c in memmove () from /lib/libc.so.6
No symbol table info available.
#2  0x00439e25 in luaA_imagebox_newindex (L=0x26e10b0, token=value
optimized out) at /home/ancient/jd/Work/debian/awesome/common/luaobject.h:39
buf = value optimized out
len = value optimized out
widget = (widget_t *) 0x2b3bcd8
d = (imagebox_data_t *) 0x2937550
#3  0x00430032 in luaA_widget_newindex (L=0x26e10b0) at
/home/ancient/jd/Work/debian/awesome/widget.c:490
len = 5
widget = (widget_t *) 0x2b3bcd8
buf = value optimized out

Re: 3.3-rc1 crash bug (?)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1242331287 time_t, Uli Schlachter wrote:
 And another backtrace, this time with gdb...
 The plan for is to finally use -O0 -fno-inline and see what happens. (btw 
 yay,
 finally done with school and I got time for this!) (Oh and another btw: I 
 still
 don't know any way to reproduce this, it just happens :( )


 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x7fe166b55740 (LWP 4868)]
 0x0032a5c7d4dc in ?? () from /lib/libc.so.6
 #0  0x0032a5c7d4dc in ?? () from /lib/libc.so.6
 No symbol table info available.
 #1  0x0032a5c7b92c in memmove () from /lib/libc.so.6
 No symbol table info available.
 #2  0x00439e25 in luaA_imagebox_newindex (L=0x26e10b0, token=value
 optimized out) at /home/ancient/jd/Work/debian/awesome/common/luaobject.h:39
  buf = value optimized out
  len = value optimized out
  widget = (widget_t *) 0x2b3bcd8
  d = (imagebox_data_t *) 0x2937550
 #3  0x00430032 in luaA_widget_newindex (L=0x26e10b0) at
 /home/ancient/jd/Work/debian/awesome/widget.c:490
  len = 5
  widget = (widget_t *) 0x2b3bcd8
  buf = value optimized out
  token = A_TK_UNKNOWN
 
 That's just weird. If the token is A_TK_UNKNOWN, it's because some code
 is doing myimagebox.blabla = value where blabla is not a known
 attribute, therefore we get A_TK_UNKNOWN as token.

This call is from somewhere inside the tasklist widget, so I'd expect no such
weirdness in there.

 Then it calls luaA_imagebox_newindex which does not handle A_TK_UNKNOWN
 in its switch() statement, so it goes to default which return 0.
 
 Where the hell memmove is called from lua object function, I don't see.
 
 I suggest that next time you try to print some stuff and dig directly
 into the code/debugger because I really miss what's wrong.

 Thanks anyway :)

 Cheers,


Well, I still don't have a test case for this. It just... happens... sometimes.
Oh and since debian testing now got kde4 I don't have kde3's konqueror anymore.
I bet this fixes this bug.
Meh... :(

Cheers,
Uli

P.S.: Welcome back, jd.
- --
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)

iQEcBAEBCAAGBQJKEVuJAAoJECLkKOvLj8sGDO4H/RPiTvLQ4FsPArr3We5FLjcW
jvZSBwxqY+mOgL0KPipGU/0gIRylUdMkrs+0c1m8Q5kh0a5MuWKKB27uqW6IOQyd
lug73YMNVetA7afmXpnnmqABt0ekSAnA+ESiJh/JffWI20iu4kV5qy9mz7ser6bh
UK4lycgGpayZh6HrE2sh2I+7Q7E1olAWi+sGQqFSbHSeb0pXYm62D3DPZEF2srUZ
4+B5ts1+7EdwgsR2Mla38jIalSJBPSLwvzBv77lYrxuDkvl3QpJDuH8th2VZ8jO7
PgiVnc4/GqcPIICUZi32K2S3/UpM+kTO53evmABbrZooPjUnOEwHGI2fBPieDsA=
=QLIi
-END PGP SIGNATURE-

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

Build breakage [was: Updated patch: Unfocused titlebar icons look bad on non-black background]

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1242491867 time_t, Johan Kiviniemi wrote:
 Sorry for the flood. Attached is a new version of the patch with the
 values tweaked to resemble the original icons more closely when using
 a dark background.

 A comparison between Awesome’s current behavior and the patch can be
 seen at http://heh.fi/tmp/awesome-titlebar-icons/
 
 Very nice patch.
 
 Pushed, thanks.
 
 Cheers,

Hi,

This patch breaks the build for me. Attached is the result of the following 
command:
  $ rm -r .build-*  LC_ALL=C make -j3 21 | tee /tmp/out

This box is running debian testing.

make --dry-run contains the following convert call:
/usr/bin/convert
/home/psychon/projects/awesome/themes/default//titlebar//sticky_focus_active.png
- -evaluate Pow 2 -channel A -evaluate Multiply 0.4
/home/psychon/projects/awesome/.build-psytux-x86_64-linux-gnu-4.3.3/themes/default//titlebar//sticky_normal_active.png

Used version is:
  $ convert --version
Version: ImageMagick 6.3.7 04/07/09 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

Sadly I've never used imagemagick and dont have much clue about it...

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)

iQEcBAEBCAAGBQJKEV6lAAoJECLkKOvLj8sG/VsH/jDtGsVpK6PPMjIVX5Iw/gcp
9okZg5nTPOmt2rCXS7lZEbGUfDlh3RMemtUFkg+Gjvjy8RyYv30aIPtVubK9LELX
SO+IaRpfKFYtwl9aD0it8gQ+FpZldjKk54lzjOXIWzod0ZvVNEtvBrzwzwT4Ozjf
ChNuoCNPJCwzDqGgxuMRAkklh8nVRVDr0j2g633uoBCiD3ByV6DAeME4vpu0FX7a
Pb/rueGVQHrcMYn/HPQp+EPck+NKP7VBLFL/ouCF+SpeXnJJNlWwahZ3PcJ8Xw9M
GASyptakBH+iv/As2dCFwsVpF6pQ+oaIiWFI7rdjOeZVDrtEQZSARL/WHx5EEhU=
=sMNY
-END PGP SIGNATURE-
Running cmake…
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/lib/ccache/gcc
-- Check for working C compiler: /usr/lib/ccache/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/ccache/c++
-- Check for working CXX compiler: /usr/lib/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- cat - /bin/cat
-- ln - /bin/ln
-- grep - /bin/grep
-- git - /usr/bin/git
-- hostname - /bin/hostname
-- gperf - /usr/bin/gperf
-- asciidoc not found.
-- xmlto not found.
-- gzip - /bin/gzip
-- lua - /usr/bin/lua
-- luadoc not found.
-- convert - /usr/bin/convert
-- Could NOT find Doxygen  (missing:  DOXYGEN_EXECUTABLE)
-- Found Lua51: /usr/lib/liblua5.1.so;/usr/lib/libm.so
-- Not generating manpages. Missing: asciidoc xmlto
-- Not generating luadoc. Missing: luadoc
-- checking for module 'xcb=1.1'
--   found xcb, version 1.2
-- checking for modules 
'glib-2.0;cairo;x11;pango=1.19.3;pangocairo=1.19.3;xcb-randr;xcb-xtest;xcb-xinerama;xcb-event=0.3.4;xcb-aux=0.3.0;xcb-atom=0.3.0;xcb-keysyms=0.3.4;xcb-icccm=0.3.3;xcb-image=0.3.0;xcb-property=0.3.0;cairo-xcb;libstartup-notification-1.0=0.10;xproto=7.0.15;imlib2;libxdg-basedir=1.0.0'
--   found glib-2.0, version 2.20.0
--   found cairo, version 1.8.6
--   found x11, version 1.2.1
--   found pango, version 1.24.0
--   found pangocairo, version 1.24.0
--   found xcb-randr, version 1.2
--   found xcb-xtest, version 1.2
--   found xcb-xinerama, version 1.2
--   found xcb-event, version 0.3.4
--   found xcb-aux, version 0.3.4
--   found xcb-atom, version 0.3.4
--   found xcb-keysyms, version 0.3.4
--   found xcb-icccm, version 0.3.4
--   found xcb-image, version 0.3.4
--   found xcb-property, version 0.3.4
--   found cairo-xcb, version 1.8.6
--   found libstartup-notification-1.0, version 0.10
--   found xproto, version 7.0.15
--   found imlib2, version 1.4.2
--   found libxdg-basedir, version 1.0.0
-- checking for module 'dbus-1'
--   found dbus-1, version 1.2.12
-- Configuring lib/beautiful.lua
-- Configuring lib/awful/titlebar.lua
-- Configuring lib/awful/mouse.lua
-- Configuring lib/awful/widget/button.lua
-- Configuring lib/awful/widget/taglist.lua
-- Configuring lib/awful/widget/init.lua
-- Configuring lib/awful/widget/common.lua
-- Configuring lib/awful/widget/tasklist.lua
-- Configuring lib/awful/widget/prompt.lua
-- Configuring lib/awful/widget/launcher.lua
-- Configuring lib/awful/hooks.lua
-- Configuring lib/awful/button.lua
-- Configuring lib/awful/client.lua
-- Configuring lib/awful/util.lua
-- Configuring lib/awful/placement.lua
-- Configuring lib/awful/init.lua
-- Configuring 

Re: Invalid _NET_WM_ICONs not properly caught

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 Hi Uli,
 
 Sorry for the delay.
 
 At 1242329343 time_t, Uli Schlachter wrote:
 Subject: [PATCH 1/2] Restructure the code in ewmh_window_icon_from_reply() 
 slightly
 
 Ack.

No changes to this patch (afaik).

 Subject: [PATCH 2/2] Check that the property is as long as it should be
 +unsigned long long len;
 
 NEIN!
 
 Never ever use this fucking type inside awesome, please. It's just a
 pain to known which size it will have on every arch in the world. We get
 ride of them with Xlib gone, good riddance. And XCB has a sane behaviour
 using stdint so let's use them.
 If you are checking for CARD32, the corresponding type is uint32_t.

 +/* Check that the property is as long as it should be, handling integer
 + * overflow. unsigned long long got at least 64 bit and thus this
 + * multiplication can not overflow.
 + */
 
 Well you can use uint64_t.

Done

 +len = data[0] * (unsigned long long) data[1];
 +if (!data[0] || !data[1] || len  r-length - 2) {
 +/* TODO remove this warning */
 +warn(Ignoring invalid icon);
 +return 0;
 +}
 +
 
 Yeah, remove it. ;-)

Also done

Both patches are attached again.

Cheers,
Uli

P.S.: Damn, I forgot [Patch] in the topic
- --
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)

iQEcBAEBCAAGBQJKEbHPAAoJECLkKOvLj8sGMOQH/1ctzpGsRrbVP5veOFATJYOd
vfELM4SbVV69Zq1Q+Sg2AEMTOB6+zPpEiYBjLSyHJ2apk5pUrqoiagaC0TiljezQ
dQsO/xYwSttuJ6A/DwgYpM+C/FXxNaESK67TRoU1G/WCCoc7TEnbDM44gRLt7f2W
I/oSDh9IFfE/MFAndPG5laC19aEufIXdtWtSari8gmSgsBJtXTzOmhseQd1I+QIm
80kcCwy5l/1q907HyX8kDpNjg7RAJzkG/+pUvKRo43UyTHVm1ljzs0QpqMDTDcgK
C/6zP3WpBNFc52mX+VaZiS32doZ4UrIN/U//0qk+KcXyesVuWJwmEVXfhrmAW8A=
=1grJ
-END PGP SIGNATURE-
From 50dc7f55cc9a8ae74e1eaa8118a6e30ebcc56f25 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Tue, 12 May 2009 11:05:34 +0200
Subject: [PATCH 1/2] Restructure the code in ewmh_window_icon_from_reply() slightly

This is just a preparation for the following commit.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 ewmh.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/ewmh.c b/ewmh.c
index 2ac8bd7..19ae6cb 100644
--- a/ewmh.c
+++ b/ewmh.c
@@ -662,11 +662,14 @@ ewmh_window_icon_from_reply(xcb_get_property_reply_t *r)
 {
 uint32_t *data;
 
-if(r  r-type == CARDINAL  r-format == 32  r-length = 2 
-   (data = (uint32_t *) xcb_get_property_value(r))  data[0]  data[1])
-return image_new_from_argb32(data[0], data[1], data + 2);
+if(!r || r-type != CARDINAL || r-format != 32 || r-length  2)
+return 0;
 
-return 0;
+data = (uint32_t *) xcb_get_property_value(r);
+if (!data || !data[0] || !data[1])
+return 0;
+
+return image_new_from_argb32(data[0], data[1], data + 2);
 }
 
 /** Get NET_WM_ICON.
-- 
1.6.2.4

From d31cb05f29a9bb5868f3b5bc0f08b6979edaf807 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Tue, 12 May 2009 11:08:43 +0200
Subject: [PATCH 2/2] Check that the property is as long as it should be

Before this, a _NET_WM_ICON could have been 5 bytes long but still claiming
that the image it describes is 100x100 pixel in size.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 ewmh.c |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/ewmh.c b/ewmh.c
index 19ae6cb..a490524 100644
--- a/ewmh.c
+++ b/ewmh.c
@@ -661,14 +661,24 @@ int
 ewmh_window_icon_from_reply(xcb_get_property_reply_t *r)
 {
 uint32_t *data;
+uint64_t len;
 
 if(!r || r-type != CARDINAL || r-format != 32 || r-length  2)
 return 0;
 
 data = (uint32_t *) xcb_get_property_value(r);
-if (!data || !data[0] || !data[1])
+if (!data)
 return 0;
 
+/* Check that the property is as long as it should be, handling integer
+ * overflow. uint32_t times another uint32_t casted to uint64_t always
+ * fits into an uint64_t and thus this multiplication cannot overflow.
+ */
+len = data[0] * (uint64_t) data[1];
+if (!data[0] || !data[1] || len  r-length - 2) {
+return 0;
+}
+
 return image_new_from_argb32(data[0], data[1], data + 2);
 }
 
-- 
1.6.2.4

[Patch] Allow setting wibox.opacity if wibox.screen is nil (was: Re: [PATCH] naughty: set screen first and opacity afterwards)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1239465244 time_t, Gregor Best wrote:
 Hmm, the thing is, here it works fine with first opacity, then screen, and to
 be honest, I don't really see why it shouldn't work. Opacity is a WM hint 
 just
 like the class, name, whatever, so it should be used correctly by xcompmgr. 
 If
 it works for you however, I'm in favor of merging it, be it just for the sake
 of people with broken setups (:P) having working opacity settings.
 
 Actually Leon's patch is bad, but there's still a bug.
 If a wibox does not have a screen, it does not have a window, so we
 can't set the X property.
 We should store opacity in the wibox_t struct and set it upon creation
 or change with some helpers function.
 
 Cheers,

Hi,

I marked this mail as hey Uli, this sounds like a neat idea, why don't you
implement this when you have the time. Find the patch attached.

@jd:
I don't think if this bug is grave enough to apply the patch even after rc3. I'd
propose this patch goes into your next branch, but feel free to ignore me and
apply it to master if you want to.

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)

iQEcBAEBCAAGBQJKEpI4AAoJECLkKOvLj8sGnDsIAMejKj0psLreq94NHBnad0sj
eCyoE/ZZmKmltw9zCMc8bvNABEI+fBXylpi5X9JNRXbcTr9bhEKaZ2PfuDp0+rXz
eALhlvweQ4A8xWztrty9qQQzVFsNgahF0rEd4B781/dpd+5QC2vip3RXuabKC7YT
7wB3YdHb1oJZXbFOmt39+cG/MpSFsrwbXEcx5BFn1jcZ6kM9uF21vzwtizMUnM57
Z0BadhUvYFSQZNY/0LSguGvr+J8jV86A3GOX0dGVbvrlgqQEhkZ1h3rPe+vaV7ZF
PqWb0MpLW5k3VU1Kxm5vvEVO+8c7XsNaBrJ/RUbj3nuZVRnjlNpffAmZo1jTDP0=
=N/CH
-END PGP SIGNATURE-
From 2d822a1b9503638cf4082db77e25c2c2796689b7 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Tue, 19 May 2009 12:56:34 +0200
Subject: [PATCH] Handle opacity for invisible wiboxes

If a wibox is not attached to a screen, it does not have window and thus
wibox-sw.window is XCB_NONE. Obviously, we can't set properties on this
window, yet we tried.

This patch adds a new member to wibox_t which saves the opacity if the wibox
is not attached to any screen. If the wibox is attached, we can't use this
member, because something else might change the opacity of a wibox.

This bug (One can't set opacity of unattached wiboxes) was first described
on the awesome-devel mailing list:

http://article.gmane.org/gmane.comp.window-managers.awesome.devel/2047
http://article.gmane.org/gmane.comp.window-managers.awesome.devel/2049

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 wibox.c |   31 +++
 wibox.h |2 ++
 2 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/wibox.c b/wibox.c
index 48cf3dc..6acc7ab 100644
--- a/wibox.c
+++ b/wibox.c
@@ -630,6 +630,8 @@ wibox_detach(wibox_t *wibox)
 
 wibox-mouse_over = NULL;
 
+wibox-opacity = window_opacity_get(wibox-sw.window);
+
 simplewindow_wipe(wibox-sw);
 
 wibox-screen-need_arrange = true;
@@ -685,6 +687,8 @@ wibox_attach(screen_t *s)
 simplewindow_cursor_set(wibox-sw,
 xcursor_new(globalconf.connection, xcursor_font_fromstr(wibox-cursor)));
 
+window_opacity_set(wibox-sw.window, wibox-opacity);
+
 /* All the other wibox and ourselves need to be repositioned */
 foreach(w, s-wiboxes)
 wibox_position_update(*w);
@@ -717,6 +721,7 @@ luaA_wibox_new(lua_State *L)
 luaA_checktable(L, 2);
 
 w = wibox_new(L);
+w-opacity = -1;
 w-widgets_table = LUA_REFNIL;
 
 w-sw.ctx.fg = globalconf.colors.fg;
@@ -915,9 +920,14 @@ luaA_wibox_index(lua_State *L)
 break;
   case A_TK_OPACITY:
 {
-double d;
-if ((d = window_opacity_get(wibox-sw.window)) = 0)
-lua_pushnumber(L, d);
+if (wibox-sw.window != XCB_NONE) {
+double d = window_opacity_get(wibox-sw.window);
+if (d = 0)
+lua_pushnumber(L, d);
+else
+return 0;
+} else if (wibox-opacity = 0)
+lua_pushnumber(L, wibox-opacity);
 else
 return 0;
 }
@@ -1130,12 +1140,17 @@ luaA_wibox_newindex(lua_State *L)
 luaA_table2wtable(L);
 break;
   case A_TK_OPACITY:
-if(lua_isnil(L, 3))
-window_opacity_set(wibox-sw.window, -1);
-else
 {
-double d = luaL_checknumber(L, 3);
-if(d = 0  d = 1)
+double d = -1;
+if(!lua_isnil(L, 3))
+{
+d = luaL_checknumber(L, 3);
+if(d  0 || d  1)
+return 0;
+}
+if (wibox-sw.window == XCB_NONE)
+wibox-opacity = d;
+else
 window_opacity_set(wibox-sw.window, d

Re: [Patch] Allow setting wibox.opacity if wibox.screen is nil (was: Re: [PATCH] naughty: set screen first and opacity afterwards)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1242731066 time_t, Uli Schlachter wrote:
 I marked this mail as hey Uli, this sounds like a neat idea, why don't you
 implement this when you have the time. Find the patch attached.
 
 Since you seems to have time :-) I'd have another suggestion for the
 implementation for this patch. That should be done in at least 2 parts,
 because currently, there's a drawback with opacity handling in
 client also.
 
 For clients, we store opacity and set it via window_opacity_set().
 So far so good.
 
 But if someone changes the opacity via something else like transset, our
 internal value of opacity (in client_t) is... wrong.
 
 So I suggest that:
 1. you fix that for client: that's easy, you just need to add a watcher
for _NET_WM_WINDOW_OPACITY in property.c and update client
accordingly.
To do things cleanly, you may need to split window_opacity_get in
another function that does not send a GetProperty request (since you
   already that property reply when dealing with property handler in
   property.c)
 
 2. you do the exact same thing for wiboxes; that means you do not need to
use window_opacity_get, since it will be always up to date
 
 I can provide help or deeper explanation if needed.
 And I'd merge that into next.
 
 Cheers,

Yay, I get to learn more X stuff. :)

I'll give this idea a try tomorrow, thanks for the suggestion.

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)

iQEcBAEBCAAGBQJKErEFAAoJECLkKOvLj8sGoH4IAMWbBfz3cPPWwi45K5a2i0uY
UngJoO5CA3h4ug0DdV4xwrcNKjWbXYmHV3jrpnPwPcf7FwpzWZ7FM+di88HgtN4Z
uroysBF6F834ro+0SYrhngYDCLttDakVtFQje/wZS/fA0eTd7/FNZR1jOYSs16lZ
gYh46o59DWwZ422Zu+7P9j07yRAPecg75QXVO7Yol807zjVCGYASFM2JofYkvCVT
pfkwKN2L3JGQhfywwsz0Oa+bnV8ieTAam42eiqcZHN09WJvimAt3p4kb33FLmur5
p+YY4N04WJJZ0PZkGGcwUkCTahKJUjemHZbb7RiOkyIWfJ72iSbAnFolJqqAP28=
=sgnC
-END PGP SIGNATURE-

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

Re: Thanks, Uli!

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrei Thorp wrote:
 I've just noticed that Uli writes tonnes of little finicky patches for
 internals that people don't think about and optimization. He also
 catches/fixes a lot of subtle bugs this way. I find that it's very
 uncommon for someone to spend so much effort and time fixing up little
 internal bits that most people aren't aware of as problem-causing.
 Thanks a bunch, Uli :)
 
 -AT
 

Uhm ehhh yeah it wasn't me *hide*.

- --
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)

iQEcBAEBCAAGBQJKEwwYAAoJECLkKOvLj8sGbjYH/3PBGYNM2yJK3PBFYJ0i5cTo
CewIurh4tuCTgmCL8hdMwbZh5Zl43AK3gcUEQRvjYiqNWpvgK3PFGlxiwEU+hPin
sR7SvyWjsqL32aRpv0BzKiBFAWv/D3aq8K98ePDtLcpVdZNujRQD6f/Zxeu9US1K
+l4Sl05833gwNfhjLFvmC3/R1mLv3jVEJHw3VQFE162YioxZdJbIVnLuIrTiUByM
2gajWN50elG5RqHrLKreVptlRlXeWyFlgsm6Kj8K/0YAMxluE6GBupH8RKVPvctL
0ebwvJjrxq17BZU9qAFxYWKHk7KkA9qSicxO8xvb4vK/6o4nmsGpdI519l0H4Nk=
=vBTa
-END PGP SIGNATURE-

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

[Patches] Fix some minor compiler warnings found in rc3

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

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.

Anyway, here are two patches for the compiler warnings:

The following changes since commit 40710e43ba517b63b42579228d4efd0e7c42954a:
  Johan Kiviniemi (1):
themes/sky: Titlebar icons: use current default theme paths

are available in the git repository at:

  git://git.znc.in/psychon/awesome.git for-jd

Uli Schlachter (2):
  Fix a harmless compiler warning
  Fix a couple of harmless compiler warnings

 mousegrabber.c|2 +-
 widgets/graph.c   |1 +
 widgets/imagebox.c|2 ++
 widgets/progressbar.c |2 ++
 widgets/systray.c |2 ++
 widgets/textbox.c |2 ++
 6 files changed, 10 insertions(+), 1 deletions(-)
- --
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)

iQEcBAEBCAAGBQJKGTbLAAoJECLkKOvLj8sGBdgIAKNW43NQyqWuA6Ps82QKd6o9
vceu7AEfg7ivsmRaA0D62+lwkCl0dhLIUmCfHwxgmTae4VkD9cClwoVEZUbqUE3B
E9qujZ1knV6BQ0ow540RwtKXFznB7+v2mPAUtB5XPETB8pEpNMuZHO9kbVnwDHaK
Vn8D0OfYMEXHUpGIDR+/tj2CHtm6O1mm5weNXGhXsJ/3Wa3VtL4tXJNS/GU6Tsht
Eoi1NU8ocHdAEfETzeRWxM7RG7+QqimcsnxQLmDo5saed485Jk7uwU8KIoun85vN
4mDXH29awVzmp09hI4MIM1DMq2UH2FzVayyBZVFKOFWmwOmKELTvmxCDXDU2p/8=
=l5ra
-END PGP SIGNATURE-

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

Re: New logo / Web site contest

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 Hi fellow users and developers,
 
 I'd like to fresh awesome a bit. We still used a logo from the
 2.x branch, and a website half-designed by me. I won't judge the logo,
 but as for my Web design skills, they suck hard.
 
 With our growing user base, I'm sure their is a couple of top designers
 around that can make a cool logo and a cool new Web page for our
 project.
 
 Feel free to discuss ideas here and around.
 
 Submission requirement:
 - SVG source if possible;
 - If possible, background free (so it can be used on white, black or
   grey);
 - If possible, 2 colour or black version;
 - Square version (64x64 or things like that), mainly to use as icon;
 - The logo should looks nice for printing; it could be fun to use it for
   additional media, like clothes, wallpapers, etc;
 - For the Web site graphics, it probably should be a new CSS; the
   current site use ikiwiki[1] and sources are available[2].
 
 Any omission will not make your proposal invalid anyway.
 
 As we don't have a status for developers and/or users, judging will be
 done by everyone, and I'll take the final decision: so if you like some
 work, you'll just have to give it +1 by mail, and we'll count that as a vote.
 
 The plan is to get this out for awesome 3.4 release, or around that
 time at least. Considering our current release rate, that should bring
 us to September.
 
 [1] http://ikiwiki.info/
 [2] http://git.naquadah.org/?p=awesome-www.git;a=summary
 
 Cheers,

I like the attached logo. Dunno if someone comes up with a better one, but so
far it's the best submission IMHO.

/me hides under a rock again

- --
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)

iQEcBAEBCAAGBQJKHUP2AAoJECLkKOvLj8sG0z0IAJq6lDH80O+SPDJ2nHjeqoAQ
NlTo898LT/jGIs42bVIdoEP7ZCuBOqqsB+gs0+s6WC8521aBhzwPurSFJ7O0wJ7+
PVQqQ22r5J3sgchck98qAfdRYtlMXZlPpomvE9v/TIil5df8hl/acVK7RBIfSgVL
4rm5Ymwbkrx4V7+6viGvl5i1/VFM+YrbBscFXoSM0GtkOT0OG6miz6vnGorE2sAf
AeXEeKiNWAYb1ftS2WNUu+sBHDlbOo7ioZhnlGh3iJgbgNUa3DLaYZyoZ2G28ICe
BcGmdqa9FYkM7Ihms7BoN0p/vRRNzKIBe1py4hoSoSWKx0DPMr6NDpux7uyBsk4=
=JDRL
-END PGP SIGNATURE-
inline: awesome64.png

rounded wibox corners

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Garoth (jokingly?) asked for rounded corners on wiboxes. With the help of
plagman I took a look at the X nonrectangular window shape extension and came
up with the attached C file. It creates a window and adds some rounded corners
on it. All the code in main() isn't needed for making some of a window's corner
rounded.
Before I start hacking on wibox.c I wanted to ask you guys about comments. The
functions init(), init_arc() and do_rounded_corners() can be easily copy-pasted
into awesome and one can just add a call to do_rounded_corners() when a wibox is
resized plus some lua magic for setting the corner size and which corners are
rounded.

Should I try to do so or are there some issues with the current code that would
have to be sorted out first? (E.g. farhaven suggested to load the mask for the
rounded corners from a file instead of generating it, I dunno...)

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)

iQEcBAEBCAAGBQJKIDiYAAoJECLkKOvLj8sGIKAH/RXlxexYve16lHeGzfgQQjb6
7kXr7ztAJAwVuBGiS7BnJNUnZsDkBi4p3yTVlUBwwYZuKiyOXKLEJuqJ5ac8PFSL
GcdDT/T4PioFGiQc3MsrpdzvZDy9v6cVaCAGumcNL7upxjOM4xGSecWQAAtRebHw
jAn50XzlWqui7fae3/RORZGcj17DiVapu2NQwXWNd3fIohxAm5YtFU/xzUgy8RGs
mHpsjFhRUP99ljdFw0uS3az9Ybxb+caNllhudv+aZsn7BrM25tx8e2yZMHIikPE4
HDnGQ4pdud+5EoqYTVfvhy+b2isOelGiaGiHw6BLmKvbxLsRPFaZkqsMXAtH5Nc=
=lwor
-END PGP SIGNATURE-
/* stolen from wikipedia and modified a bit,
 * then again stolen from farhaven.
 * compile like this:
 * gcc -o test test.c -std=c99 $(pkg-config --cflags --libs xcb xcb-shape)
 */

#include xcb/xcb.h
#include xcb/shape.h
#include stdio.h
#include stdlib.h
#include string.h

static int have_xshape = 0;

static void init(xcb_connection_t *c)
{
const char *name = SHAPE;
xcb_query_extension_cookie_t cookie;
xcb_shape_query_version_cookie_t shape_cookie;
xcb_shape_query_version_reply_t *shape;

cookie = xcb_query_extension(c, strlen(name), name);
if (!xcb_query_extension_reply(c, cookie, NULL)-present) {
have_xshape = 0;
return;
}

shape_cookie = xcb_shape_query_version_unchecked(c);
shape = xcb_shape_query_version_reply(c, shape_cookie, NULL);
printf(XShape version %d.%d\n, shape-major_version, shape-minor_version);
/* This works with all existing versions of the SHAPE extension, so no
 * version check is required.
 */
have_xshape = 1;
}

static void init_arc(xcb_arc_t *a, int x, int y, int corner, int angle)
{
a-x = x;
a-y = y;
a-width = corner * 2;
a-height = corner * 2;
a-angle1 = angle * 64;
a-angle2 = 90 * 64;
}

/* In each corner there is an arc which does the actual rounded corner,
 * the rest is covered by three rectangles:
 *-
 *   /|  1|\
 *  |---|
 *  |   |
 *  |2  |
 *  |   |
 *  |---|
 *   \|  3|/
 *-
 */

static void do_rounded_corners(xcb_connection_t *c, xcb_window_t w, xcb_screen_t *s, int corner, int width, int height,
int top_left, int top_right, int bottom_left, int bottom_right)
{
if (!have_xshape)
return;
/* Make sure the corner size is a sane value, anything bigger than half the
 * window will break
 */
if (corner  width / 2)
corner = width / 2;
if (corner  height / 2)
corner = height / 2;
xcb_rectangle_t full_window = { 0, 0, width, height };
xcb_arc_t arcs[4];
int num_arcs = 0;
xcb_rectangle_t  rects[] = {
{ corner, 0,   width - corner * 2, corner }, /* 1 Top area */
{ 0, corner,   width, height - corner * 2 }, /* 2 Middle */
{ corner, height - corner, width - corner * 2, corner }  /* 3 bottom area */
};
xcb_pixmap_t p;
xcb_gcontext_t   g;
uint32_t mask;
uint32_t values[1];
int num_rects = sizeof(rects) / sizeof(rects[0]);

/* Set up the stuff we intend to draw (= have visible) */
if (top_left)
init_arc(arcs[num_arcs++], 0, 0, corner, 90);
else {
/* Extend rectangle 1 to cover this corner */
rects[0].width += rects[0].x;
rects[0].x = 0;
}
if (top_right)
init_arc(arcs[num_arcs++], width - corner * 2, 0, corner, 0);
else {
/* Rect 1 got to cover this area then */
rects[0].width += corner;
}
if (bottom_left)
init_arc(arcs[num_arcs++], 0, height - corner * 2, corner, 180);
else 

Re: rounded wibox corners

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 Hi,
 
 At 1243625625 time_t, Uli Schlachter wrote:
 Should I try to do so or are there some issues with the current code that 
 would
 have to be sorted out first? (E.g. farhaven suggested to load the mask for 
 the
 rounded corners from a file instead of generating it, I dunno...)
 
 Seems pretty ok. Maybe it'd need some rearrangement to be more readable,
 and also respect a little more STYLES, but seems ok as far as I
 understand it.

Uhm, yeah, I bet it would at least cause some warnings with awesome's CFLAGS.

 What's your userland API proposal for this feature ?

Uhm, the plan so far was to have a corner_size and for each corner a setting
whether it should be rounded or not. Originally I planned a corner_size setting
for each corner, but maths defeated me (There were rounding issues).

 Because I'm wondering if exporting rounded corner is enough. I'd suggest
 we export more or less XShape to Lua and then add rounded corner, which
 is a particular usage of XShape, to awful.

Uhm... Actually, this could be done quite easy *if* someone adds some API for
drawing 1bit depth (black and white) pixmaps via some lua api :P

 YMMV, and I know nothing about XShape. :)

You create a 1bit pixmap (size doesn't really matter, it will be clipped to the
window's geometry) for your window. Everything which is black will be
transparent, the white part is what actually stays visible. Then you do one
single XShape call and the window got the pixmap's shape.
Well... XShape can do more than this and I just remember that I have to check
how it affects window borders. The spec allow you to set three pixmaps (I forgot
how those are called). One is describes the... uhm... shape? of the window.
Another one defines which part of the window is the border (the difference
between this pixmap and the last one is the window border) and XShape 1.1 adds a
new option which is the input area. I'm not exactly sure what this does, but I
guess it does something input related. ;)

Looking at the current image lua API, I kinda doubt that it's worth to use this
for generating a 1bit pixmap. Plus, if a window is resized you pretty much have
to set a new pixmap. Everything else would look ugly or make the resize 
pointless.

I think it's better to just have rounded via some C code for now...

Cheers,
Uli

P.S.: Since a 1bit pixmap is used there can be no gray involved and thus no
anti-aliasing is possible. I'd doubt if some fancy-shape window with rough
corners would look good...
- --
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)

iQEcBAEBCAAGBQJKIPNZAAoJECLkKOvLj8sGBGAH/i1f2Ys3w/HvTx/LC373mfF7
Zuxt7ztlEXgsJ5jeOmt53xYhB0z0lbKIlOAJ3woXhIEDxKApZWmZuyzi3RDOd4uo
R00+9jsr0AV2/95m4BBtnSznXdVnvVDp/tCSh/01797lufNlyME+EUiJdPREiEoi
0ONRpXEXB6yypmRg4SgQDsKHkEyVsDcgJDq5XAUvcUNE4LPoaloiqEs4pHpqmnUt
/ekBEbM/3QhHQWqf1697/nFdfR7Y9ABQfu4cJ4QSIyhdiBkO2YehPgO/nMSOQr0B
XuzSi10EcwdQ8DxPjuxNQcghAiD0z+tD+K78Nz5+bgwSQe0PPObSu+/9Nfa2e+s=
=KZBR
-END PGP SIGNATURE-

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

[Patch] Some fixes

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I'm currently trying to make my config work with current master. One thing I
found: awful.widget.graph and .progressbar don't offer the same features their C
counterparts had. I'll see if I write some patches on this...

The first patch makes awful.wibox() work with non-north orientation and
user-specified geometries.

The second one is some cleanup and a fix to naughty (I wonder why no one ran
into this yet...).

The last one fixes the SIGSEGV handling, because we can't use libev for this.
See the commit msg for an explanation.

Let's see which other patches I will come up with... (Anyone wants to enhance
awful.widget.*? vertical progressbars and graphs with more than one graph sound
like a goal (I use one graph which shows used mem and caches/buffers at the same
time))

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)

iQEcBAEBCAAGBQJKKk1gAAoJECLkKOvLj8sGkEoIAJq43QLn24uLcCGUKxHmV7ZQ
k7M7/WJmGb08ZzvxgHIZOxy0joBgGFibxk9jSPWFPt0kVQXR9FGvMBrWfPglUOLY
igBp8TtaJl8fc1daeA8jI0fLpJk49Tu9+GVnN5Hi09l1SzP0DBSyNr6eEDP7JfIw
iUiNDWRvqyKBIUIVpYS3uv5SlnjyLQOeT3ctQhnIFOQOtDWbr+MJvFhrNWZBL9V9
NFxv9/utenY9O57RJSVmbSPTuVPPAWTpPazfpwRkmC6fVF/kEWkjn4TZ593rRBYg
STQfafRS4IJhHVNj0I+ilt8tHkOJ8L0knXITBfGU7W+PedC7bUwsccXhsjZGUJI=
=zYBq
-END PGP SIGNATURE-
From 304cc3c9f787719a043d81368bd0171f1dbbca5c Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Fri, 5 Jun 2009 23:28:54 +0200
Subject: [PATCH 1/3] awful.wibox(): Honour user specified geometries

If a wibox with non-north geometry was created and a wibox size was specified,
this function happily ignored it when it made the wibox fit.

The hunk in wibox.c partly reverts 7cc0b13eae2638aaab40bfd1632036a6bea4d8d4.
No idea if this is a good idea or why that one was done...

Thanks to Garoth who found this bug.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/awful/wibox.lua.in |   24 ++--
 wibox.c|4 ++--
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/lib/awful/wibox.lua.in b/lib/awful/wibox.lua.in
index 190caea..48c710c 100644
--- a/lib/awful/wibox.lua.in
+++ b/lib/awful/wibox.lua.in
@@ -237,14 +237,26 @@ function new(arg)
 -- Empty position and align in arg so we are passing deprecation warning
 arg.position = nil
 
+-- Set default size
+if position == left or position == right then
+arg.width = arg.width or capi.awesome.font_height * 1.5
+arg.height = arg.height or 100
+else
+arg.width = arg.width or 100
+arg.height = arg.height or capi.awesome.font_height * 1.5
+end
+
 local w = capi.wibox(arg)
 
-if position == left then
-w.orientation = north
-w:geometry({ width = capi.awesome.font_height * 1.5 })
-elseif position == right then
-w.orientation = south
-w:geometry({ width = capi.awesome.font_height * 1.5 })
+if position == left or position == right then
+if position == left then
+w.orientation = north
+else
+w.orientation = south
+end
+-- We need to swap width and height
+local old_geom = w:geometry()
+w:geometry({ width = old_geom.height, height = old_geom.width })
 end
 
 w.screen = arg.screen or 1
diff --git a/wibox.c b/wibox.c
index 69009c9..a54634c 100644
--- a/wibox.c
+++ b/wibox.c
@@ -488,8 +488,8 @@ luaA_wibox_new(lua_State *L)
 w-sw.border.width = luaA_getopt_number(L, 2, border_width, 0);
 w-sw.geometry.x = luaA_getopt_number(L, 2, x, 0);
 w-sw.geometry.y = luaA_getopt_number(L, 2, y, 0);
-w-sw.geometry.width = luaA_getopt_number(L, 2, width, 100);
-w-sw.geometry.height = luaA_getopt_number(L, 2, height, globalconf.font-height * 1.5);
+w-sw.geometry.width = luaA_getopt_number(L, 2, width, 0);
+w-sw.geometry.height = luaA_getopt_number(L, 2, height, 0);
 
 w-isvisible = true;
 w-cursor = a_strdup(left_ptr);
-- 
1.6.3.1

From e3f5970ad30d2e601a5766ee1d2932f814d8e4c9 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Sat, 6 Jun 2009 12:28:25 +0200
Subject: [PATCH 2/3] Minor fixes

Remove an unused var and fix a reference to capi.awesome

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/awful/wibox.lua.in |1 -
 lib/naughty.lua.in |2 +-
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/lib/awful/wibox.lua.in b/lib/awful/wibox.lua.in
index 48c710c..111f6ec 100644
--- a/lib/awful/wibox.lua.in
+++ b/lib/awful/wibox.lua.in
@@ -231,7 +231,6 @@ end
 -- If not specified, 1 is assumed.
 -- @return The wibox created.
 function new(arg)
-local screen = screen or 1
 local arg = arg or {}
 local position = arg.position or top
 -- Empty position and align in arg so we are passing

Re: [Patch] Some fixes

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 The first patch makes awful.wibox() work with non-north orientation and
 user-specified geometries.

I'm just a human Attached is a New and Improved (tm) version of this first
patch.

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)

iQEcBAEBCAAGBQJKKmTmAAoJECLkKOvLj8sGlPUIAM1qjONuZIvt7XpKU9uCKpPJ
Md7vti15oyjjMUiaqND95pbLuEYjuFIjuUznNaYi0AfWrnCpCyvRP0VtpJHqBAYv
kGfNkz31rxnd5gd2TPw9dmwtQCwxuHFxwxwlCAAjulDq7rJ9h59q/WCPP7TmvMNa
7TyWtFG830p8Brz8WG/MAKUMUnC1TpyoinFBbIGSWwEDwfP9ks7EziD5WBR5Wk/x
NFqdRHA4YhQu/kzuGBS/a1Xzwf/rRi4wUmtWOBQpiLs1XloJBLSnQCtH3gFk7BJ0
diZm2ObFkvgarjUW7k1gJ97fj/4iQWkjA4zZj1KTBiVOB8mJ3MP1zt0KN78MP6Q=
=1Rkp
-END PGP SIGNATURE-
From cbbec52a98f35f25fb6d9d99510c065e19662b60 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Fri, 5 Jun 2009 23:28:54 +0200
Subject: [PATCH] awful.wibox(): Honour user specified geometries

If a wibox with non-north geometry was created and a wibox size was specified,
this function happily ignored it when it made the wibox fit.

The hunk in wibox.c partly reverts 7cc0b13eae2638aaab40bfd1632036a6bea4d8d4.
No idea if this is a good idea or why that one was done...

Thanks to Garoth who found this bug.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/awful/wibox.lua.in |   11 +--
 wibox.c|4 ++--
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/lib/awful/wibox.lua.in b/lib/awful/wibox.lua.in
index 190caea..939f52e 100644
--- a/lib/awful/wibox.lua.in
+++ b/lib/awful/wibox.lua.in
@@ -237,14 +237,21 @@ function new(arg)
 -- Empty position and align in arg so we are passing deprecation warning
 arg.position = nil
 
+-- Set default size
+if position == left or position == right then
+arg.width = arg.width or capi.awesome.font_height * 1.5
+arg.height = arg.height or 100
+else
+arg.width = arg.width or 100
+arg.height = arg.height or capi.awesome.font_height * 1.5
+end
+
 local w = capi.wibox(arg)
 
 if position == left then
 w.orientation = north
-w:geometry({ width = capi.awesome.font_height * 1.5 })
 elseif position == right then
 w.orientation = south
-w:geometry({ width = capi.awesome.font_height * 1.5 })
 end
 
 w.screen = arg.screen or 1
diff --git a/wibox.c b/wibox.c
index 69009c9..a54634c 100644
--- a/wibox.c
+++ b/wibox.c
@@ -488,8 +488,8 @@ luaA_wibox_new(lua_State *L)
 w-sw.border.width = luaA_getopt_number(L, 2, border_width, 0);
 w-sw.geometry.x = luaA_getopt_number(L, 2, x, 0);
 w-sw.geometry.y = luaA_getopt_number(L, 2, y, 0);
-w-sw.geometry.width = luaA_getopt_number(L, 2, width, 100);
-w-sw.geometry.height = luaA_getopt_number(L, 2, height, globalconf.font-height * 1.5);
+w-sw.geometry.width = luaA_getopt_number(L, 2, width, 0);
+w-sw.geometry.height = luaA_getopt_number(L, 2, height, 0);
 
 w-isvisible = true;
 w-cursor = a_strdup(left_ptr);
-- 
1.6.3.1

Re: [Patch] Some fixes

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1244286306 time_t, Uli Schlachter wrote:
 I'm currently trying to make my config work with current master. One thing I
 found: awful.widget.graph and .progressbar don't offer the same features 
 their C
 counterparts had. I'll see if I write some patches on this...
 
 Like ?
 
 Let's see which other patches I will come up with... (Anyone wants to enhance
 awful.widget.*? vertical progressbars and graphs with more than one graph 
 sound
 like a goal (I use one graph which shows used mem and caches/buffers at the 
 same
 time))
 
 No no no, do not rewrite that crap again. Wants more graph on top of
 each other? Use a widget layout. :-)

And if I want this now and not in 6 months? Plus this wouldnt work since graphs
aren't transparent AFAIK. Well, ok, I guess I dont really need the memory used
for caches...

So, what's up with the patches I posted?

- --
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)

iQEcBAEBCAAGBQJKKpHjAAoJECLkKOvLj8sGxT4H/120mPVSJGknBw/27BjUEo6o
6Py66bre9jOspu5OuFzI0DN4kPWWjLsXBuP2aMBm/nbMA9NsCuXTcmjBIpdN64P7
DKaP48MXjO2mAIq6rzax6DP8bZLmLpReOpvi1ry02sgjUdFYSkf/Xh0Tegf/bYHt
gSKEToj8rQLhble4zU7+slFtWgayWw4pX+rPJ++GCgj3L6baU5vrK15ah6gAHm8J
KihvsQ08YHCt//O4Sm4mvGJ+QoPfvdObAELNK47HPXes8NXaVYb2NhGouLB6yYBn
6H2GlsARppcbfjW22IyN1fp+QHdBuCMFvk3Upe+54qsa+gRB4vF90U5jsvUpe0U=
=Qsko
-END PGP SIGNATURE-

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

Re: [Patch] Some fixes

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

calmar c. wrote:
 On Sat, Jun 06, 2009 at 03:23:03PM +0200, Julien Danjou wrote:
 Let's see which other patches I will come up with... (Anyone wants to 
 enhance
 awful.widget.*? vertical progressbars and graphs with more than one graph 
 sound
 like a goal (I use one graph which shows used mem and caches/buffers at the 
 same
 time))
 No no no, do not rewrite that crap again. Wants more graph on top of
 each other? Use a widget layout. :-)
 
 the graph has more than one thing. You can use a line style to
 have one over all others.
 
 -- -- graph widget
 gr_cpu = widget({ type = graph, align = right })
 gr_cpu.width = 70
 gr_cpu.height = 0.90
 gr_cpu.grow = left
 gr_cpu.bg = beautiful.gr_cpu_bg
 gr_cpu.border_color = beautiful.gr_cpu_border_color
 
 gr_cpu:plot_properties_set(total, 
 { 
   [fg] = beautiful.gr_cpu_total_fg,
   [fg_center] = beautiful.gr_cpu_total_center,
   [fg_end] = beautiful.gr_cpu_total_end,
   [vertical_gradient] = true,
   [scale] = false,
   [max_value] = 100.0,
   [style] = bottom
 })
 gr_cpu:plot_properties_set(user, 
 { 
   [fg] = beautiful.gr_cpu_user_fg,
   [fg_center] = beautiful.gr_cpu_user_center,
   [fg_end] = beautiful.gr_cpu_user_end,
   [vertical_gradient] = true,
   [scale] = false,
   [max_value] = 100.0,
   [style] = bottom
 })
 gr_cpu:plot_properties_set(nice, 
 { 
   [fg] = beautiful.gr_cpu_nice_fg,
   [fg_center] = beautiful.gr_cpu_nice_center,
   [fg_end] = beautiful.gr_cpu_nice_end,
   [vertical_gradient] = true,
   [scale] = false,
   [max_value] = 100.0,
   [style] = line
 })

This doesn't work in master (well, it does, but you get a deprecation warning
and awful.widget.graph which is supposed to replace this doesn't work with any
of these lines). Which is why I wanted to add some of this back...

@Julien: Apropos, any reason why we can't have 'scale = true'? Would you mind a
patch which adds this back, too? And if we have auto-scaling, adding back
max_value (currently it requires values between 0 and 1) wouldn't be much work
either

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)

iQEcBAEBCAAGBQJKKppGAAoJECLkKOvLj8sG2LkH/R3Y+1QT7HzVLDSsj4zAHxgF
GnIWH4M2beAUyxaUE7+DBlE234i2bLbaBUwcdG5W+EmrrpFj0twrAX8QbY8dgX4q
PCEgowwjh/PTUPx+zXoK9bTSeegupoH/rzVGHjBoFuNG+PkEYBfPFpA3T7J9uMGy
/LRTihhhltIGTqUF0Bo2Ondt1EWyv5vXJCQnEt7ZRA1wbrUjEu05R0BuLip/6nQ/
fiyFFWlI8wRPTVBiV8al5jkNE92UO9WeLlSfNNacib0eLMMHME4uQUSDrBLK7M9+
lc2TaW8yjU5UcrxDf73l+bX1fdV1cBjqsCFHOoAeNRjFcxUa4EHLqXqL0JZuBk0=
=P2xU
-END PGP SIGNATURE-

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

Re: [Patch] Some fixes

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1244292328 time_t, Uli Schlachter wrote:
 I'm just a human Attached is a New and Improved (tm) version of this 
 first
 patch.
 
 Me too, ignore my previous mail.
 
 ---
  lib/awful/wibox.lua.in |   11 +--
  wibox.c|4 ++--
  2 files changed, 11 insertions(+), 4 deletions(-)

 diff --git a/lib/awful/wibox.lua.in b/lib/awful/wibox.lua.in
 index 190caea..939f52e 100644
 --- a/lib/awful/wibox.lua.in
 +++ b/lib/awful/wibox.lua.in
 @@ -237,14 +237,21 @@ function new(arg)
  -- Empty position and align in arg so we are passing deprecation warning
  arg.position = nil
  
 +-- Set default size
 +if position == left or position == right then
 +arg.width = arg.width or capi.awesome.font_height * 1.5
 +arg.height = arg.height or 100
 +else
 +arg.width = arg.width or 100
 +arg.height = arg.height or capi.awesome.font_height * 1.5
 +end
 +
  local w = capi.wibox(arg)
  
  if position == left then
  w.orientation = north
 -w:geometry({ width = capi.awesome.font_height * 1.5 })
  elseif position == right then
  w.orientation = south
 -w:geometry({ width = capi.awesome.font_height * 1.5 })
  end
  
  w.screen = arg.screen or 1
 
 Now I understand this patch. Ok.
 
 diff --git a/wibox.c b/wibox.c
 index 69009c9..a54634c 100644
 --- a/wibox.c
 +++ b/wibox.c
 @@ -488,8 +488,8 @@ luaA_wibox_new(lua_State *L)
  w-sw.border.width = luaA_getopt_number(L, 2, border_width, 0);
  w-sw.geometry.x = luaA_getopt_number(L, 2, x, 0);
  w-sw.geometry.y = luaA_getopt_number(L, 2, y, 0);
 -w-sw.geometry.width = luaA_getopt_number(L, 2, width, 100);
 -w-sw.geometry.height = luaA_getopt_number(L, 2, height, 
 globalconf.font-height * 1.5);
 +w-sw.geometry.width = luaA_getopt_number(L, 2, width, 0);
 +w-sw.geometry.height = luaA_getopt_number(L, 2, height, 0);
 
 Is that really needed? Because 0 is invalid, so it seems bad to set this
 by default.

Hm, dunno. Just skip that part of the patch, fine with me.. (yeah, you are
right, as always)

- --
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)

iQEcBAEBCAAGBQJKKrnkAAoJECLkKOvLj8sGQ+oH/RvmdOt7o9BirK0R3XnwG6Ua
weCjVX4aNObHAY5G01x3gheoZKI4dv9l/DU71C1skYJvCwfSjHYbE+wZg/k/vj6k
XLZFvjYS0t8mAd5/uO8k9NvloGWodsRH1s77SsPvt+ZJ7kE4xyW7eOIyjah2rSew
hfrOBaWZnuvGKTjfnB6AEpGVkMzfPIhETaPjjjTk6wlViJEB9veSnGj/O0g3lK4B
RoeLyZ7kj2T/lC2/TuOoqSyPNbyzNpXFqC0xcaOx4GH9DHRX34cKawRtBOmwlCeb
WdQCEBG+hq4EVtBP88ZuxzDUshj8lOr+rmZDU4/d0L2Q0vyunLDjhUOmWy2/V50=
=e/d+
-END PGP SIGNATURE-

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

[Patch] Add a scale option to awful.widget.graph

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The attached patch adds a scale option to awful.widget.graph.

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)

iQEcBAEBCAAGBQJKK7eaAAoJECLkKOvLj8sGDOsH/10vxcEcJjDtk1cPfa8kwVbG
IjUr4gf/k9MVm4aUEe4FY2pd3EFuiGMpvI+jPLHw9zIE8GjJAHUyTzLscHOCUPbC
3Fs7U0PXGAmPcx/Iz4ntI3p4TainNq4SmXVGQjpGPNMGv6aDzJOhpxcUiBHNgqkH
wWR1kthW5K6/OltLo2b9K82nI/zK972gpa7uK1DZDsq4Bu2n4WBUjynDknR1qexp
PRWZeva10ciyrBT39G7cnEEXlC9iXkZus1EJG5vfQQzMgkWw0ErfZ30nlBNkxUBQ
OVVcMXFhFkul7RiDqYTGGt/MLDB3CZHokDkChMWqFmuWje991JGT0LmkcdoQb7I=
=gsYk
-END PGP SIGNATURE-
From 300b668b29ea1224585e5f44d4734fe1492e2f67 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Sun, 7 Jun 2009 14:37:50 +0200
Subject: [PATCH] awful.widget.graph: Add scale property

If this is set to true (default is false), then the graph widget automatically
scales its content to make it fit exactly. This can be useful for graphes which
monitors things like network bandwidth which can vary a lot.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/awful/widget/graph.lua.in |   36 +---
 1 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/lib/awful/widget/graph.lua.in b/lib/awful/widget/graph.lua.in
index 656302a..79f799c 100644
--- a/lib/awful/widget/graph.lua.in
+++ b/lib/awful/widget/graph.lua.in
@@ -50,9 +50,15 @@ local data = setmetatable({}, { __mode = k })
 -- @param graph The graph.
 -- @param color The graph background color.
 
+--- Set the graph to automatically scale its values. Default is false.
+-- @name set_scale
+-- @class function
+-- @param graph The graph.
+-- @param scale A boolean value.
+
 local properties = { width, height, border_color,
  gradient_colors, gradient_angle, color,
- background_color }
+ background_color, scale }
 
 local function update(graph)
 -- Create new empty image
@@ -83,19 +89,28 @@ local function update(graph)
true, data[graph].color or red)
 end
 
+-- Find the max value to draw
+local max_value = 1
+if data[graph].scale then
+max_value = 0
+for i = 1, #values do
+if values[i]  max_value then
+max_value = values[i]
+end
+end
+end
+
 -- No value? Draw nothing.
-if #values ~= 0 then
+if max_value ~= 0 and #values ~= 0 then
 -- Draw reverse
 for i = 0, #values - 1 do
 if values[#values - i]  0 then
--- Do not draw a pixel if the value is 1
-if values[#values - i] ~= 1 then
-img:draw_line(data[graph].width - border_width - i - 1,
-  border_width + ((data[graph].height - 2 * border_width) * (1 - values[#values - i])),
-  data[graph].width - border_width - i - 1,
-  border_width,
-  data[graph].background_color or #00aa)
-end
+local value = values[#values - i] / max_value
+img:draw_line(data[graph].width - border_width - i - 1,
+  border_width + ((data[graph].height - 2 * border_width) * (1 - value)),
+  data[graph].width - border_width - i - 1,
+  border_width,
+  data[graph].background_color or #00aa)
 end
 end
 end
@@ -121,7 +136,6 @@ local function add_value(graph, value)
 if not graph then return end
 
 local value = value or 0
-value = math.min(1, math.max(0, value))
 
 table.insert(data[graph].values, value)
 
-- 
1.6.3.1

Re: [Patch] Add a scale option to awful.widget.graph

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1244379036 time_t, Uli Schlachter wrote:
 @@ -121,7 +136,6 @@ local function add_value(graph, value)
  if not graph then return end
  
  local value = value or 0
 -value = math.min(1, math.max(0, value))
  
  table.insert(data[graph].values, value)
 
 This seems useless, and potentially dangerous if scale is not set.
 No?

Hm, perhabs... update() checks for larger than or equal to 0 already, but I'm
not really sure what should be done about less than or equal to 1. Check for
'scale' in :add_value() and only do the math.min(1, value) conditionally?

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)

iQEcBAEBCAAGBQJKK/MaAAoJECLkKOvLj8sGxfMIAL1qw7oJpdaAschuQ0F+rD9/
S8k6m5Mc9NXoZeXlxeGcNnNetqgsyOrQfWK31HkYOPd4EzRevNRWFnuiBy6yQwcZ
V8cwj3SDcir6j+FBFhC9myhTr9vz/NaE0tRbyKa27+shwoV03yn2c/JK4zXpGM35
/cCqDeYPRtuuBNXskTHesrzXIW3vhYMgIyuiaySp414m6OYKALfGPea3R0rSFOFh
62uVSLf2za0E8sPu3VG4CdWhFemGvwDNuXOKsuRz9SlGwZR7UVGHfW0oiiHT+K+s
AMrRxRgDgMOAU9fWXYMX6uIvwOHu0vXTaSXC7lNfqn9TeaicshL9CwPpuILlH90=
=PKps
-END PGP SIGNATURE-

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

Re: [Patch] Add a scale option to awful.widget.graph

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1244394267 time_t, Uli Schlachter wrote:
 Hm, perhabs... update() checks for larger than or equal to 0 already, but 
 I'm
 not really sure what should be done about less than or equal to 1. Check 
 for
 'scale' in :add_value() and only do the math.min(1, value) conditionally?
 
 Actually, I wrote graph with the idea in my mind that all values should
 be between 0 and 1. That means that you always know the max value of the
 graph so you can give graph a ratio (between 0 and 1).
 
 But I wonder if this is a right choice, since there's probably some case
 where you do not know what the maximum value. I.e. you can know for a
 network interface or CPU usage, but that makes no sense if you monitor
 the number of TCP socket opened.
 
 Probably a first patch would be to fix such a limitation, and then add
 scale, which can deal with both ideas.
 
 What do you think?

Both patches attached. :)

- --
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)

iQEcBAEBCAAGBQJKLU7oAAoJECLkKOvLj8sGGfkIAJDGf5cEUoU/0J9iYAzeMOtP
rTPorj1ZL00y6G5UsQAdfJk1+8gxjr9r5IbvN9f432od8TQoMDgXo+Cxb8ideM/V
/jhelZGqKDqRvwlUVrxk6nvMHU2u/OwdLE9CA69TGru346j6DhYZgJiV4Z34vndA
g91zE8PcjFm6oji9SL0/cImJbtUadPp4JEBSq82nAavaCPYHd8nJv72kQjY0Mb64
4TQTfnSaFvrfRjuzCbiR11QCdm/ky0JY4eVWif6mA/spnI2IORIRqBuljgBUnVL3
1VjldqaCWjn0SXB7J2rHEP4XdM25W0+wLiRUdsVWOyurAIJEnuXnMFHKtZCcWSk=
=/ZCA
-END PGP SIGNATURE-
From b6c9d0503a42eb1d6bfbf537f1a47e9faba66c01 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Mon, 8 Jun 2009 19:08:49 +0200
Subject: [PATCH 1/2] awful.widget.graph: Add a max_value option

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/awful/widget/graph.lua.in |   31 +++
 1 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/lib/awful/widget/graph.lua.in b/lib/awful/widget/graph.lua.in
index 656302a..8691269 100644
--- a/lib/awful/widget/graph.lua.in
+++ b/lib/awful/widget/graph.lua.in
@@ -50,9 +50,15 @@ local data = setmetatable({}, { __mode = k })
 -- @param graph The graph.
 -- @param color The graph background color.
 
+--- Set the maximum value the graph should handle.
+-- @name set_max_value
+-- @class function
+-- @param graph The graph.
+-- @param value The value.
+
 local properties = { width, height, border_color,
  gradient_colors, gradient_angle, color,
- background_color }
+ background_color, max_value }
 
 local function update(graph)
 -- Create new empty image
@@ -67,6 +73,7 @@ local function update(graph)
 end
 
 local values = data[graph].values
+local max_value = data[graph].max_value
 
 -- Draw background
 -- Draw full gradient
@@ -87,15 +94,14 @@ local function update(graph)
 if #values ~= 0 then
 -- Draw reverse
 for i = 0, #values - 1 do
-if values[#values - i]  0 then
--- Do not draw a pixel if the value is 1
-if values[#values - i] ~= 1 then
-img:draw_line(data[graph].width - border_width - i - 1,
-  border_width + ((data[graph].height - 2 * border_width) * (1 - values[#values - i])),
-  data[graph].width - border_width - i - 1,
-  border_width,
-  data[graph].background_color or #00aa)
-end
+local value = values[#values - i]
+if value  0 then
+value = value / max_value
+img:draw_line(data[graph].width - border_width - i - 1,
+  border_width + ((data[graph].height - 2 * border_width) * (1 - value)),
+  data[graph].width - border_width - i - 1,
+  border_width,
+  data[graph].background_color or #00aa)
 end
 end
 end
@@ -121,7 +127,8 @@ local function add_value(graph, value)
 if not graph then return end
 
 local value = value or 0
-value = math.min(1, math.max(0, value))
+local max_value = data[graph].max_value
+value = math.min(max_value, math.max(0, value))
 
 table.insert(data[graph].values, value)
 
@@ -183,7 +190,7 @@ function new(args)
 local graph = {}
 graph.widget = capi.widget(args)
 
-data[graph] = { width = width, height = height, values = {} }
+data[graph] = { width = width, height = height, values = {}, max_value = 1 }
 
 -- Set methods
 graph.add_value = add_value
-- 
1.6.3.1

From b0518c386433da04b420803542f91ffc112efea5 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Mon, 8 Jun 2009 19:13:44 +0200
Subject: [PATCH 2/2] awful.widget.graph: Add

[Patch] minor simplification

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

new day - new patch

The attached patch makes it easier to see the difference between the big endian
and little endian version of this code. I haven't actually tested, but I think
that this patch doesn't have any effect on the resulting binary, since any
compiler should be intelligent enough to inline local const variables.

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)

iQEcBAEBCAAGBQJKLm/UAAoJECLkKOvLj8sGaGsH/j9P/LK4unJfYEvB06e5hkG8
ph70E42NbNFT7Y9Oah4DGj0wWQsexCxJPkoYHUl9nUh4n5jAkZZENqkkdJI3FuK1
WVvF2LlYbIIjzGlEyETOa2Bl1P52zJlGpjJN49aFeA+4oN7X4dUAkmrWPRrx6WPE
7CWNUHFNyOkxcEAH9n2b8KhS65Rw14DCLLpzeUaCEy4i6AmZ8Lysfg1YKgPeawbM
GdNFfn7nQ3JJckfSDrsK3LIw+Coihx6S8z9LGEFZCEqyaBz38OouHYDMxCYix5q+
5vTS4lKrAL9ulBB81kCbZqlFwtdbalO85eQMh4kmb56e/L6Sha4A5h5z/WdVah4=
=uUBp
-END PGP SIGNATURE-
From b03953dd34e1b27df747ba9feab393b943deb1b8 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Fri, 22 May 2009 11:22:16 +0200
Subject: [PATCH] image: Remove some code duplication

Only the indices are different between the big / little endian versions of this
loop, so just move the indices into local variables and we are done.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 image.c |   24 ++--
 1 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/image.c b/image.c
index a9d54a3..680c52d 100644
--- a/image.c
+++ b/image.c
@@ -108,6 +108,11 @@ image_getdata(image_t *image)
 uint32_t *data;
 double alpha;
 uint8_t *dataimg;
+#if AWESOME_IS_BIG_ENDIAN
+const int index_a = 0, index_r = 1, index_g = 2, index_b = 3;
+#else
+const int index_a = 3, index_r = 2, index_g = 1, index_b = 0;
+#endif
 
 if(image-isupdated)
 return image-data;
@@ -123,21 +128,12 @@ image_getdata(image_t *image)
 
 for(i = 0; i  size; i++, dataimg += 4)
 {
-#if AWESOME_IS_BIG_ENDIAN
-dataimg[0] = (data[i]  24)  0xff;   /* A */
+dataimg[index_a] = (data[i]  24)  0xff;   /* A */
 /* cairo wants pre-multiplied alpha */
-alpha = dataimg[0] / 255.0;
-dataimg[1] = ((data[i]  16)  0xff) * alpha; /* R */
-dataimg[2] = ((data[i]   8)  0xff) * alpha; /* G */
-dataimg[3] = (data[i]  0xff) * alpha; /* B */
-#else
-dataimg[3] = (data[i]  24)  0xff;   /* A */
-/* cairo wants pre-multiplied alpha */
-alpha = dataimg[3] / 255.0;
-dataimg[2] = ((data[i]  16)  0xff) * alpha; /* R */
-dataimg[1] = ((data[i]   8)  0xff) * alpha; /* G */
-dataimg[0] = (data[i]  0xff) * alpha; /* B */
-#endif
+alpha = dataimg[index_a] / 255.0;
+dataimg[index_r] = ((data[i]  16)  0xff) * alpha; /* R */
+dataimg[index_g] = ((data[i]   8)  0xff) * alpha; /* G */
+dataimg[index_b] = (data[i]  0xff) * alpha; /* B */
 }
 
 image-isupdated = true;
-- 
1.6.3.1

[Patch] High impact variable removal ;)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list,

new day - new patch ;)

I somehow noticed that draw_context's depth member is unused and can be removed.

Cheers,
psychon
- --
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)

iQEcBAEBCAAGBQJKMODCAAoJECLkKOvLj8sGbFYH/2CGltIfpCxT+ELVLWLqS20o
vPz0GzyM0hy/arDybprARe88yYzl/ql2/jzvQ6OSWFvfa/8aQCQicKorCXEcwPxs
NX+l9erzMq0WfpuySJqbrcy3BvsWd18QTXzVYLbYk21oQWDCiMHZbrcbS4L0O1Y+
px/D/+hW5dc7se1eNUwbItOtzo3dc/xRqTAvGZWIboYZTtNYDIw9JKvp3XP3rLWT
94SNt6sj80OSgVKtZ34MJCSD1fnZssVJ+mfDiaHZqzhbM/2QQRZ9w0OHIjwnOoJr
lsFp8afSBknE/Ta71luncpfBQqlyWz2pPZoNa6gBVHIw5u1ROu+Zevn7pk3VYQE=
=TIKg
-END PGP SIGNATURE-
From 3d602463e5f5c943c574f9c85b6a4d564b3099a2 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Wed, 3 Jun 2009 11:58:15 +0200
Subject: [PATCH] draw_context_t's depth member is unused, remove it

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 draw.c |1 -
 draw.h |1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/draw.c b/draw.c
index db9cdb3..bea8ece 100644
--- a/draw.c
+++ b/draw.c
@@ -204,7 +204,6 @@ draw_context_init(draw_context_t *d, int phys_screen,
 d-phys_screen = phys_screen;
 d-width = width;
 d-height = height;
-d-depth = s-root_depth;
 d-visual = draw_screen_default_visual(s);
 d-pixmap = px;
 d-surface = cairo_xcb_surface_create(globalconf.connection, px, d-visual, width, height);
diff --git a/draw.h b/draw.h
index ea74a9e..5f7c84b 100644
--- a/draw.h
+++ b/draw.h
@@ -95,7 +95,6 @@ typedef struct
 uint16_t width;
 uint16_t height;
 int phys_screen;
-uint8_t depth;
 cairo_t *cr;
 cairo_surface_t *surface;
 PangoLayout *layout;
-- 
1.6.3.1

Re: [Patch RFC] Move some code for setting certain clients above = true from C into lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1244824357 time_t, Uli Schlachter wrote:
 Hm, awful you say? This is a little hidden tin here...

 Patch attached.

 I tested that gimp's toolboxes are still above and they (sadly?) are.
 
 Should they, is the question.
 
 According to git blame, this has been added by
 cf163797782038562fed70de52f65298ba87226c without any reason for EWMH
 compliance.

Hm, I think the client_setabove(c, false); which was added in there should be
removed too, not? Oh and the commit message doesn't really git with the hunk
which this thread is above. :/

 I suggest to give a couple of test in other WM, and simply drop this
 code if we are conforming to everyone behaviour.

I only have fluxbox on this box and (without any testing, just from memory) it
doesn't do something like this.

I never read the EWMH, so could you point to the paragraph which requires this
behavior? Anyone knows some window manager where gimp's toolbox windows are
above the real image window?

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)

iQEcBAEBCAAGBQJKM1yoAAoJECLkKOvLj8sGXZ8IAKF9vhm4ssNTFCbcoATsn2J1
eLGGOKzmWf17L9p6Flm7gFW5i6bvAbmCHX8VA64hQdB5d8ISN0nnoOMcGasffIDn
pLYBNJhpATfAWTkYF9fYVPPlw1+okAsthgF2zxWCqyg5YA3quvXI8f70LpTb8D3z
JdxZ26n7Rs2SAep7eYAGKONQPs7W6d1eF+pjx4UBFaRY30gK1zorwKJdKwV6rzFB
q6AVbf6lOehQ6HMbvRWE079nSRmKKmRD9n3748BuQowDjOQDNV9E/+/wI9+bXPmB
pLWLV48fd8e6K3n/SpzSH3uwmqBLP3bUJADC3Wk8eY5LUZYIryw39ZzTVWmOV+8=
=4Uu4
-END PGP SIGNATURE-

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

Re: [Patch RFC] Move some code for setting certain clients above = true from C into lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Maarten Maathuis wrote:
 Personally i like the ability of above and below, please don't remove it.
 
 Just make it optional if you feel strongly about it.

Heh, read the diff! ;)

I'm not removing anything here, the current patch moves some behavior from the
awesome C source (where it doesnt belong IMHO) into the awful lua code (where it
does belong) which enables people to unregister the hook and thus disable this
behavior. This patch doesn't remove any features or change the default behavior.

Oh and this behavior:
When I start gimp, all of its toolbox windows are c.above = true by default
which means c:raise() on the image window doesn't have any effect at all.

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)

iQEcBAEBCAAGBQJKM3KoAAoJECLkKOvLj8sGT08IAI05cGJplxVDcmmT6IETaxm7
CVRqO5Uj7BTLcJORSKRVl1HCcfyE8s6GsrsGPVgD767CYAkyjEVRlNIwGLSOyFZI
l9WzWyTxEH92XbT9hJkHlVuX6b+1kclzIX+RlQ4XsO6v9edM7mS1uETCnwK1/LmZ
HW7DW+vSoIJMPuzOLQ+dG7QomwkhCtY2qfg1/R3aTRPPx2TmQCTGlsDT+3PKrGFk
yFWUAJV6TtLy8qfrs1yRo5C8m5W2n0YG7TYnXCEaPb6dfVuF9iR5C2ULG1JyiKfp
zlLVHcQYHaB6M3JhZ2PObpfU423WWB1H3XfPK9Zn9ZnE14Az881x+yAh8z1IKMI=
=tJs8
-END PGP SIGNATURE-

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

Re: [Patch RFC] Move some code for setting certain clients above = true from C into lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1244824357 time_t, Uli Schlachter wrote:
 Hm, awful you say? This is a little hidden tin here...

 Patch attached.

 I tested that gimp's toolboxes are still above and they (sadly?) are.
 
 Should they, is the question.
 
 According to git blame, this has been added by
 cf163797782038562fed70de52f65298ba87226c without any reason for EWMH
 compliance.
 
 I suggest to give a couple of test in other WM, and simply drop this
 code if we are conforming to everyone behaviour.

I only have fluxbox installed (which doesn't do this) and #awesome seems a
little unresponsive (I tested fluxbox, blackpenguin tested icewm, both dont do
this), so let's read EWMH instead:

Stacking order
- --

To obtain good interoperability between different Desktop Environments, the
following layered stacking order is recommended, from the bottom:

* windows of type _NET_WM_TYPE_DESKTOP
* windows having state _NET_WM_STATE_BELOW
* windows not belonging in any other layer
* windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW)
and windows having state _NET_WM_STATE_ABOVE
*focused windows having state _NET_WM_STATE_FULLSCREEN

Windows that are transient for another window should be kept above this window.

The window manager may choose to put some windows in different stacking
positions, for example to allow the user to bring currently a active window to
the top and return it back when the window looses focus.


Ok, so code in question sets the _NET_WM_STATE_ABOVE property (EWMH doesnt say
anything about the WM setting this property) on windows which are neither
normal nor desktop (which kind of fits EWMH) and which dont have a
transient_for set (hm, dunno, I guess grouping windows and their transients is
done elsewhere).

So to me this looks like EWMH doesn't really require this. Now the question:
Pushing the patch I already sent or, as jd suggests, just dropping the C code
without adding the lua side of things?

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)

iQEcBAEBCAAGBQJKNPQFAAoJECLkKOvLj8sG1aoH/3XCA6Gvx/lvQcugqafM1tAX
vEcq6TyiJhN3BrrjWFEAz0R1FbWVHsvSkD/uMWCMqSiNyy7d1edV7Bs1+gpiInRM
Xd6cOyXES0xcRQebOICDfA/etinqm9qHqDhTKnESkTmEYtEozjoRBUEn9MVjHzFw
jt67mz5FJCRrcPlYsQ7NdtCDBJuUJ1Yktj7J6bctBXstNNXxErpj1i4WRqI/eV4+
4i/Ojh9qcROZP1Ra/g8ywnIKTGDI7Z2tlcketyQkwjzZvq0g3QIiPFJaPnuD2ypZ
P+JUvmx2dtFOQs+qZPy+ozVXIc3C9Ei08F3/dKhAXau+5SxRjsoiQclOJH9Gc2w=
=T1rG
-END PGP SIGNATURE-

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

Re: lua pixmap drawing api in preparation for arbitrary shaped wiboxes

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 Julien Danjou wrote:
 At 1243673434 time_t, Uli Schlachter wrote:
 Looking at the current image lua API, I kinda doubt that it's worth to use 
 this
 for generating a 1bit pixmap. Plus, if a window is resized you pretty much 
 have
 to set a new pixmap. Everything else would look ugly or make the resize 
 pointless.
 We could adapt image API for such a case.
 
 I just looked into this again. It looks like I can't to a 1-bit depth pixmap
 with cairo which means cairo is a no-go here, so I would have to transfer the
 shape to the X server via xcb_poly_point() which sucks. E.g. for a 15x1050 
 wibox
 this would mean drawing 15.750 points. If I wanted a fullscreen wibox
 (1680x1050) with some fancy shape (a debian swirl shaped wibox? Dunno...) I
 would need 1.764.000 xcb_point_ts. I didn't do any benchmarks on this, but I
 kinda doubt that this would have nice results...

*headdesk*

I just found xcb_put_image() which sounds way more appropriate for this. I still
think that drawing directly to a pixmap would be 'better', but at least there is
an usable alternative...
- --
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)

iQEcBAEBCAAGBQJKNgbKAAoJECLkKOvLj8sG/zkH/3b1RfMOXntKR2oUecszubvz
d16Sw+Cd3ZYWuf4imTC3tgM+Zn9NzN13wy1qxwKUPwF+XEvWi5lOaFToKghEn61j
W3TiQhtGnCclZbJOtGb/PMRcc51X98dOgfliQEnbSAHCM3CAVEsnUTswSRK6XMpT
C8SYpogSOMgcPKYEz2/z40pmCvmDaFs2jkQmhtMmY1u6bvixcyLvIApPEuw6Be8R
D/okTpIcIEPdAfpWlO/I2H0e3anB7yoe/L5ssXyNBluX5zhw+ub2r/ps1BU77P/r
FmKBT/b9PeFXNvXUTz2i+xZQEhu4rq5A1GRZY12JfW2w4nzJWtXrBM2qZanFXB8=
=sZ0K
-END PGP SIGNATURE-

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

[Patch] Another high-impact patch ;)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list,

no idea how, but somehow I manage to stay with my current rate of high-impact,
totally bleeding edge, most likely broken, [insert something funkeh here] 
patches:


Today's hero in this show, Variables that the world (= awesome) doesn't need,
is globalconf::have_randr. While once imagined to result in world domination,
globalconf::have_randr (or ghr, like his friends call him) never quite managed
to meet this expectations. Over the years, people became frustrated with him and
now his days are numbered.


globalconf ghr have_randr
passed away on June 17th 2009 after long illnes.
Gone, but never forgotten.
We will miss you, little ghr.


Cheers,
Uli
(who will use lack of sleep as his defense)
- --
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)

iQEcBAEBCAAGBQJKOOxSAAoJECLkKOvLj8sGTmsH/RVwJ1Wr5tm0As+NukaZIaT7
C+jPPgva5wX4hCaDlw2a6cBJUuBgpIu2mAVJ0bcKkXRkYZsnab70p2qSgn04l4T8
N8cqCuNb20tUjxnGg3gXrPTgxq7iUHHk9ALFYIkXAd7g9NolXlnjtCJpXXEi0OfX
1ynI3ZR3gX0CuUglCW4gRD7PJl1V4UTe98KJtRJrBU4qBGai+7b+8/eu3yJEAoDO
Kpsj12kueAyZZzMbXFvyGjqjoK/6dI4cxIc4onEgCtZ/R7ctedY3RO/fX6ow/7H6
YerYEilIy2a5Ew6poZfNAvG/3AOKdDOaIZl1RSjMXexkbR49VX8Cqss8cq1D0hs=
=Y918
-END PGP SIGNATURE-
From 8adad4a7a085d38b1d00e1b06f1d233924fdf7b8 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Wed, 17 Jun 2009 14:56:24 +0200
Subject: [PATCH] Remove globalconf.have_randr

This variable didn't really have any effect on anything. It was only ever
checked in a function that would never be called if this flag was false.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 event.c   |5 +
 structs.h |2 --
 2 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/event.c b/event.c
index a21845e..7dc3a17 100644
--- a/event.c
+++ b/event.c
@@ -671,9 +671,6 @@ event_handle_randr_screen_change_notify(void *data __attribute__ ((unused)),
 xcb_connection_t *connection __attribute__ ((unused)),
 xcb_randr_screen_change_notify_event_t *ev)
 {
-if(!globalconf.have_randr)
-return -1;
-
 /* Code  of  XRRUpdateConfiguration Xlib  function  ported to  XCB
  * (only the code relevant  to RRScreenChangeNotify) as the latter
  * doesn't provide this kind of function */
@@ -810,7 +807,7 @@ void a_xcb_set_event_handlers(void)
 
 /* check for randr extension */
 randr_query = xcb_get_extension_data(globalconf.connection, xcb_randr_id);
-if((globalconf.have_randr = randr_query-present))
+if(randr_query-present)
 xcb_event_set_handler(globalconf.evenths,
   randr_query-first_event + XCB_RANDR_SCREEN_CHANGE_NOTIFY,
   (xcb_generic_event_handler_t) event_handle_randr_screen_change_notify,
diff --git a/structs.h b/structs.h
index 3a11872..4a69efa 100644
--- a/structs.h
+++ b/structs.h
@@ -73,8 +73,6 @@ struct awesome_t
 button_array_t buttons;
 /** Modifiers masks */
 uint16_t numlockmask, shiftlockmask, capslockmask, modeswitchmask;
-/** Check for XRandR extension */
-bool have_randr;
 /** Check for XTest extension */
 bool have_xtest;
 /** Clients list */
-- 
1.6.3.1

[Patch] Yes, another Really Important Thingie (tm)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I can't live without submiting a patch, the result of this OCD is attached.

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)

iQEbBAEBCAAGBQJKOnYwAAoJECLkKOvLj8sGOl8H9RB9hb0XvzoBgs77l5hn9Ann
Zj/YtQafVL46DxCcaQmibUdYX5UUnbxA97Q7ABXWqhzuoog4H/drFNj1bExrjj+x
yYNhBHnn67p0nbHcibI/liRuvZXFMmovWs0GVUnxbwmJej1jpwrS0e/OPN9V6ffU
IMKm96ji4nMFr8SVWuiRRtKu2Wbt26RsyLUi1TN1jt+x7G+xM+2Gt3Rxf8o30c1U
j8OQx7i09pag2WNA8vMOYuYSrbo3KtvM0yxUKPdDkSkOUiIK7yR+TDKbsdUItkKc
c695Boa3zv9+0JhYj1jMQ3Vt8SLMiyQEoAkvhikCFJGptcYWFO+C6++FdVGp3g==
=4Ayn
-END PGP SIGNATURE-
From 6b9b422164fb846c0b0e61575df92d7bc020620b Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Thu, 18 Jun 2009 18:33:32 +0200
Subject: [PATCH] Inline client_real_stack()

This function is only called from one place and there is no reason not
to inline it there.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 client.c |   17 ++---
 1 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/client.c b/client.c
index c2a3e08..2ad0905 100644
--- a/client.c
+++ b/client.c
@@ -372,12 +372,16 @@ client_layer_translator(client_t *c)
  * \todo It might be worth stopping to restack everyone and only stack `c'
  * relatively to the first matching in the list.
  */
-static void
-client_real_stack(void)
+void
+client_stack_refresh()
 {
 uint32_t config_win_vals[2];
 layer_t layer;
 
+if (!globalconf.client_need_stack_refresh)
+return;
+globalconf.client_need_stack_refresh = false;
+
 config_win_vals[0] = XCB_NONE;
 config_win_vals[1] = XCB_STACK_MODE_ABOVE;
 
@@ -424,15 +428,6 @@ client_real_stack(void)
 }
 }
 
-void
-client_stack_refresh()
-{
-if (!globalconf.client_need_stack_refresh)
-return;
-globalconf.client_need_stack_refresh = false;
-client_real_stack();
-}
-
 /** Manage a new client.
  * \param w The window.
  * \param wgeom Window geometry.
-- 
1.6.3.1

Fighting memleaks with valgrind - making awesome crash via lua_close()

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list,

today I took a look at valgrind's 'leak-check=full' output and thought wtf? I
gotta improve this!. As a first step I added a call to lua_close() in
awesome_atexit() which (finally?) frees the complete lua state during cleanup.

The downside of this is that awesome starts to crash during shutdown. :(
I had some fun with the example config, traced this down to awful.menu.new(),
had some more fun and came up with the attached test case which is quite minimal
(yes, this is supposed to be a complete config).

Attached are the stripped-down test case and a patch for awesome.c which adds
the lua_close() call. I hope you can help me with finding the crash bug.

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)

iQEcBAEBCAAGBQJKO3qGAAoJECLkKOvLj8sGnlIIAJlMuz0W4er6zWxD2jzVD5LL
ckLWasp/RRf6SSQmEhhA7Yd9tp9zt5gppd34VVTYNC0uwFx3K1XExBB8k0B/T/um
rWC2kcw+w0H68Oh8TDYrLfEDjjE+SRBrNtPHZA6nnJ/gbTBdmYxy7hXchstUvIZY
TE8SdULVtdTzaK8ehyqgRPiqTfrNw54jUqKL6qyPUKHtPssAddoZTm241WkjN3ME
yp+LE4hMdSwnKHda/gFHdfFOBgRkfrlBPpGUQeSKd9Uvuw5AGQ0Uk+nLTXeneBnm
VVXFrKaw0KbhnXIXQk9W3HneAhIlVpDuLMt4c7ywF6Xq3cJv/1CtoR2tfxsOoIg=
=aLTV
-END PGP SIGNATURE-
local item = wibox({})
item:buttons({button({Lock}, 1, function () end)})
item = nil

-- Here comes the magic:
-- If this call is done: no crash on lua_close().
-- If it isn't done: Kabm.
--collectgarbage(collect)

-- This has to be in the timer hook because awesome.quit() has no effect
-- during startup (does this qualify as bug?). Oh and yes, I'm having a timer
-- hook without using awful!
hooks.timer(1, function() awesome.quit() end)
diff --git a/awesome.c b/awesome.c
index 785f473..f8cc723 100644
--- a/awesome.c
+++ b/awesome.c
@@ -91,6 +91,10 @@ awesome_atexit(void)
 titlebar_client_detach(*c);
 }
 
+warn(Going down\n);
+lua_close(globalconf.L);
+globalconf.L = NULL;
+
 xcb_flush(globalconf.connection);
 
 xcb_disconnect(globalconf.connection);

Re: [Patch] SHAPE stuff *again*

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1245756208 time_t, Uli Schlachter wrote:
 +size = width * height;
 
 Seems unused.

Seems you are right.
http://git.znc.in/?p=psychon/awesome.git;a=commitdiff;h=56d73102ea8995c911664f0203f77f7a3dc0767d

 +static void
 +do_update_shape(xcb_window_t win, xcb_shape_kind_t kind, image_t *image, 
 int offset)
 +{
 +xcb_pixmap_t shape;
 +
 +if(!image)
 +{
 +/* Reset the shape */
 +shape = XCB_NONE;
 +} else {
 
 No bracket on one line please :)
 And I prefer if(image) when possible, it's just simpler.

Hm, so many different projects with so many different coding styles...
http://git.znc.in/?p=psychon/awesome.git;a=commitdiff;h=b8fe16f7153b645e0c1f22fcb5c0dcfc45454919

 +shape = image_to_1bit_pixmap(image, win);
 +}
 +
 +xcb_shape_mask(globalconf.connection, XCB_SHAPE_SO_SET, kind,
 +win, offset, offset, shape);
 
 Bad indentation.
 (Yeah, I am annoying.)

Nope, you aren't. Only three style comments, that's nothing. ;)
http://git.znc.in/?p=psychon/awesome.git;a=commitdiff;h=630019c51f846aaa5d6ad71162d9baa68d1fd100

 +local function do_rounded_corners(width, height, corner)
 +local img = image.argb32(width, height, nil)
 +
 +-- Completly transparent
 +img:draw_rectangle(0, 0, width, height, true, #ff)
 +
 +-- [[ This is the layout of the wibox:
 +----
 +--   /||\
 +--  /4| 1  |5\
 +-- |--|
 +-- |2 |
 +-- |--|
 +--  \6| 3  |7/
 +--   \||/
 +----
 +-- ]]
 +
 +-- Show the content of the wibox
 +-- 1
 +img:draw_rectangle(corner, 0, width - corner * 2, corner, true, 
 #00)
 +-- 2
 +img:draw_rectangle(0, corner, width, height - corner * 2, true, 
 #00)
 +-- 3
 +img:draw_rectangle(corner, height - corner, width - corner * 2, corner, 
 true, #00)
 +
 +-- These are the 'real' rounded corners
 +-- 4
 +img:draw_circle(corner, corner, corner, corner, true, #00)
 +-- 5
 +img:draw_circle(width - 1 - corner, corner, corner, corner, true, 
 #00)
 +-- 6
 +img:draw_circle(corner, height - 1 - corner, corner, corner, true, 
 #00)
 +-- 7
 +img:draw_circle(width - 1 - corner, height - 1 - corner, corner, 
 corner, true, #00)
 +
 +return img
 +end
 
 I find this really really... nice. :)
 Why don't you draw the opposite, i.e. simply the part you want to
 remove?

Uhm, how would I do that? I would need to do some evil math with cos and sin for
this and then loop through the single pixels...
(untested code, just now written. cos is the cosine and arcsin is the arcsine,
arguments to them are in degrees. No idea if I got the math right or if lua got
the necessary functions.)

 for i=0, corner_size do
  local w = cos(arcsin(i/corner_size*90°))
  for x=0, w do
  set pixel (i, w) to transparent)
  end
 end

Would you prefer something like this? (I bet this would make this faster, but no
idea if this is easier...)

 Otherwise, the code seems quite clean and clear, I just do not know
 anything about XShape so I can't really judge.
 I still wonder what is cliping and bounding... ? :)

Heh, second try:
If you just want an arbitrary shaped window, set the bounding shape and be done.
If you want a shaped window with a border, the clipping shape is the content
area and the bounding shape the border area and the content area together.

If this still doesn't make this clear, I'll have to start doing some screenshots
with examples which I could then add to the wiki as a start of documenting this.

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)

iQEcBAEBCAAGBQJKQNGUAAoJECLkKOvLj8sGMgYIAInH4JXAXunVT2f95qTqeVo0
q4xlXvCehqHX8PIvzNaLDJvTsN5P9sjQg88yVAY5ZUsFK2DzVrCSRetTy/ugRDCF
U4rdO+tlGwspgo4dWbvvSG08gx/qXgVkKgfTAxkTiU3LScbLgLkUumV92cE0YWCZ
c5aGNS+wDXlqn9197g0MdTdZBd76dzYPV/8IhdA3MNocaSJbcOzTqCADpxnQqjlA
LSU5ArzZbR0mr+LlCUUaMFUKEZKdAMwADT7NdqsI7L1jBwoHv+IcV4BeMdAaELgc
pwSpTd/Z+5OTjymCCZ8Ysp3K5ljUWHG5vNW5VJcVTSVv0o8i9yeaBFSufCVfy1I=
=c0am
-END PGP SIGNATURE-

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

Re: [Patch] SHAPE stuff *again*

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1245761941 time_t, Uli Schlachter wrote:
 Uhm, how would I do that? I would need to do some evil math with cos and sin 
 for
 this and then loop through the single pixels...
 
 I'm not a geometry expert but if you need to draw a top left corner:
 ++
 |1 / |
 |/ 2 |
 ++
 (1 is being transparent, 2 opaque)
 
 So you just have to draw a rectangle of tranparent and then draw part
 2 (as you do already) in opaque.
 Or do I miss something?

Hm, that's quite similar to what I am doing already, but I think your way is a
littler better. I'll implement this. :)
(And I bet this is again a little, unmeasurable bit faster :)

 Otherwise, the code seems quite clean and clear, I just do not know
 anything about XShape so I can't really judge.
 I still wonder what is cliping and bounding... ? :)
 Heh, second try:
 If you just want an arbitrary shaped window, set the bounding shape and be 
 done.
 If you want a shaped window with a border, the clipping shape is the content
 area and the bounding shape the border area and the content area together.

 If this still doesn't make this clear, I'll have to start doing some 
 screenshots
 with examples which I could then add to the wiki as a start of documenting 
 this.
 
 Would be a wonderful idea, but I think I got it, if border is what I
 think it is (a X border).

Yeah, it is. I guess I better start doing some screenshots, give me a minute (or
two)...

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)

iQEcBAEBCAAGBQJKQNm5AAoJECLkKOvLj8sGLIMH/j9w02KuiTADIKU8XkV/vHVw
CqEb0YlbYIakkGskmo6+/6g+zp7CkdXDNXiIBl8lc+iCBUtqLZkO2hpEBSOBBl2T
l8clErUNWR7i8Z3uE80J0IasiEavmXrWu7j3d4C5LaJE5ij6abK6WGIhxlbSVxLs
BEjItvvfi5soHFfLqIHLs1kzMxrum1XSMWEEpLzVExgkXQbXeXYr+SazCcR8iS/s
Ora4uimJMTsvEzjb9ivTwMMwsFk0OkRcMvJYnQyX/H2MkpV8Scu2u670uiaQr7SO
2eEE26Mzg180R+p5aR3PklfZYbhFb6BTKb75erJvC0dLvECmultWe9so1NzoHJ4=
=gXXJ
-END PGP SIGNATURE-

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

[Patch] Make window_hasproto non-blocking (was: [awesome bugs] #543 - Split window_hasproto)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

awesome wrote:
 THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
 
 A new Flyspray task has been opened.  Details are below. 
 
 User who did this - Julien Danjou (jd) 
 
 Attached to Project - awesome
 Summary - Split window_hasproto
 Task Type - Evolution Request
 Category - Core
 Status - New
 Assigned To - 
 Operating System - All
 Severity - Low
 Priority - Normal
 Reported Version - git/master
 Due in Version - Undecided
 Due Date - Undecided
 Details - window_hasproto() should be asynchronous.
 
 More information can be found at the following URL:
 http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=543
 
 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.

Hi list,

the attached patch series takes care of this. This was tested with the attached
code, gimp and xterm. With xterm valgrind generated warnings, but these are also
present in current master (and I don't understand them, accessing index 0, 2, 3
of an array is fine, but 1 is evil?)

In other news the attached test was run in xtrace and I added a warn() in
property_update_wm_protocols() which showed that this function was indeed
called. Also, the test app received client messages for WM_TAKE_FOCUS.

I hope I tested all cases...

This patch series is also available at:
 git://git.znc.in/psychon/awesome.git async_hasproto

Cheers,
Uli

P.S.: Nope, I won't reply to FS#543.
- --
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)

iQEcBAEBCAAGBQJKQnZUAAoJECLkKOvLj8sGEgIIAIROSMthhZn48vGTa/ZqsCu9
5wxZnqbQTQyvbEZT91RbaQvDYEnM+qpTt4frA+kFhe0VH+rjBDKx1tKrycOvZ+Rg
xVoQI9+tF2F0pobXw14WVyIY6UPaDjtKpUeoAwBS4lRR2G5EpkS4eY6hx0VjiV/e
7fh4x8Ni9rREdETkT0o2CpbQX9dPkepnGcYRkxEGwMXFHg9zrNCfM8v9+pw4cXhD
78+XhQIUk1J10TPBHBPTbOXdaLzlEJMghJr3xEoar1Re5aolDSv4EBy5OvXGEpog
93476UQuZpM/5FyMviMIuLJspkseMTd+nquxCJByHNMexPiCnDgPO3TFEqjOUHM=
=SIjM
-END PGP SIGNATURE-
From 5367b92bf497baa906e0c34ff2b3784a38b50a9b Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Wed, 24 Jun 2009 17:59:19 +0200
Subject: [PATCH 1/3] Add client_t::protocols

We now always know a client's WM_PROTOCOLS property without asking the X server.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 client.c   |3 +++
 client.h   |2 ++
 property.c |   40 
 property.h |1 +
 4 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/client.c b/client.c
index f1a4192..f7d6990 100644
--- a/client.c
+++ b/client.c
@@ -510,6 +510,7 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, int phys_screen,
 property_update_wm_name(c);
 property_update_wm_icon_name(c);
 property_update_wm_class(c, NULL);
+property_update_wm_protocols(c);
 
 xutil_text_prop_get(globalconf.connection, c-win, _NET_STARTUP_ID, c-startup_id, NULL);
 
@@ -1035,6 +1036,8 @@ client_unmanage(client_t *c)
 
 ewmh_update_net_client_list(c-phys_screen);
 
+p_delete(c-protocols);
+
 /* set client as invalid */
 c-invalid = true;
 
diff --git a/client.h b/client.h
index e7ac0e3..f9acdee 100644
--- a/client.h
+++ b/client.h
@@ -130,6 +130,8 @@ struct client_t
 xcb_window_t group_win;
 /** Window holding command needed to start it (session management related) */
 xcb_window_t leader_win;
+/** Client's WM_PROTOCOLS property */
+xcb_get_wm_protocols_reply_t *protocols;
 /** Client logical screen */
 screen_t *screen;
 /** Client physical screen */
diff --git a/property.c b/property.c
index b9322e1..aa4357a 100644
--- a/property.c
+++ b/property.c
@@ -365,6 +365,44 @@ property_handle_net_wm_icon(void *data,
 return 0;
 }
 
+/** Update the list of supported protocols for a client.
+ * \param c The client.
+ */
+void
+property_update_wm_protocols(client_t *c)
+{
+xcb_get_wm_protocols_reply_t protocols;
+
+if(xcb_get_wm_protocols_reply(globalconf.connection,
+  xcb_get_wm_protocols_unchecked(globalconf.connection,
+ c-win, WM_PROTOCOLS),
+  protocols, NULL))
+{
+if(c-protocols)
+xcb_get_wm_protocols_reply_wipe(c-protocols);
+else
+c-protocols = p_new(xcb_get_wm_protocols_reply_t, 1);
+
+memcpy(c-protocols, protocols, sizeof(protocols));
+}
+}
+
+static int
+property_handle_wm_protocols(void *data,
+ xcb_connection_t *connection,
+ uint8_t state,
+ xcb_window_t window,
+ xcb_atom_t name

Re: [Obvious] Pull Request: Pop-up Run Prompt Done

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrei Thorp wrote:
  - Settings to control the speed, shape and so on of the wibox
Shape?

Oh and I would propose to mark some of the variables and functions as local.
Don't ask me which ones, but at least inited looks like a candidate.

Cheers,
Uli

P.S.: Yes, I wrote this mail just because of shape. :P
- --
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)

iQEcBAEBCAAGBQJKQo5wAAoJECLkKOvLj8sGpiQH/0qLwiCgqrVPe8qDqrcTgbVn
aQF1yrnAV74nJhsiWWc+FqnG0yLAR5DLBTgzn7J53FIzQsZ3KwrPVS5OK/UvTgGe
UdmAbURHlz39OeOnamGKqYWrvTWWPsGyH3zS1fxiAE279CKx/XYw2R28qUy0kGdW
QjfbDLh+n9Ucwvuw7+yNgpDIWhJwKJcHuV8WO58stK0tZETydiE/thI95Ph5kDkA
uL9ZBgXKpl4d4WZjyMVRWP4xZ7vwBq5j6qq8/9TbBqys8G4tl1Wmca+qvcxpYxF7
Z1SboRw6JDQ7W3MRcTTN2wSuZO/4EnUZPfgAfU7smMNczC+BnC+iqHBq9p8Ra2M=
=aaHC
-END PGP SIGNATURE-

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

Re: [Obvious] Pull Request: Pop-up Run Prompt Done

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrei Thorp wrote:
 Excerpts from Uli Schlachter's message of Wed Jun 24 16:37:07 -0400 2009:
 Andrei Thorp wrote:
  - Settings to control the speed, shape and so on of the wibox
 Shape?
 
 You know, height, width, border_width. You've got too much xshape on the
 brain :)

Ah, geometry! ;)

 Oh and I would propose to mark some of the variables and functions as local.
 Don't ask me which ones, but at least inited looks like a candidate.
 
 Probably a good idea -- settings and defaults shouldn't be publically
 accessible, and neither should enforce_init either.

:)

P.S.: CC'd awesome-devel again.

- --
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)

iQEcBAEBCAAGBQJKQpRTAAoJECLkKOvLj8sGD4YIAJAQ3yO0dCNkgr/Je1ke5J/4
+G0XMNbHM1+9qWvvDhGPOHZlT+gspmIV/3Xletes5BeN7DgImA5cTy0e+jdeoUX5
SK7f/eRypcd9zaUZHskZVM01HoJewtd0Ck/xbckkxpeo8WD38Yc5rpocCKJo8nlV
0IE74Dbw1YfI431MrYF+ZzpumrhvnilLBTYwJtIkcZCCFOayfTorcYxVXyMwxAAj
LSJ6+2uleObD/SXZJz/pOZN01C9RqM3/70CRNPLor/C9bYnO9/YwiBz8zRvf2Scs
+ivlI3Wi8e3nCc/KWIZ2VhcnwJ5VhA5L+vJcvV0u7HobNdx3gb1l4LxQuGuHiV8=
=p0j2
-END PGP SIGNATURE-

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

Re: [Patch] Make window_hasproto non-blocking

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 Julien Danjou wrote:
 At 1245919316 time_t, Uli Schlachter wrote:
 So it doesn't really forbid it. ;)
 Should I use 'protocols-_reply != NULL' as a check when to
 xcb_get_wm_protocols_reply_wipe()?
 Yes.
 
 Attached are the new patches and a diff between the first version and this 
 one.
 (Ignore the lib/awful/widget/progressbar.lua.in hunk, the new version was
 rebased on master while the old one wasnt)
 
 This is also in git:
  git://git.znc.in/psychon/awesome.git async_hasproto2

Oh, I forgot:

If every single call to xcb_reply() (I keep forgetting the name...) fails,
then .._wipe() will free(NULL), since the _reply pointer was never initialized.
This is defined to be a no-op.
In every other case the wm_protocols struct will always be valid and thus the
_wipe() in client_gc (yeah, I moved it into here from unmanage) will do the
Right Thing (tm) and everyone is happy.
- --
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)

iQEcBAEBCAAGBQJKQz1iAAoJECLkKOvLj8sGwhgH/3Bhomtbtvx6sItZzlAPL2GN
oLa0PW4Y0Z2szO+codASBQAFssLlSTAyPXD7sJCUJPim4BLV8gDlg9YdpnYIs89S
Csir4GIKIXHDKz3juFWi8RQIwUrN+sivxHb8VT5g1fTHt+sNiFN+zhiF7yqmi9qT
1idxSxwtmTFkiALpg36ScBZO3BhX6tcooLAHkU0Z0p8cDWNeQEmy+amKgD1Vui94
bk+YgpY5zqhOM0BHCYso1nbEfrH02/ew5IAZC8Hqk6Hzwxb8Jmjy0sU2/ziIImJr
g+7FmAL8PEfmQB064Mwx86v+hakL2isWkFR8DAoWaNdDfHFaOfpUNJ7J5qVIyqU=
=G3wx
-END PGP SIGNATURE-

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

Re: [Draft] Introduction of Widget Layouts

[Uli Schlachter]

-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

[Uli Schlachter]

-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

[Uli Schlachter]

-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: [awesome bugs] #554 - save pointer coordinates when switching screens

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrei Thorp wrote:
 Excerpts from Uli Schlachter's message of Wed Jul 08 14:13:13 -0400 2009:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Andrei Thorp wrote:
 Excerpts from awesome's message of Wed Jul 08 13:53:50 -0400 2009:
 Details - IMHO it would be very helpful if the mouse position was saved and
 restored when switching screens (using awful.screen.focus). You almost 
 never
 want the cursor on the top left corner of the screen.
 That's a really valid point, I think.
 I use awful.screen.focus() to move the mouse pointer in the upper left 
 corner ;)
 (xautolock, if the mouse pointer is in the corner then the screen wont be
 locked)
 
 I call hax :)
 
 You should have a function to move the mouse cursor to 0,0 (or
 arbitrarily), and then focus should remember.

You win...

- --
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)

iQEcBAEBCAAGBQJKVP2DAAoJECLkKOvLj8sGwoQH/j3uNCOigntYFIs+035bIAYC
CM595igdmDHSsDDuhteSzipFNKf5rRbLQkNFk2P9/j9DEoM6wjlqSYVojzr9a2pu
93oOh9ik27ICR1seQS1bvtCERYa1bvvtvadalSWT+4I6crh19FbvwFEpl88MPv6F
FLC1lz8KKgk1DjRYSJogB1o/ofC7JX3Io5jmxxGH9zJV8X8fv3RGT0OJ94hss6yV
56pwGenQfZvFuau6RbrYQ6lvxflWaQWfU7NQUymcdM9KgfJbxmEjdNIXI8KzDgYK
FB6pMtoBQUAQKN5GUl0+pZ9KY7AXVEprrBxB8N2k3lyAhjIYxD9dlx1+9eb1vU8=
=c2B3
-END PGP SIGNATURE-

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

Re: [Draft] Introduction of Widget Layouts

[Uli Schlachter]

-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

[Uli Schlachter]

-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

[Uli Schlachter]

-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

[Uli Schlachter]

-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.

Request for icons (was: Spiral Layout)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrei Thorp wrote:
 Hello,
 
 clockwork on IRC (with really poor English) has requested that I ask
 whether someone would be interesting in writing spiral in lua for him.
 He seemed to really like it.
 
 Anyway, perhaps someone wants to do this.

Hi,

attached is the patch, have fun. ;)

Could someone create some layout icons for this? The ones from awesome 2 are...
improvable.

Apropos icons: Could we do something to clean up / unify themes/default/layouts/
and themes/sky/layouts/? Or do we really need so many different icons? That kind
of makes it a little more difficult to add new layouts...

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)

iQEcBAEBCAAGBQJKWiz9AAoJECLkKOvLj8sG2E8H/A1/L8iTQhB698GJT8l9s0jK
wSGXNrXb+fVBybqZ2/mb4lT+rhUTtDiV3jniuwWtdMLtrObsmRTgnK6JOOx+7aRQ
5htbvi35Js22M26vJzAY5G6/8k7IVf/vZ6IY2M74a7s7+ufkKyYNgy3DAJDt/BOV
gynDBYDFRnrNFYAbMVBcs0PRGRPuin8vXs6vvDnVEcIh5NK6c+TTSY5dw9PfUvL6
DKiyq+67GURDRpnSYhB/uyMtb/qb/Qm1VWiy4H2RMpx/gr5OrZPPkyrObTqdUoT5
1OJEzMPGrGpLVj8ttm9SD3tA2C+mPWR+bxWv1YRGKlZFToG+bLDkmFAPnLQHBek=
=sjBN
-END PGP SIGNATURE-
From 7c3399a71eae23077b8bbb6356769b01f1455c5b Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Sun, 12 Jul 2009 20:27:41 +0200
Subject: [PATCH] Add fibanocci layouts ported from the C version

This is based on the C code from commit b9320be372be84f8b9140fce62b77c7462490.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 awesomerc.lua.in|2 +
 lib/awful/layout/suit/init.lua.in   |1 +
 lib/awful/layout/suit/spiral.lua.in |   79 +++
 3 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 lib/awful/layout/suit/spiral.lua.in

diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 4783c2f..53ae46f 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -36,6 +36,8 @@ layouts =
 awful.layout.suit.tile.top,
 awful.layout.suit.fair,
 awful.layout.suit.fair.horizontal,
+awful.layout.suit.spiral,
+awful.layout.suit.spiral.dwindle,
 awful.layout.suit.max,
 awful.layout.suit.max.fullscreen,
 awful.layout.suit.magnifier,
diff --git a/lib/awful/layout/suit/init.lua.in b/lib/awful/layout/suit/init.lua.in
index ae83edf..d5d4e3f 100644
--- a/lib/awful/layout/suit/init.lua.in
+++ b/lib/awful/layout/suit/init.lua.in
@@ -3,6 +3,7 @@ require(awful.layout.suit.tile)
 require(awful.layout.suit.fair)
 require(awful.layout.suit.floating)
 require(awful.layout.suit.magnifier)
+require(awful.layout.suit.spiral)
 
 --- Suits for awful
 module(awful.layout.suit)
diff --git a/lib/awful/layout/suit/spiral.lua.in b/lib/awful/layout/suit/spiral.lua.in
new file mode 100644
index 000..0c00644
--- /dev/null
+++ b/lib/awful/layout/suit/spiral.lua.in
@@ -0,0 +1,79 @@
+---
+-- @author Uli Schlachter lt;psyc...@znc.ingt;
+-- @copyright 2009 Uli Schlachter
+-- @copyright 2008 Julien Danjou
+-- @release @AWESOME_VERSION@
+---
+
+-- Grab environment we need
+local ipairs = ipairs
+
+module(awful.layout.suit.spiral)
+
+local function spiral(p, dwindle)
+local wa = p.workarea
+local cls = p.clients
+
+local i = 0
+local n = #cls
+local nx = wa.x
+local ny = wa.y
+local nw = wa.width
+local nh = wa.height
+
+for k, c in ipairs(cls) do
+if (i % 2 == 1 and nh / 2  2 * c.border_width)
+  or (i % 2 == 0 and nw / 2  2 * c.border_width) then
+if i  n - 1 then
+if i % 2 == 1 then
+nh = nh / 2
+else
+nw = nw / 2
+end
+if i % 4 == 2 and not dwindle then
+nx = nx + nw
+elseif i % 4 == 3 and not dwindle then
+ny = ny + nh
+end
+end
+if i % 4 == 0 then
+if dwindle then
+ny = ny + nh
+else
+ny = ny - nh
+end
+elseif i % 4 == 1 then
+nx = nx + nw
+elseif i % 4 == 2 then
+ny = ny + nh
+elseif i % 4 == 3 then
+if dwindle then
+nx = nx + nw
+else
+nx = nx - nw
+end
+end
+if i == 0 then
+ny = wa.y
+end
+i = i + 1
+end
+local geom = { x = nx, y = ny, width = nw, height = nh }
+c:geometry(geom)
+end
+end
+
+--- Dwindle layout
+dwindle = {}
+dwindle.name = dwindle
+function dwindle.arrange(p)
+return spiral(p, true)
+end

Re: [Draft] Introduction of Widget Layouts

[Uli Schlachter]

-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.

wibox' geometry weirdness

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list,

today I noticed the following weirdness:

 w = wibox({border_width = 30, border_color = blue})
 w.screen = 1
 w:geometry({width = 90, height = 90})

The above lua snippet creates a wibox whose out border (wibox content + wibox
border) is 90x90 pixel large.

 w = wibox({border_width = 30, border_color = blue})
 w:geometry({width = 90, height = 90})
 w.screen = 1

The above lua snippet creates a wibox whose *content* is 90x90 pixel large. The
whole wibox with border seems to be 150x150 pixel large (90+2*30 = 150).

The difference is from wibox / simplewindow.

wibox_moveresize() and wibox_resize() just set the simplewindow's geometry to
its argument, while the simplewindow's version subtracts 2 times border_width
from the width and height first.

The question is now, which of these is the correct behavior?

Cheers,
Uli

P.S.: I noticed the above while debugging some naughty stuff, I guess this
naughty stuff now got to wait until later. (naughty's popup was exactly 2 times
the border_width too small which made the textbox shorten the text (Hello, this
is a...)).
- --
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)

iQEcBAEBCAAGBQJKavMaAAoJECLkKOvLj8sGeCwIAIkwcqnmv98bPQJ+0Yzj086a
jjnNWk+8vw7qVJ6bzspTx99mU/jIHe3BVYBjvOVwlTWmW+fFUW5dQTuue6NWkCu+
O32yZwFno630E0dBVTJDYP9CJaBtLrXdj++Jm457eSbVr0Kz43lV1y458udQQBSP
iG2T/E+2f6lUmTC0OZmRl1YHHX7CVPZcfyjieoFLZHZcoGaxzyfE/ts/lYrApZMX
NIsZixs3U3Gp2xMP9wg/QPaXudm5m/p0ofe2YkJ1o+xqJxD7H/zq4Kcu8ivFH8wy
O1excCHyKM3Nmj0J+DImfeiAY+tZ379OM6QqJ4274bhNKVJsKXFK92rhfrUjX0k=
=05sV
-END PGP SIGNATURE-

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

Re: [RFC Patches] SHAPE extension support for lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 Hi list,
 
 these patches implement support for the SHAPE extension.
  ^

Nope, *these* patches (damn...).

- --
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)

iQEcBAEBCAAGBQJKawJjAAoJECLkKOvLj8sGNXAH/RzavH8xBEF4XcC50VOdXAkn
LIxcYErVJr6EA8E5RXHmYQdvILZpoQeMPBFgbOfQEzKz5xHIOTZb7PJN2Ng9Z9n3
mkQiYGaMg9Dak3rKQSt29DKxswuVGmChc8V8lscOxQoGANAJy/sO0ulP58H+3cwD
fnpeFgUcTQlG3ZkV20m6ME8PQu5cGvxWhoVcSvBh+8OLtVAZC6ojnKb9UbDfU5St
qMseCSn+zdx+pe4Q0JeFwpxV6Drc8Uhd0rgBjKgnfmK7afGUqDUWXHCfypFZ8yDy
tN9dATTWamiXuHx6s255nfB4wg0YdUqLNqhIbgDTWHOrCdVAFTxd9tZr3GDqOQQ=
=xsAm
-END PGP SIGNATURE-
From b76b3b33a712a7db532fa5d090ad349d4a621834 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Thu, 18 Jun 2009 14:34:14 +0200
Subject: [PATCH 1/4] Add image_to_1bit_pixmap()

This function converts an image_t into a 1bit pixmap.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 image.c |   71 +++
 image.h |2 +
 2 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/image.c b/image.c
index a71df33..9ce840a 100644
--- a/image.c
+++ b/image.c
@@ -21,6 +21,8 @@
 
 #include structs.h
 #include common/tokenize.h
+#include common/xutil.h
+#include xcb/xcb_image.h
 
 DO_LUA_TOSTRING(image_t, image, image);
 
@@ -138,6 +140,75 @@ image_getdata(image_t *image)
 image-isupdated = true;
 
 return image-data;
+
+}
+
+static void
+image_draw_to_1bit_ximage(image_t *image, xcb_image_t *img)
+{
+uint32_t *data;
+int x, y, width, height;
+
+imlib_context_set_image(image-image);
+
+data = imlib_image_get_data_for_reading_only();
+
+width = imlib_image_get_width();
+height = imlib_image_get_height();
+
+for (y = 0; y  height; y++)
+for (x = 0; x  width; x++)
+{
+int i, pixel, tmp;
+
+i = y * width + x;
+
+// Sum up all color components ignoring alpha
+tmp  = (data[i]  16)  0xff;
+tmp += (data[i]   8)  0xff;
+tmp +=  data[i] 0xff;
+
+if (tmp / 3  127)
+pixel = 0;
+else
+pixel = 1;
+
+xcb_image_put_pixel(img, x, y, pixel);
+}
+}
+
+// Convert an image to a 1bit pixmap
+xcb_pixmap_t
+image_to_1bit_pixmap(image_t *image, xcb_drawable_t d)
+{
+xcb_pixmap_t pixmap;
+xcb_gcontext_t gc;
+xcb_image_t *img;
+uint16_t width, height;
+
+width = image_getwidth(image);
+height = image_getheight(image);
+
+/* Prepare the pixmap and gc */
+pixmap = xcb_generate_id(globalconf.connection);
+xcb_create_pixmap(globalconf.connection, 1, pixmap, d, width, height);
+
+gc = xcb_generate_id(globalconf.connection);
+xcb_create_gc(globalconf.connection, gc, pixmap, 0, NULL);
+
+/* Prepare the image */
+img = xcb_image_create_native(globalconf.connection, width, height,
+XCB_IMAGE_FORMAT_XY_BITMAP, 1, NULL, 0, NULL);
+image_draw_to_1bit_ximage(image, img);
+
+/* Paint the image to the pixmap */
+xcb_image_put(globalconf.connection, pixmap, gc, img, 0, 0, 0);
+
+xcb_free_gc(globalconf.connection, gc);
+
+xcb_image_destroy(img);
+
+return pixmap;
 }
 
 /** Create a new image from ARGB32 data.
diff --git a/image.h b/image.h
index a9acd93..1df544c 100644
--- a/image.h
+++ b/image.h
@@ -46,5 +46,7 @@ uint8_t * image_getdata(image_t *);
 int image_getwidth(image_t *);
 int image_getheight(image_t *);
 
+xcb_pixmap_t image_to_1bit_pixmap(image_t *, xcb_drawable_t);
+
 #endif
 // vim: filetype=c:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
-- 
1.6.3.3

From 88f058f57eba8cb01e95a35a9a495afab37b0023 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Tue, 23 Jun 2009 12:55:50 +0200
Subject: [PATCH 2/4] Add a lua api for setting a wibox' shape

When the SHAPE extension is not available, this code prints
a harmless warn() on stderr.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 awesomeConfig.cmake   |1 +
 common/tokenize.gperf |2 +
 swindow.c |   57 +
 swindow.h |9 +++
 wibox.c   |   25 +
 wibox.h   |2 +
 6 files changed, 96 insertions(+), 0 deletions(-)

diff --git a/awesomeConfig.cmake b/awesomeConfig.cmake
index 6d2e9a4..eeb263c 100644
--- a/awesomeConfig.cmake
+++ b/awesomeConfig.cmake
@@ -139,6 +139,7 @@ pkg_check_modules(AWESOME_REQUIRED REQUIRED
 xcb-randr
 xcb-xtest
 xcb-xinerama
+xcb-shape
 xcb-event=0.3.4
 xcb-aux=0.3.0
 xcb-atom=0.3.0
diff --git a/common/tokenize.gperf b/common/tokenize.gperf
index 8713fdd..afe36af 100644
--- a/common/tokenize.gperf

Re: [RFC Patches] SHAPE extension support for lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gregor Best wrote:
 On Sat, Jul 25, 2009 at 02:58:58PM +0200, Uli Schlachter wrote:
 [...]
 I'm not sure if this code is ready to go in. E.g. there is no way to check if
 the SHAPE extension is available for lua code. Would we need something like
 this? What would this API look like.
 [...]
 
 I'd say we shouldn't export that to Lua at all. Simply check for the
 shape extension on startup, set a flag in globalconf (something like
 have_shape) and if that's not set in the shape functions, simply ignore
 shape requests.

Currently it kind-of ignores shape requests, too. That is, it allows setting a
wibox shape but that doesnt actually have any effect...

If we simply ignore shape requests, then one could detect shape support in lua
by setting a shape and then checking if that shape is nil or an actual image.
Sounds hacky to me. :/

I just thought about this:
We can add an official way for checking for shape support (awesome.have_xshape?
Dunno, sounds bad... ideas?) and then lua_error() when someone tries to set a 
shape.

Hm...

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)

iQEcBAEBCAAGBQJKazbgAAoJECLkKOvLj8sGWcgH/RVTasF4GfZ765WIqYjKKgQu
rHB+2a2vs3mLa0/IGsgynapIjfpmuVZ9LH0n/P1bCyCW1xQb6Eu3catQYpGoL6KO
E9HU8sxQYj6Er6L/UC8PREL/O85gBHqOTwfTlk8WdOvNAbkc8+q50byEZ+D8Fqdi
4Vf/qt0tbyWLaz5A8bt8dRfN7eG4lGq9/O/JJe1Q39yf18HevnclYJUNLnJQv9RV
V7z+roRuOBDSfwqS4UCyjohdq1AVJKyM05c5HivUIbCLNamZ7Rd7Oj7Qe//KLnzd
HDiyWlJxYJsACM1qpHil5DCNgaPqDtgx5PNCi79DDowZ9zTYLB01PmK+nSyWF1I=
=+EK7
-END PGP SIGNATURE-

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

Re: [RFC Patches] SHAPE extension support for lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1248526949 time_t, Uli Schlachter wrote:
 +// Convert an image to a 1bit pixmap
 +xcb_pixmap_t
 +image_to_1bit_pixmap(image_t *image, xcb_drawable_t d)
 +{
 +xcb_pixmap_t pixmap;
 +xcb_gcontext_t gc;
 +xcb_image_t *img;
 +uint16_t width, height;
 +
 +width = image_getwidth(image);
 +height = image_getheight(image);
 +
 +/* Prepare the pixmap and gc */
 +pixmap = xcb_generate_id(globalconf.connection);
 +xcb_create_pixmap(globalconf.connection, 1, pixmap, d, width, height);
 +
 +gc = xcb_generate_id(globalconf.connection);
 +xcb_create_gc(globalconf.connection, gc, pixmap, 0, NULL);
 +
 +/* Prepare the image */
 +img = xcb_image_create_native(globalconf.connection, width, height,
 +XCB_IMAGE_FORMAT_XY_BITMAP, 1, NULL, 0, NULL);
 +image_draw_to_1bit_ximage(image, img);
 +
 +/* Paint the image to the pixmap */
 +xcb_image_put(globalconf.connection, pixmap, gc, img, 0, 0, 0);
 +
 +xcb_free_gc(globalconf.connection, gc);
 +
 +xcb_image_destroy(img);
 +
 +return pixmap;
  }
 
 Suggestion: is there a way you can create one and only one GC for all
 painting, definiting it static in that .c file? This would avoid some
 X requests.
 
 The rest seems ok to me.
 
 Cheers,

  static xcb_gcontext_t gc = XCB_NONE;
  if (gc == XCB_NONE)
  { insert create_gc stuff from above }

That seems to be possible, but:
   xcb_create_gc(globalconf.connection, gc, pixmap, 0, NULL);
The create_gc call takes the pixmap as an argument. I can't do much testing atm,
but will this break if the gc is used on a different drawable later on?

man XCreateGC says that The GC can be used with any destination drawable
having the same root and depth as the specified drawable. What is the root of a
pixmap? If it's the root of the window, then I can't use one GC for everything,
because that would break without xinerama, right? (No xinerama == multiple root
windows, one per screen).

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)

iQEcBAEBCAAGBQJKbXVFAAoJECLkKOvLj8sGxA4H/2NL9bZczogf/gxQwpOxHo4o
JChlVysueGNI2YOcGUYOsAx1ypO3klPaUYMcf7o6iwTwF6xV6igFRe2aGS8QOD+M
CKVa4rzHHIqyC4QB4SMQChhFVz5DMKRoZt1eW4dbtqSAWktEFJUSKRKfjOXfOo1Y
tzDmV7rrVz2BJ4FegRe4EATBYQk0uQOCU4N1xARG9aHv06h7aVitH9b/Eid/BWO8
cwOSDU7jdBvgvvLDnfsMsjvPPSAZixDkjMsCF4RwxaahFdgwJPlgSaDUn9163lyL
JYTIiZj2eW1YPrFSRa+QdgbISFBxfxBhq5Vx/s+PfwNn8/60JawspA0wvI8IyTM=
=lkPR
-END PGP SIGNATURE-

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

Re: [RFC Patches] SHAPE extension support for lua

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien Danjou wrote:
 At 1248687430 time_t, Uli Schlachter wrote:
 man XCreateGC says that The GC can be used with any destination drawable
 having the same root and depth as the specified drawable. What is the root 
 of a
 pixmap? If it's the root of the window, then I can't use one GC for 
 everything,
 because that would break without xinerama, right? (No xinerama == multiple 
 root
 windows, one per screen).
 
 I understand the same thing.
 So let it go. I think it's ok like that.
 I don't have time to test your patch *right now*, will do this
 afternoon. If it's ok for you (and me), I'll merge them.

No hurry, take your time.
Oh and yeah, feel free to merge them, but don't merge patch 4, plese. :)

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)

iQEcBAEBCAAGBQJKbX/IAAoJECLkKOvLj8sGclYH/jOpu7TIxlaMwnqOr4EIg+gl
pWvl8ko899OMz7hcQoDb4iT2qKClou6cHk69f3/6N4fFislQDcUGDiP932N7Rntn
lSO28jcyjgbjMNtJlG+FXbByPwe38WOUlfLTD+D0498L5nxVLuLpPcoNqarItXKW
FG8S89jRvtRhtSbJjfN1EyW374lhpTjNmuaVzrSRM+9g57WIT4rL+Oi5TbysZ1I7
2LimnLNE5EKIHnp2Tojv4+BwNOJernZoMPTlYl0If9BGH76yAAPtYc23rZbPNY/i
QNYttioGBLREdkq6FVM4H5jDbllrpUXCdAMo0rf9ZqafjIFDDwQI1dPwgkSGmRg=
=PboA
-END PGP SIGNATURE-

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

[Patch] Fix naughty's margin calculation

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

no idea when this break, but the attached patch fixes it (for me).
Tested with notify-sent, with and without an icon.

Oh and I'm working on a follow-up patch for this, the width calculation looks a
little fishy.

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)

iQEcBAEBCAAGBQJKcENjAAoJECLkKOvLj8sGxCEH/iBEw+LSi7t7P/ny3/EWb7w/
4kzANhmFVd4xUm+IRDVhPpMcacY28zBvndRd6zUn9Eixi8hOMGbgMzivgvnCe+ir
HceFML+OWvb3cijrfeVeb4wcSQueHWxAVFb3+nG9HgNXOccqbHG1qOVqgA7ilCQ4
O6DfGxx1duADb4ercF55dq6qi+gXhaNanrBCuKhyQtjhVu129QgQmaV1TQllA1DH
W7CSe+TiS+G9arwaaQH67c6Q5x/V6Nhetb/jzQiTtaehcMCGnUrTtnYFaBgTyTy8
pUDwPQnF8nmyLZY07mQT5Ej35ic18DguobfS5+aJSrALcKkV0J/qjrgIuqSmFlA=
=N6Fn
-END PGP SIGNATURE-
From 8e866ba152eca6a4d1a784df2a4fb804d33f81e4 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Wed, 29 Jul 2009 14:37:23 +0200
Subject: [PATCH] Naughty: Fix the text margin

No idea where this comes from or why it worked before, but it's obviously wrong.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/naughty.lua.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/naughty.lua.in b/lib/naughty.lua.in
index c13cca7..ad02149 100644
--- a/lib/naughty.lua.in
+++ b/lib/naughty.lua.in
@@ -313,7 +313,7 @@ function notify(args)
 -- create textbox
 local textbox = capi.widget({ type = textbox, align = flex })
 textbox.buttons = util.table.join(button({ }, 1, run), button({ }, 3, die))
-textbox:margin({ right = margin, left = margin, bottom = 2 * margin })
+textbox:margin({ right = margin, left = margin, bottom = margin, top = margin })
 textbox.text = string.format('span font_desc=%sb%s/b%s/span', font, title, text)
 if hover_timeout then textbox.mouse_enter = hover_destroy end
 
-- 
1.6.3.3

[Patch] Some more naughty fixage

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Damn, that went faster than I had expected

Commit message should say it all, read it!

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)

iQEcBAEBCAAGBQJKcETGAAoJECLkKOvLj8sGWjUH/jyDAMC+JvcOzX+ZLfd8Ta0c
jfQgkF/AK4bFkf1Ngl2iR8pb2/+zVaW+1LioMBbahUxdmRq8e+rvCKvPNq2Qajb0
CDOlLH1g3zbT3lBfHhMu3CwI11JNX+2TnN7DvG53Z4HDBUcY+BFNaCog9x+z5xfz
snCyxk4ZLfY+bW5VbPwt044N+CyDwkQVMImyvjMO12ZbRE2dfJIyi5HUeprd3OAP
70eznzci5WwaWKPMoLJmBOKKHrlglU64CC07lcDNzSRMmjt/9WJKO31b9/MuRW6W
38eP5fDmXY5P7H6AJyAbnv/JHWUcMVhDghh9spbGLJyAOEzX8rRq0kh4FJxQfg8=
=tiDR
-END PGP SIGNATURE-
From 649b434e8a6b042cc81b041e39488bd06884e51b Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Wed, 29 Jul 2009 14:43:00 +0200
Subject: [PATCH] Naughty: Remove some code duplication

2b69d333f8d4e2770da added some code duplication here. I guess this was a
mis-rebase or something like that. Anyway, the width and height of the wibox is
already calculated right before this code snippet and the existing calculation
is even correct (now that the calculation for a wibox' geometry with
border_width was fixed up).

Tested via notify-send with and without icon.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/naughty.lua.in |   20 +++-
 1 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/lib/naughty.lua.in b/lib/naughty.lua.in
index ad02149..b4feb06 100644
--- a/lib/naughty.lua.in
+++ b/lib/naughty.lua.in
@@ -379,24 +379,10 @@ function notify(args)
 notification.width = width + 2 * (border_width or 0)
 
 -- position the wibox
-if iconbox and iconbox.image.height  textbox:extents()[height] then
-notification.height = iconbox.image.height + (2 * config.border_width)
-else
-notification.height = textbox:extents()[height] + (2 * config.border_width)
-end
-notification.width = (iconbox and iconbox:extents()[width] or 0) + textbox:extents()[width] + (2 * config.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)
-end
-if capi.screen[screen].workarea.height  notification.height then
-notification.height = capi.screen[screen].workarea.height - (2 * config.border_width) - (2 * config.padding)
-end
-
-local offset = get_offset(screen, notification.position, notification.idx, notification.width, notification.height)
+local offset = get_offset(screen, notification.position, nil, notification.width, notification.height)
 notification.box.ontop = ontop
-notification.box:geometry({ width = notification.width,
-height = notification.height,
+notification.box:geometry({ width = width,
+height = height,
 x = offset.x,
 y = offset.y })
 notification.box.opacity = opacity
-- 
1.6.3.3

Re: [Obvious] Next branch patches (for easy review)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 Andrei Thorp wrote:
 I wanna get my patches reviewed dammit ;)
 
 Ok, here we go:
 
 Subject: [PATCH 1/4] Lib: hooks lib w/ awful timer wrapper functions
 [...]
 diff --git a/lib/hooks/init.lua b/lib/hooks/init.lua
 new file mode 100644
 index 000..ec94102
 --- /dev/null
 +++ b/lib/hooks/init.lua
 [...]
 +-- Register a timer just as you would with awful.hooks.timer.register, but
 +-- with one slight twist: you set your regular speed, (optionally) your slow
 +-- speed, and then your function.
 +-- @param reg_time Regular speed for the widget
 +-- @param slow_time Slow time for the widget
 +-- @param fn The function that the timer should call
 +-- @param descr The description of this function
 +function timer.register(reg_time, slow_time, fn, descr)
 +if not slow_time then slow_time = reg_time * 4 end
 +registry[fn] = {
 +regular=reg_time,
 +slow=slow_time,
 +speed=regular,
 +running=true,
 +description=descr or Undescribed timer
 +}
 +timer.set_speed(registry[fn].speed, fn)
 +end
 
 [...] (BTW, is slow_time being nil handled anywhere?)

Ah, found it. I'd propose to move this into set_speed().

if want_slow_spped() then
local speed = v.slow or 4 * (v.regular or 42)
else
local speed = v.reguler or 42
end

(where 42 is a global config variable that the user can mess with)

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)

iQEcBAEBCAAGBQJKcYjdAAoJECLkKOvLj8sGCyIH/3KdKYXXCYZiRq2fniNbAxBG
V9+Fp7phweJaVMzwexLT4OsCqnHbnpzzTBINqnjQ2ftx1/KEPniJk7eHOT8v9U8h
iUE4f+vKLCxnVD8b7UXrNgKOVBM6BTAQXt26XSmTrDvWLWbEY3Gh8hGSTKTrw1rS
AneKdyXe3VxnwdNyIxHxZHS2GAUeaLK+KTXzu9XlTgqD+9X5jvhSbb8bE6Oltvda
KXxmcsYwHR2r4r2SoU/vtSpKA/9uv8SCOtGR0G086SYw4dcdkY9J7i0x2qiLwmOK
GJ5xH1hqFVfnUydawtojh3+n7vm7PvrIH3wvPP+EUStDGJZillDYTr7v8IjjhUA=
=FRDl
-END PGP SIGNATURE-

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

Re: [Obvious] Next branch patches (for easy review)

[Uli Schlachter]

Andrei Thorp wrote:
 Subject: [PATCH 2/4] Lib/Util: Added bold  colour functions
 diff --git a/lib/util/init.lua b/lib/util/init.lua
 new file mode 100644
 index 000..6360f87
 --- /dev/null
 +++ b/lib/util/init.lua
 @@ -0,0 +1,21 @@
 +--
 +-- Author: Andrei Garoth Thorp--
 +-- Copyright 2009 Andrei Garoth Thorp --
 +--
 +module(obvious.lib.util)
 +
 +-- Set Foreground colour of text
 +-- @param colour The colour you want to set the text to
 +-- @param text The text you want to colour
 +-- @return The coloured string
 +function colour(colour, text)
 +return 'span color=' .. colour .. '' .. text .. '/span'
 +end
 +
 +-- Make bold text
 +-- @param text The text you want to make bold
 +-- @return The bolded text
 +function bold(text)
 +return 'b' .. text .. '/b'
 +end
 +-- vim: 
 filetype=lua:expandtab:shiftwidth=4:tabstop=4:softtabstop=4:encoding=utf-8:textwidth=80

Looks good I guess. But | can do better[1] (This is based on some code that |
nopasted and i tweaked it a little, oh and who needs luadoc anyway? ;) ).

Uli

[1]
http://git.znc.in/?p=psychon/dotfiles.git;a=blob;f=config/awesome/markup.lua;hb=HEAD

-- 
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451

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

Re: [Obvious] Next branch patches (for easy review)

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrei Thorp wrote:
 Excerpts from Uli Schlachter's message of Thu Jul 30 09:43:46 -0400 2009:
 Andrei Thorp wrote:
 @@ -97,25 +113,33 @@ function show_wibox(s)
  })
  runwibox[s].visible = true
  
 -f = function ()
 -startgeom = runwibox[s]:geometry()
 -runwibox[s]:geometry({
 -y = startgeom.y - settings.move_amount,
 -})
 -if runwibox[s]:geometry().y = screen[s].geometry.y +
 -screen[s].geometry.height - startgeom.height then
 -set_default(mouse.screen)
 -awful.hooks.timer.unregister(f)
 -end
 +if lib.hooks.timer.has(do_slide_up) then
 +lib.hooks.timer.start(do_slide_up)
 +else
 +lib.hooks.timer.register(settings.move_speed,
 + settings.move_speed*3,
 + do_slide_up,
 + popup_run_prompt slide up)
  end
 -
 -awful.hooks.timer.register(settings.move_speed, f)
 I like the old code better which unregisters the timer when it's no longer
 needed (or at least get rid of that lib.hooks.timer.has() call somehow).
 
 I'll probably register the timer elsewhere and just pause it right away
 then.
 
 Fixes to Timers pushed.

Care to send the fix for review? *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)

iQEcBAEBCAAGBQJKcdB2AAoJECLkKOvLj8sGkrIIAMNpb3VOjxQOjwjoKrGz3pzC
kp0tL0t8K/hwL43UjtAKW4oekkkXwjdnkkfkfwRpAbBA/l8CcP2ZEhrAr7GSS7IJ
Ae97UXAamReK6qudv7QGCUiyafdHP9/GD0F81QNGp4e/QUTQlsYgxaPpiSJGA1xr
M8jJL9rIIGorQNiqxAQT7zjDyZQ6oqgYM3E+QSWRTpGpMYZOCU0yAJlKfrOdTg24
2/jSqezUAWvd8VPK+t8yJfvJwYjeJg3UDys5o0duAlG3NsBKhvpxlnLrsLU51AyT
8WGmfi/lWlKoeuHlLX3+k0yfALr5RhienCYnLO5fhr+DHfdOrogFmeuhoVc20Xg=
=5Q4G
-END PGP SIGNATURE-

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

[Patch Obvious] High impact code rewrite, again

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list,

I was recently forced to use obvious. Well, you wanted it that way. So far I
only looked at obvious.wlan and noticed that your code looks almost like mine.
Obviously, mine's a little better and I wanted to share...

Enough bla, I tested this and it Works For Me (tm).

Uli

P.S.: GPLv2 :P
- --
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)

iQEcBAEBCAAGBQJKdI/OAAoJECLkKOvLj8sGQG0IALR5lD5vzll/RoHcA37szCo3
mUb2MUD0aVIty1+LGG1aRCxgc49u/0WhlmFrKQmhiXnRGaM5Vvf5Qw6Npvle6AwR
O4Ww0khLjoqVnzYHszXqa1UWiSkN+cmR8+Z/3iQOp+CpRRK1KQLrj06ZmgXQa656
Qh0q1Ourk5IZDCzQ2odYZ2LukGlPtPssZUeaHiAHJIM2FzxYYxeXZTQg2LUqGrIx
RMS1rNJr1kiw24vY1zdk6DwOFPwJ9pK6BFfYNtn+tfhASOuKfBqtWrXTeN3gvpIC
61GAXD1WtO2YTMAvskEauHYdKyPAYgfefrAWYrAClHR+S7DOAiaXR9cF32+wQpk=
=TN35
-END PGP SIGNATURE-
From aaf7a74b93efcc7598bb278f1b5418e9d3a60fc6 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Sat, 1 Aug 2009 20:50:06 +0200
Subject: [PATCH] obvious.wlan: Minor cleanup

This patch applies some minor code prettification (=makes the code prettier).

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 wlan/init.lua |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/wlan/init.lua b/wlan/init.lua
index eb70afa..27b0eff 100644
--- a/wlan/init.lua
+++ b/wlan/init.lua
@@ -32,10 +32,7 @@ function get_data()
 local fd = io.open(/proc/net/wireless)
 if not fd then return end
 
-while true do
-local line = fd:read(*l)
-if not line then break end
-
+for line in fd:lines() do
 if line:match(^ ..device) then
 rv.link = tonumber(line:match(   (%d?%d?%d)))
 break
-- 
1.6.3.3

[Obvious RFC Patches] Add the concept of data sources

[Uli Schlachter]

Hi list,

if you don't use obvious stop here.

This patch series adds the concept of general data sources to obvious. This
splits the widget-part from the collect-data-about-the-system-part. Any data
source is a table with two entries:

local data = {
   max = the maximum value get() can return, if nil then there is no limit
   get = a method that is called when we need a new value for a widget
}

The code calls data:get(), not data.get(), so data sources can add additional
fields to the table. The wlan data source uses this for the interface name.

Oh and yes, data sources can only return numerical values. Anything else doesn't
really make sense IMHO.

Opinions? Should I add more of these or is it better to stop trying?

The file-layout might be sub-optimal (thinking about it, obvious.widget belongs
into obvious.lib etc.), but I like the general idea.

@farhaven:
Feel free to shuffle this stuff around, I did this in a free minute at work
without much thinking about it. Critique welcome.

Uli
- --
Do you know that books smell like nutmeg or some spice from a foreign land?
  -- Faber in Fahrenheit 451
From b0ebfcd37a9dd64d7cd7209d8630dfad9e52bcb6 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Wed, 5 Aug 2009 16:24:13 +0200
Subject: [PATCH 1/3] Add the concept of data sources

obvious.data.* are supposed to be a collection of general data sources. Via
obvious.widget.progressbar() one can turn one of them into a widget and add that
to the statusbar.

For example: obvious.widget.progressbar(obvious.data.wlan(wlan0))

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 data/init.lua   |   10 
 data/wlan.lua   |   44 +++
 init.lua|3 +-
 lib/init.lua|3 +-
 lib/{widgets.lua = widget.lua} |2 +-
 lib/wlan.lua|   30 --
 widget/init.lua |   28 
 wlan/init.lua   |3 +-
 8 files changed, 88 insertions(+), 35 deletions(-)
 create mode 100644 data/init.lua
 create mode 100644 data/wlan.lua
 rename lib/{widgets.lua = widget.lua} (97%)
 delete mode 100644 lib/wlan.lua
 create mode 100644 widget/init.lua

diff --git a/data/init.lua b/data/init.lua
new file mode 100644
index 000..4379583
--- /dev/null
+++ b/data/init.lua
@@ -0,0 +1,10 @@
+---
+-- Author: Uli Schlachter--
+-- Copyright 2009 Uli Schlachter --
+---
+
+require(obvious.data.wlan)
+
+module(obvious.data)
+
+-- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=4:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/data/wlan.lua b/data/wlan.lua
new file mode 100644
index 000..d366efa
--- /dev/null
+++ b/data/wlan.lua
@@ -0,0 +1,44 @@
+
+-- Author: Gregor Best--
+-- Copyright 2009 Gregor Best --
+
+
+local tonumber = tonumber
+local setmetatable = setmetatable
+local io = {
+open = io.open
+}
+
+module(obvious.data.wlan)
+
+local function get_data(device)
+local link
+local fd = io.open(/proc/net/wireless)
+if not fd then return end
+
+for line in fd:lines() do
+if line:match(^ ..device) then
+link = tonumber(line:match(   (%d?%d?%d)))
+break
+end
+end
+fd:close()
+
+return link
+end
+
+local function get_data_source(device)
+local device = device or wlan0
+local ret = {}
+
+ret.device = device
+ret.max = 100
+ret.get = function (obj)
+return get_data(obj.device)
+end
+
+return ret
+end
+
+setmetatable(_M, { __call = function (_, ...) return get_data_source(...) end })
+-- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=4:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/init.lua b/init.lua
index 2474541..e157b63 100644
--- a/init.lua
+++ b/init.lua
@@ -4,12 +4,13 @@
 ---
 
 require(obvious.lib)
+require(obvious.data)
 require(obvious.clock)
 require(obvious.battery)
 require(obvious.volume_alsa)
 require(obvious.wlan)
-require(obvious.wlan.bar)
 require(obvious.popup_run_prompt)
 require(obvious.basic_mpd)
+require(obvious.widget)
 
 module(obvious)
diff --git a/lib/init.lua b/lib/init.lua
index 31fe374..c7377c6 100644
--- a/lib/init.lua
+++ b/lib/init.lua
@@ -5,9 +5,8 @@
 
 require(obvious.lib.hooks)
 require(obvious.lib.util)
-require(obvious.lib.widgets)
+require(obvious.lib.widget)
 require(obvious.lib.mpd)
-require(obvious.lib.wlan)
 
 module(obvious.lib)
 -- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=4:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/lib/widgets.lua b/lib/widget.lua
similarity index 97%
rename from lib/widgets.lua
rename to lib/widget.lua
index 40f73c2..9a54404 100644
--- a/lib/widgets.lua
+++ b/lib/widget.lua
@@ -8,7 +8,7 @@ local

Re: [Obvious RFC Patches] Add the concept of data sources

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 Hi list,
 
 if you don't use obvious stop here.
 
 This patch series adds the concept of general data sources to obvious. This
 splits the widget-part from the collect-data-about-the-system-part. Any data
 source is a table with two entries:

Whoops, some debugging code left in (timer fires each second instead of every
10 seconds).

New stuff attached

- --
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)

iQEcBAEBCAAGBQJKeZztAAoJECLkKOvLj8sGbdkH+gOD5IHVtWyX+Ni1cwkXNzL2
+rEgjFZqNUef58vF0BSV2+URbmUz6DRoVmDM2kRe/TRpklLOt7NMD956Fl0rcn7h
6jppJ46//+25/aEu4OwQ8de516OqWE+yNhbsCdBIhU7wC668QJJZscTh/8VjnXQZ
rhbAfADYisumWcMo04Nc/KCSr9vHQiQRB4Rue8fQX/AddJXP4yq8nNX8bRbISGn+
x4G1C2TDenEwDGb86sklyRjn0UOA1jxur7ww2VJ7hnftSItKviyX8gOyYyvLoHRJ
ijwBcvQs6UPC5uYPVfEwq8ZIQeoM6eIGGo34m8alVcHYmFLseDiboYikIv9p69s=
=N/K+
-END PGP SIGNATURE-
From b0ebfcd37a9dd64d7cd7209d8630dfad9e52bcb6 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Wed, 5 Aug 2009 16:24:13 +0200
Subject: [PATCH 1/3] Add the concept of data sources

obvious.data.* are supposed to be a collection of general data sources. Via
obvious.widget.progressbar() one can turn one of them into a widget and add that
to the statusbar.

For example: obvious.widget.progressbar(obvious.data.wlan(wlan0))

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 data/init.lua   |   10 
 data/wlan.lua   |   44 +++
 init.lua|3 +-
 lib/init.lua|3 +-
 lib/{widgets.lua = widget.lua} |2 +-
 lib/wlan.lua|   30 --
 widget/init.lua |   28 
 wlan/init.lua   |3 +-
 8 files changed, 88 insertions(+), 35 deletions(-)
 create mode 100644 data/init.lua
 create mode 100644 data/wlan.lua
 rename lib/{widgets.lua = widget.lua} (97%)
 delete mode 100644 lib/wlan.lua
 create mode 100644 widget/init.lua

diff --git a/data/init.lua b/data/init.lua
new file mode 100644
index 000..4379583
--- /dev/null
+++ b/data/init.lua
@@ -0,0 +1,10 @@
+---
+-- Author: Uli Schlachter--
+-- Copyright 2009 Uli Schlachter --
+---
+
+require(obvious.data.wlan)
+
+module(obvious.data)
+
+-- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=4:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/data/wlan.lua b/data/wlan.lua
new file mode 100644
index 000..d366efa
--- /dev/null
+++ b/data/wlan.lua
@@ -0,0 +1,44 @@
+
+-- Author: Gregor Best--
+-- Copyright 2009 Gregor Best --
+
+
+local tonumber = tonumber
+local setmetatable = setmetatable
+local io = {
+open = io.open
+}
+
+module(obvious.data.wlan)
+
+local function get_data(device)
+local link
+local fd = io.open(/proc/net/wireless)
+if not fd then return end
+
+for line in fd:lines() do
+if line:match(^ ..device) then
+link = tonumber(line:match(   (%d?%d?%d)))
+break
+end
+end
+fd:close()
+
+return link
+end
+
+local function get_data_source(device)
+local device = device or wlan0
+local ret = {}
+
+ret.device = device
+ret.max = 100
+ret.get = function (obj)
+return get_data(obj.device)
+end
+
+return ret
+end
+
+setmetatable(_M, { __call = function (_, ...) return get_data_source(...) end })
+-- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=4:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/init.lua b/init.lua
index 2474541..e157b63 100644
--- a/init.lua
+++ b/init.lua
@@ -4,12 +4,13 @@
 ---
 
 require(obvious.lib)
+require(obvious.data)
 require(obvious.clock)
 require(obvious.battery)
 require(obvious.volume_alsa)
 require(obvious.wlan)
-require(obvious.wlan.bar)
 require(obvious.popup_run_prompt)
 require(obvious.basic_mpd)
+require(obvious.widget)
 
 module(obvious)
diff --git a/lib/init.lua b/lib/init.lua
index 31fe374..c7377c6 100644
--- a/lib/init.lua
+++ b/lib/init.lua
@@ -5,9 +5,8 @@
 
 require(obvious.lib.hooks)
 require(obvious.lib.util)
-require(obvious.lib.widgets)
+require(obvious.lib.widget)
 require(obvious.lib.mpd)
-require(obvious.lib.wlan)
 
 module(obvious.lib)
 -- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=4:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/lib/widgets.lua b/lib/widget.lua
similarity index 97%
rename from lib/widgets.lua
rename to lib/widget.lua
index 40f73c2..9a54404 100644
--- a/lib/widgets.lua
+++ b/lib/widget.lua
@@ -8,7 +8,7 @@ local awful = {
 widget = require(awful.widget)
 }
 
-module(obvious.lib.widgets)
+module

Re: [Obvious Patch] Some fun

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrei Thorp wrote:
 On Mon, Aug 03, 2009 at 06:21:42PM +0200, Uli Schlachter wrote:
 [...]
 Subject: [PATCH 2/4] Add a general function for creating widgets
 [...]
 
 Nifty, nifty. What we might want to investigate in the future is having
 widget users be able to choose what kind of display the widget has. For
 example, if we have a graphical progress bar as well as a textual
 progress bar as well as a simple numerical progress bar, it's imaginable
 that you could write a generic widget that has an option for which kind
 of display it should be using.

You should really take a look at my obvious rfc patches below. ;)

In my current awesomerc.lua I got sth like this:
 obvious.widget.progressbar(obvious.data.wlan(wlan0)),
 obvious.widget.graph(obvious.data.wlan(wlan0)),

I hope you get the idea. ;)

Please comment on those patches!

Uli

P.S: While I only submitted the wlan version yet, I have upload traffic,
download traffic, mem usage, cpu usage, disk I/O and used disk space coded and
working.
- --
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)

iQEcBAEBCAAGBQJKextDAAoJECLkKOvLj8sGk+AH/j7x5ypNoPX6dn8E64FkE2vb
Yy+0HRN2yJLerHsOnF5x8WBSdJxG+MzSvGvLHT1iIe265T/UMx/W3A406bMW+Hin
n1imn04+Zikwr/MPRMOF0bNbyErQCkI6gxB6RSimfXz5GPNfY3qGnUOwWhcmZHyC
KkTFsxzhYrxmX4y8Qn6IZd/z5SKbgwwNk6/wTxa9Kcn6Sh/DCQOasjp6A1kQxHDq
6tLctoIs5Gxue8j/VSNo/mZqDafgU+CRtEltrxziXNtDcFY2xHBPSUYn2ecy7R0N
a8ajU8sCk+rU8wkfhDpll53cVzOgXNJdX9I5Z22igBtnGAxvlGUg50a+nj9fnWA=
=JfO7
-END PGP SIGNATURE-

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

[Obvious Patch] Fix volume_alsa

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

volume_alsa killed my awesome session today by indexing nil. Don't do that!

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)

iQEcBAEBCAAGBQJKfDEiAAoJECLkKOvLj8sGIOUIAMfbZHnu976m1ZrnxGVAWInZ
Mlol5Wnr42FhzCBvGbQBcRHju5OEgY6s0QhJsBIHJTEjRK/7o7xwh3a3uhhjY5Ze
tytVS1zWRHaTc/a0OzranlQWDXyzkd1fnKs/mFmN3toc5m8UynVM4t78nxwTFLsc
qNSGSc/SzbngtymnVnEQifLWFAcMJmdC4r5TLBMZSktyn6qUkCnI8RJFHE3ajTyJ
IxEhCVDkD20yI8Erm5i4M+XHCK+PKcUiM6uIwgNrMBPCuayYQQOsMLcraq7zrkx9
8H6qLM4uRhwNPZJ4v92s/DHAKLGKESanEL265QACUsIRA6zGeUwxB/pjXg6IydM=
=apHw
-END PGP SIGNATURE-

From ff572e814868befe45ff4a4d3ab69cfd3b65cfa8 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Fri, 7 Aug 2009 15:47:44 +0200
Subject: [PATCH] obvious.volume_alsa: Don't break if mis-configured

If get_data() fails it returns nil. This might be bad by itself, but this is not
bad enough to shoot into awesome's foot. With this patch the following error
goes away:

W: [snip] volume_alsa/init.lua:57: attempt to index local 'status' (a nil value)

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 volume_alsa/init.lua |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/volume_alsa/init.lua b/volume_alsa/init.lua
index fe193f5..902926c 100644
--- a/volume_alsa/init.lua
+++ b/volume_alsa/init.lua
@@ -51,7 +51,7 @@ function get_data()
 end
 
 local function update()
-local status = get_data()
+local status = get_data() or { mute = true, volume = 0 }
 
 local color = #90
 if not status.mute then
-- 
1.6.3.3

[Patch] Place new client's on their direct transient_for's screen, not the top-level one

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list,

finally again an awesome patch. ;)

The C code in client_manage() recursively follows transient_fors to find the
top-level transient_for client. It then places the new client on this screen.

Then, later on the lua manage hook is run which ends up running
awful.tag.withcurrent() (registered to the manage hook in the same file). This
function places the new window on its direct transient_for's window. Thus, the C
code's screen is always overwritten anyway.

The attached patch just makes the C code select the same screen that
awful.tag.withcurrent later on select again. Alternatively one could remove that
code from the C core completely, but I like the attached solution more.

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)

iQEcBAEBCAAGBQJKfJM1AAoJECLkKOvLj8sGRfMIAKDW43KeaZgM4V+hXCrbE8yF
L4b1jVZejInmtW177dEnI/l72ZBOxwHB9pHr6GHM3AN7ud0lubixZ1U6LSOmWsjW
1z1dOLN192OofUZemZi+HqBggeW4d8tn+JvjF+HzXO47bqn/+esROsxewA5CW2HV
caRxYxz/yOV+zaM0B+CW6Vr3h4lBbjpd407Etqr5b6e6vpdY+t5Q7/KNrFKUGzkF
sISn/wb7u68n0VHGJ/Lw3qRR53bKUOG37GB/I/r5CgjHuTXGyemkaeX088WTTjbl
jhk2zNI+h4O0Ib/hGzh+M9IIhQBfywtxkU6uIP1P4A5Oss682JOpv8E/aaOFVHo=
=HcZq
-END PGP SIGNATURE-
From feb1c98218c9e56e8feab8480acae0cefcc174de Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Fri, 7 Aug 2009 22:30:32 +0200
Subject: [PATCH] Don't follow transient_fors recursivly in client_map()

This code uses the top-most transient_for to decide on which screen this window
should appear, but awful.tag.withcurrent (which is attached to the manage hook)
will move it to the direct transient_for's screen anyway, effectively disabling
the effect of this for loop. Therefor this change shouldn't really result in any
behavior change.

Plus this improves our reaction to transient_fors which form a loop. Before we
went into an endless loop in the for loop which this patch removes. After this
patch, we will enter an endless loop in the client_raise() call in
client_manage(). No idea for that one. :/

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 client.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/client.c b/client.c
index 5589fa8..8be4065 100644
--- a/client.c
+++ b/client.c
@@ -493,7 +493,7 @@ void
 client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, int phys_screen, bool startup)
 {
 xcb_get_property_cookie_t ewmh_icon_cookie;
-client_t *c, *tc = NULL;
+client_t *c;
 screen_t *screen;
 const uint32_t select_input_val[] = { CLIENT_SELECT_INPUT_EVENT_MASK };
 
@@ -550,10 +550,9 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, int phys_screen,
 property_update_wm_transient_for(c, NULL);
 property_update_wm_client_leader(c, NULL);
 
-/* Recursively find the parent. */
-for(tc = c; tc-transient_for; tc = tc-transient_for);
-if(tc != c  tc-phys_screen == c-phys_screen)
-screen = tc-screen;
+/* Move this client to its parent's screen */
+if(c-transient_for  c-transient_for-phys_screen == c-phys_screen)
+screen = c-transient_for-screen;
 
 /* Then check clients hints */
 ewmh_client_check_hints(c);
-- 
1.6.3.3

Re: [PATCH] awful.completion: sort matches

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gregor Best wrote:
 On Sat, Aug 08, 2009 at 12:14:39PM +0100, koniu wrote:
 Hi,

 Dunno if it's just me but here, at least with zsh completion, the
 available matches are pretty randomly ordered with gajtab giving
 gajim-remote first, then gajim-history-manager and finally (after
 a lot of cycling) gajim. I think we need to sort the table.

 koniu
 [...]
 
 Yeah, that also happens with Bash completion and it annoyed the hell out
 of me :)

You guys really use completion? Wow... Lot's of different users, I guess

- --
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)

iQEcBAEBCAAGBQJKfWsiAAoJECLkKOvLj8sG1qkH/j0qdjklQbSRAwI/T9MCL7tK
RdxaBBaTPzMNQo1o3x3cd4Ozc4HWLtIlpik3RM5VrZBVCju8ouXa9F548C180lHN
pckGJ7NZp/eItJ18TkG42P1tFZrWY5f2aBWbIsQeHi3hqGhzmWLEoh0KI/wv+DHb
cJ6L/jZsGKCaBf3mytOtZdi66RjJ/xEIPeEAG0/l6FmBj7BXMtPgfkTfTIQUAU+Z
yJWW+mcrnT2UnC3WILsvA6Rszb1LFSc6P4tswfAOBD7isnL+iWGPlwKhFFVrAQUr
ZWUPtOqixFtLuBgMgVYWOLyfDvKz3Pzl4yGKPhZ8JizRj99rXII83/iL/OrgttY=
=Gg+d
-END PGP SIGNATURE-

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

[Patch] Let graph and progressbar return their own widget in :set_* functions

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list,

This change enables stuff like the following:

 awful.widget.graph({}):set_color(red):set_width(40):add_value(0.5)

Additionally, one can use the above directly in th widgets table.

This most likely doesn't break any existing configs and it adds a quite nice
syntax which can be used for in-place configuration of new widgets.

Plus I need this to make my Great New Obvious Stuff (tm) (GNOS) work. ;)

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)

iQEcBAEBCAAGBQJKfYLsAAoJECLkKOvLj8sGCi8H/14VwwUyJv0CwePnpef0KeaH
XMsghB8vluZj7a4A1jXQo2TYPBrzf0F+Ttr2nhPS9f4o+p5fkUwUGoTZg+3YeAv3
1Tb03HNkg7ihXeZsqH07v8EtLJqCYeNr2abm18R1/IPxWRuKUnXVFe1+N+wA2IfH
KA7hSOEauAgXVrkfblVRK5yCFAb57B6NCz3ccO/xpAQEj77JaTMBwCAgdT0VPhDe
jwLRDrLJZqRsL9r1gQS0FEPwXGs0T2Qco4dfKKrYohmQLQjEuBuT8vlhcJ5sBQV+
HjEdwENPXe7hHYodlBLZPmN18V2SNjHB8iwciDaN6yrW6B/DLcUiGQmtESEm9Sk=
=S5bK
-END PGP SIGNATURE-
From dba6afb751a821d2d40643fed21b1539f2a043e9 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Sat, 8 Aug 2009 15:47:00 +0200
Subject: [PATCH] lib.awful.widget: Return obj in set_* methods

This change enables stuff like the following:

 awful.widget.graph({}):set_color(red):set_width(40):add_value(0.5)

Additionally, one can use the above directly in th widgets table.

This most likely doesn't break any existing configs and it adds a quite nice
syntax which can be used for in-place configuration of new widgets.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/awful/widget/graph.lua.in   |4 
 lib/awful/widget/progressbar.lua.in |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/lib/awful/widget/graph.lua.in b/lib/awful/widget/graph.lua.in
index 4802a0d..7ef756b 100644
--- a/lib/awful/widget/graph.lua.in
+++ b/lib/awful/widget/graph.lua.in
@@ -164,6 +164,7 @@ local function add_value(graph, value)
 end
 
 update(graph)
+return graph
 end
 
 
@@ -175,6 +176,7 @@ local function set_height(graph, height)
 data[graph].height = height
 update(graph)
 end
+return graph
 end
 
 --- Set the graph width.
@@ -185,6 +187,7 @@ local function set_width(graph, width)
 data[graph].width = width
 update(graph)
 end
+return graph
 end
 
 -- Build properties function
@@ -193,6 +196,7 @@ for _, prop in ipairs(properties) do
 _M[set_ .. prop] = function(graph, value)
 data[graph][prop] = value
 update(graph)
+return graph
 end
 end
 end
diff --git a/lib/awful/widget/progressbar.lua.in b/lib/awful/widget/progressbar.lua.in
index 652a949..2b30a3a 100644
--- a/lib/awful/widget/progressbar.lua.in
+++ b/lib/awful/widget/progressbar.lua.in
@@ -116,6 +116,7 @@ end
 local function set_value(pbar, value)
 local value = value or 0
 data[pbar].value = math.min(1, math.max(0, value))
+return pb
 end
 
 --- Set the progressbar height.
@@ -126,6 +127,7 @@ local function set_height(progressbar, height)
 data[progressbar].height = height
 update(progressbar)
 end
+return progressbar
 end
 
 --- Set the progressbar width.
@@ -136,6 +138,7 @@ local function set_width(progressbar, width)
 data[progressbar].width = width
 update(progressbar)
 end
+return progressbar
 end
 
 -- Build properties function
@@ -144,6 +147,7 @@ for _, prop in ipairs(properties) do
 _M[set_ .. prop] = function(pbar, value)
 data[pbar][prop] = value
 update(pbar)
+return pbar
 end
 end
 end
-- 
1.6.3.3

Re: [Patch] Let graph and progressbar return their own widget in :set_* functions

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Uli Schlachter wrote:
 This change enables stuff like the following:
[snip]

I hate it when this happens. Attached is a fixed version of the patch.

The only change: return pbar instead of return pb in progressbar's 
set_value().

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)

iQEcBAEBCAAGBQJKfYNvAAoJECLkKOvLj8sGuBkH/R3z68a4A0uNtklaLIhwlUVV
1D/Yql3pXEVtVx/RG5Uyl9pEDXGYu4qrTFqnRq6+1ieZA14ih/skdB1G+pXg/R/w
tG98eExq0gilMSY04d5GPRGv/3SGqRYqyXB0XYVodB5Lb0wVmpVORv639xwSpxxV
0/mPa5PF4WYSy91L7IsfpRN19Il+B3f1lv6co++sjFchW8QPg9FF+P1CeLgcNJ62
a8Y8fqvb2CAl6zMVll6BMbKtVSrDMUFY9OXLVhpKGVg3ipc5IuuFsm2Y2yk671iX
dEi5NFTn1bwtczO962n2dl6CmsET2Boh94Iy7efaOs3y+vmTges3XKRdi/mBb0k=
=GVWM
-END PGP SIGNATURE-
From bbd8ec4ec703540f353740ffdf18f89963f19578 Mon Sep 17 00:00:00 2001
From: Uli Schlachter psyc...@znc.in
Date: Sat, 8 Aug 2009 15:47:00 +0200
Subject: [PATCH] lib.awful.widget: Return obj in set_* methods

This change enables stuff like the following:

 awful.widget.graph({}):set_color(red):set_width(40):add_value(0.5)

Additionally, one can use the above directly in th widgets table.

This most likely doesn't break any existing configs and it adds a quite nice
syntax which can be used for in-place configuration of new widgets.

Signed-off-by: Uli Schlachter psyc...@znc.in
---
 lib/awful/widget/graph.lua.in   |4 
 lib/awful/widget/progressbar.lua.in |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/lib/awful/widget/graph.lua.in b/lib/awful/widget/graph.lua.in
index 4802a0d..7ef756b 100644
--- a/lib/awful/widget/graph.lua.in
+++ b/lib/awful/widget/graph.lua.in
@@ -164,6 +164,7 @@ local function add_value(graph, value)
 end
 
 update(graph)
+return graph
 end
 
 
@@ -175,6 +176,7 @@ local function set_height(graph, height)
 data[graph].height = height
 update(graph)
 end
+return graph
 end
 
 --- Set the graph width.
@@ -185,6 +187,7 @@ local function set_width(graph, width)
 data[graph].width = width
 update(graph)
 end
+return graph
 end
 
 -- Build properties function
@@ -193,6 +196,7 @@ for _, prop in ipairs(properties) do
 _M[set_ .. prop] = function(graph, value)
 data[graph][prop] = value
 update(graph)
+return graph
 end
 end
 end
diff --git a/lib/awful/widget/progressbar.lua.in b/lib/awful/widget/progressbar.lua.in
index 652a949..75111e4 100644
--- a/lib/awful/widget/progressbar.lua.in
+++ b/lib/awful/widget/progressbar.lua.in
@@ -116,6 +116,7 @@ end
 local function set_value(pbar, value)
 local value = value or 0
 data[pbar].value = math.min(1, math.max(0, value))
+return pbar
 end
 
 --- Set the progressbar height.
@@ -126,6 +127,7 @@ local function set_height(progressbar, height)
 data[progressbar].height = height
 update(progressbar)
 end
+return progressbar
 end
 
 --- Set the progressbar width.
@@ -136,6 +138,7 @@ local function set_width(progressbar, width)
 data[progressbar].width = width
 update(progressbar)
 end
+return progressbar
 end
 
 -- Build properties function
@@ -144,6 +147,7 @@ for _, prop in ipairs(properties) do
 _M[set_ .. prop] = function(pbar, value)
 data[pbar][prop] = value
 update(pbar)
+return pbar
 end
 end
 end
-- 
1.6.3.3