Re: 3.3-rc1 crash bug (?)
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 -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: 3.3-rc1 crash bug (?)
At 1241876690 time_t, Uli Schlachter wrote: jd: I guess the debian version doesn't have this... bug? Should not. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
Re: premature raise() somewhere?
At 1241879154 time_t, koniu wrote: Somewhere there's an implicit raise() or something which in some situations causes flicker when a client is being managed. The most common situation I see this in is when in max layout and having 1 urxvt window open, I spawn another one and for a split second I can see it in the top-left corner of the screen in its default size before the screen is arranged. Every new windows start raised. And that's not a choice, that's how X works AFAIK. One solution could be to set the window down the stack in client_manage() and send a configure window request (_if needed_) to trigger the go down before it is mapped later by arrange(). Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: [RFC + PATCH] awful.doc
At 1241938520 time_t, koniu wrote: Nope, I haven't been dead or anything, on the contrary I've made some progress with this stuff. Recent commits in the branch re-organize some functions and make the whole thing a bit smarter. Nice. There's more but I cant be bothered to do full changelogs since all of this will end up squashed to 'import' anyway. Here's some recent screenshots, tho I plea to you to try it in action as that could generate some constructive feedback. http://omploader.org/vMW5qOQ http://omploader.org/vMW5qYg http://omploader.org/vMW5qYw http://omploader.org/vMW5qZA That's just *great*. Anyway, so how would we go about generating doc.set()s for modules other than awful (including capi)? IMHO, we should provide a special module for that. awful.doc.awful was nice for documenting awful, but in the end, we need to document more stuff as you noticed. So I suggest to change the auto documentation stuff to auto document everything in lib/ and move that in awful.doc.awesome. I've done it in the latest commit of jd/awful-doc-generate branch. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: [PATCH] naughty environment cleanup
At 1241929100 time_t, koniu wrote: I missed one s/screen/capi.screen/ in this patch, please amend. Amended. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // There is nothing under this line. signature.asc Description: Digital signature
Re: Pull request - random build stuff and some minor config cleanup
At 1241895108 time_t, Uli Schlachter wrote: jd just showed me git request-pull. Since I think it's a nice command, I just had to try it. ;) That's cool. Use tr [:lower:] [:upper:] instead of the a-z one Seriously, I pick this one because it does not break anything, but that's really a pity. awesome-client: Use /bin/sh instead of /bin/bash Really not sure, but at least it works with bash, zsh, ksh and dash. That might be enough. Everything pushed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: RFC/Testing: jd/padding branch
At 1241969514 time_t, koniu wrote: OK, so now its in next and I have no choice but to take that time and test :) One thing I can say so far is that having get_workarea() in awful.wibox is a bit counter-intuitive, it should go to awful.screen. That would require adding a function to export the local 'wiboxes' table in awful.wibox. Can provide patches if this sounds like a good idea. Well, if that's possible, having a get_workarea in awful.screen handling padding and wiboxes would be nice, sure. I'll let the implementation detail up to you. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust no one. signature.asc Description: Digital signature
Re: [RFC + PATCH] awful.doc
At 1242022527 time_t, koniu wrote:
The generated awesome.lua generally broke for me trying to index nil
values while settings descriptions for modules that weren't even
loaded (invaders :P) so I fiddled with the generator and added pulling
global environment + checks for the given module being loaded:
http://git.mercenariesguild.net/?p=awesome.git;a=commitdiff;h=cf3dc8c9849df0b9c44a7b4a05e6a7e21216
Ok, you can merge it with my previous commit adding the doc generator
then.
The results (in combination with fresh commit that does line breaking)
are nice: http://omploader.org/vMW5xbg
Niice. :)
Remaining problems with the generator are:
1. the capi 'module'. It breaks the generated code by setting stuff like this:
if env then set(env.progressbar.bar_data_add, { ...
progressbar will be always nil and we're trying to index it.
This is a version where I was trying to make this work (and then
noticed that it won't probably happen like that):
http://git.mercenariesguild.net/?p=awesome.git;a=commitdiff;h=0f6afad8febed553a77818f767065936a0744773
Yeah, C API is a problem. All objects method would be impossible to
document I think since they are not exported to Lua as function, but
only as methods on objects.
We could change that however. I'll give it a try.
2. i haven't fully investigated but @class table kind of docs are
not generated right, we get only keys 'description' and 'comment' but
nothing else (no table with @field's or anything)
any clues on these?
Nop. I think the script generating stuff does things badly. IIRC there's
a couple of if for printing module and stuff, I maybe forgot table
objects. There's not reason luadoc would not give this information.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// When I get sad, I stop being sad and be awesome instead. True story.
signature.asc
Description: Digital signature
Re: 3.3-rc1 crash bug (?)
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. 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, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Tomorrow I was nothing, yesterday I'll be. signature.asc Description: Digital signature
Re: Making gkrellm not float [PATCH]
At 1242588030 time_t, koniu wrote: Attached a patch on top of master so that new users can enjoy this starting with 3.3. Pushed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Ferns will rule the world. signature.asc Description: Digital signature
[ANNOUNCE] awesome 3.3-rc3 released
Hi folks, Sorry for the delay, but I was really too busy these last days, so I did not have time to handle awesome correctly. I'll still be under heavy load until the end of the week, when I'll have done moving into my new flat. So, what's new in this rc3? Nothing big, it's a rc version, of course. But I did fix a couple of startup-notification related issue, so you won't get a cursor stucked with a watch anymore. A memory corruption in startup-notification was also fixed. Rendering of left/right oriented wibox has also been fixed. root.fake_input was fixed also. Two other changes: build issue on weird system fixed, and titlebar icons are partially autogenerated using ImageMagick. There seems to be not so many issue remaining, so I really except final version in ~2 weeks. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust no one. awesome version 3.3-rc3 has been released. It is available from: tar.gz: http://awesome.naquadah.org/download/awesome-3.3-rc3.tar.gz md5sum: 54d1591f18fea1a076d75c3f111fed8d tar.bz2: http://awesome.naquadah.org/download/awesome-3.3-rc3.tar.bz2 md5sum: 86aa76cc6fb3b7502e721187a22279f6 number of changes - 28 shortlog Ali Polatel (1): luaA_init: use Lua C API to add paths to package.path Johan Kiviniemi (1): themes: Generate unfocused/inactive icons automatically Julien Danjou (13): build: allow to specify cmake args spawn: fix reference counting of sequences spawn: call startup notification hooks on time out awful.startup_notification: unregister events on time out build: remove useless check for libs spawn: fix hook call on timeout swindow: fix draw_context_update for north and south orientation widget: use orientation rather than position root: fix screen in fake_input root: fix arguments in fake_input spawn: fix sequence ref count again build: remove ncurses stuff change codename Uli Schlachter (12): 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 Remove a wrong space awesome-client: Properly exit when dbus-send isn't found awesome-client: Fix bashism awesome-client: Use /bin/sh instead of /bin/bash koniu (1): awesomerc: allow 'false' in floatapps diffstat CMakeLists.txt | 40 ++ Makefile |2 +- README |3 + awesomeConfig.cmake| 22 ++-- awesomerc.lua.in | 25 + build-utils/gperf.sh | 17 +++--- event.c|6 +- lib/awful/startup_notification.lua.in |3 +- lib/awful/util.lua.in |6 +-- luaa.c | 54 mouse.c|2 +- root.c | 21 spawn.c| 22 +++- swindow.c |4 +- themes/default/theme.lua.in|2 +- themes/default/titlebar/close.png | Bin 358 - 0 bytes themes/default/titlebar/close_normal.png | Bin 431 - 0 bytes themes/default/titlebar/closer.png | Bin 611 - 0 bytes .../default/titlebar/floating_focus_inactive.png | Bin 414 - 0 bytes themes/default/titlebar/floating_normal_active.png | Bin 386 - 0 bytes .../default/titlebar/floating_normal_inactive.png | Bin 349 - 0 bytes .../default/titlebar/maximized_focus_inactive.png | Bin 816 - 0 bytes .../default/titlebar/maximized_normal_active.png | Bin 738 - 0 bytes .../default/titlebar/maximized_normal_inactive.png | Bin 682 - 0 bytes themes/default/titlebar/ontop_focus_inactive.png | Bin 669 - 0 bytes themes/default/titlebar/ontop_normal_active.png| Bin 565 - 0 bytes themes/default/titlebar/ontop_normal_inactive.png | Bin 590 - 0 bytes themes/default/titlebar/sticky_focus_inactive.png | Bin 659 - 0 bytes themes/default/titlebar/sticky_normal_active.png | Bin 611 - 0 bytes themes/default/titlebar/sticky_normal_inactive.png | Bin 597 - 0 bytes utils/awesome-client |6 ++- widget.c | 10 ++-- widget.h |2 +- 33 files changed, 154
Pager problem with ban offscreen
Hi,
Bug #528512 at Debian[1] seems to me to be the responsibility of
commit f9c2ee62a32cd98eedd3a76f9180dd320f682d80
Author: Maarten Maathuis madman2...@gmail.com
Date: Thu Nov 20 22:11:13 2008 +0100
client: reimplement client_{ban,unban} for more performance
Which move windows offscreen rather than unmapping them.
We are breaking pagers with that, which is IMHO more problematic than
solutionning performance problem we are not responsible for.
I might decide to fix that bug by reverting to the old unmap system
unless someone has an idea how to fix this properly.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528512
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// And thinking so much differently.
signature.asc
Description: Digital signature
Re: Build breakage [was: Updated patch: Unfocused titlebar icons look bad on non-black background]
At 1242652336 time_t, Uli Schlachter wrote: 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 What returns this command on its own? 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 Version: ImageMagick 6.5.1-0 2009-04-09 Q16 OpenMP http://www.imagemagick.org Here (sid) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: Invalid _NET_WM_ICONs not properly caught
At 1242673617 time_t, Uli Schlachter wrote: Both patches are attached again. Thanks, pushed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: [Patch] Allow setting wibox.opacity if wibox.screen is nil (was: Re: [PATCH] naughty: set screen first and opacity afterwards)
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, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman. signature.asc Description: Digital signature
Re: Fixup awful to use awful.wibox.get_workarea(screen)
At 1242901314 time_t, Jacob Winther wrote: I noticed the menu and some windows were overlapping the wibox in next, fix attached. Thanks, pushed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust no one. signature.asc Description: Digital signature
Re: Problem with 3.3-rc3 and functions using ... and arg
At 1243188456 time_t, Tassilo Horn wrote: Ah, now I've looked that up in the lua spec. In 5.0 `arg' is used to access varargs, but in 5.1 `...' is used instead. Because awesome uses so many bleeding edge libs anyway, I'd say that one could switch to using lua 5.1 syntax... Thanks, that should be fixed, for sure. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: next branch keybinding weirdness
At 1243147563 time_t, koniu wrote:
My best conclusion so far is that when re-setting root.keys with
different length tables (note that I still run root.keys({ ... }) even
when switching A1-A2 and it works fine) something goes wrong and the
keybinding/function is done twice.
The thing is that when you call root.keys(), awesome lies down the table
passed as argument, and fill an array of key object (globalconf.keys).
So when awesome receive an key event, it look through from 0 to
globalconf.keys.len and check each element of the array. When a
key matches, it run its callback function.
So if one of this function modifies the array, while the loop was
checking for example key object 5 on 200, it will still go through key
number 6 which can be ... the same as 5 if you pushed an elememnt in
from of your table in the previously called callback function from
object number 5.
In fact it can be anything else, and you can do very bad things modifying
key bindings while a key binding is pressed, like infinite loop.
(This can be a false problem, since awesome is able to finish such a loop in
matter of miliseconds of course *g*)
Seriously, this has been discussed previously, and no solution has been
found.
I just though about something that IIRC had not been proposed.
What we can try is to go through the loop and look for matching key from
globalconf.key. Then, rather then calling callback function each time we
match (since that can break things (TM)) we store key object temporarly.
_Then_, we call all matched key's callback function. If one of them
modify the root.keys(), we just do not care, we already finished
looping.
What do you people think?
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// I'm no superman.
signature.asc
Description: Digital signature
Re: [PATCH] 0001-hooks-add-exit-hook
At 1243184445 time_t, Gregor Best wrote: You wouldn't need such a hook. Just append all stuff which needs to be started to the end of your rc.lua Except that it's not very easy to use when you just want to add that code in a module. You can't access rc.lua and telling user to add code ia PITA. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: Problem with 3.3-rc3 and functions using ... and arg
At 1243245445 time_t, Tassilo Horn wrote: In the meantime I've discovered that lua 5.1.4 allows to use those deprecated features by default, but my distro (Gentoo) disables them if the deprecated USE flag is not set. This explains why nobody except me complained till now. So for now I recompiled lua with the 5.0 vararg style enabled and awesome 3.3-rc3 is running fine. Fine, anyway it's fixed in git now AFAICT. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // The more we fly, the more we climb, the more we know that heaven is a lie. signature.asc Description: Digital signature
Re: [PATCH] 0001-hooks-add-exit-hook
At 1243177021 time_t, koniu wrote: and the patch :P Pushed. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Ferns will rule the world. signature.asc Description: Digital signature
Re: [Patches] Fix some minor compiler warnings found in rc3
At 1243166412 time_t, Uli Schlachter wrote: gogonkt reported some compiler warnings in #awesome with gentoo's gcc 4.2.4 (And he also had an error trying to build the docs, but no idea about that one. Merged. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: [Patch] simplewindow / wibox stuff (nothing major ;)
At 1243258659 time_t, Uli Schlachter wrote: this is v2 of Re: [Patch] Allow setting wibox.opacity if wibox.screen is nil which I sent some time ago (or rather: this is completly unrelated to that other patch, but also fixes that bug). There is also some other stuff in there, but everything is wibox/simplewindow related. I've merged it, but edit to inline opacity helpers function. (and added to my TODO to merge wibox and swindows :) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // The more we fly, the more we climb, the more we know that heaven is a lie. signature.asc Description: Digital signature
Re: c.hide broken in next
At 1243264813 time_t, koniu wrote: jd_, u mess with all those properties :) Did I? :) I've amended the commit responsible of that. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: next branch keybinding weirdness
At 1243268501 time_t, koniu wrote: This can be tested/reproduced by adding this to default rc's awful.hooks.tags function: if view == select root.keys(globalkeys) end This is not a major issue but makes me think that there could be some improvement to be made in the way properties/hooks/events are handled there. I can't reproduce such a behaviour even adding this to default config. Maybe some profiling may help? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: c.hide broken in next
At 1243272624 time_t, koniu wrote: Fixed, thanks. Can you do the same magic for c.minimized (same issue)? Should be ok. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: And the patch :P Fwd: [Patch] warning in setlocale()
At 1243318849 time_t, Ángel Alonso wrote: From 92761316de40b0cac70dd5eca34ed72d7a84e07c Mon Sep 17 00:00:00 2001 From: feler fe...@archlinux.us Date: Tue, 26 May 2009 22:40:20 -0700 Subject: [PATCH] warning_setlocale --- awesome.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/awesome.c b/awesome.c index 321d98e..e6672e6 100644 --- a/awesome.c +++ b/awesome.c @@ -354,7 +354,8 @@ main(int argc, char **argv) } /* Text won't be printed correctly otherwise */ -setlocale(LC_CTYPE, ); +if(!setlocale(LC_CTYPE, )) +fprintf(stderr, warning: cannot set locale.\n); You should rather use warn(). Btw, does this situation really happens and has any impact? Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // The more we fly, the more we climb, the more we know that heaven is a lie. signature.asc Description: Digital signature
[ANNOUNCE] awesome 3.3-rc4 released
Hi awesome people, Another rc, probably the last one, a bit late again. Busy busy me. This one fixes compatibility problem with Lua 5.1, and also revert some changes about how we handled docking. We are back to the old behaviour, respecting EWMH. It also fixes some corner cases with applications settings bad information about their icons. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // The more we fly, the more we climb, the more we know that heaven is a lie. awesome version 3.3-rc4 has been released. It is available from: tar.gz: http://awesome.naquadah.org/download/awesome-3.3-rc4.tar.gz md5sum: ce6df795892104c1592a20fff1505521 tar.bz2: http://awesome.naquadah.org/download/awesome-3.3-rc4.tar.bz2 md5sum: ccd951458b386d53839b29e76b60607f number of changes - 12 shortlog Johan Kiviniemi (2): themes: Old ImageMagick compatibility themes/sky: Titlebar icons: use current default theme paths Julien Danjou (6): awful.tag: call property hook on icon changes main: fix typo in fatal() lib: stop using unpack where not needed Revert client: handle struts (a lot) better Revert client, mouse: improve struts a bit change codename Uli Schlachter (4): Restructure the code in ewmh_window_icon_from_reply() slightly Check that the property is as long as it should be Fix a harmless compiler warning Fix a couple of harmless compiler warnings diffstat CMakeLists.txt |2 +- awesome.c|2 +- awesomeConfig.cmake |2 +- client.c | 195 -- client.h |3 - ewmh.c | 20 +++- layout.c |2 - lib/awful/button.lua.in |5 +- lib/awful/client.lua.in |3 +- lib/awful/key.lua.in |5 +- lib/awful/layout/init.lua.in |3 +- lib/awful/mouse.lua.in | 16 ++-- lib/awful/tag.lua.in |2 +- lib/awful/titlebar.lua.in|3 +- lib/awful/widget/button.lua.in |3 +- lib/awful/widget/launcher.lua.in |3 +- lib/awful/widget/prompt.lua.in |5 +- lib/awful/widget/taglist.lua.in |6 +- lib/awful/widget/tasklist.lua.in |5 +- mousegrabber.c |2 +- screen.c | 31 +++ themes/sky/theme.lua.in | 24 +- wibox.c |3 +- widgets/graph.c |1 + widgets/imagebox.c |2 + widgets/progressbar.c|2 + widgets/systray.c|2 + widgets/textbox.c|2 + 28 files changed, 95 insertions(+), 259 deletions(-) signature.asc Description: Digital signature
Re: tag history broken in next
At 1243301027 time_t, koniu wrote: I've attempted to hack a better tag history implementation which would be multi-level and allowed a variable number of tags. The problem I keep facing is that eg. each tag switch with viewonly() triggers a bunch of unselect's by running viewnone() which results in useless history entries with all tags unselected. Any hints welcome :) I also tried to fix that yesterday, but did not find anything for now. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Ferns will rule the world. signature.asc Description: Digital signature
Re: focus problem in next
At 1243269750 time_t, koniu wrote: Reproducible with default rc.lua. I confirm. A bisect may help. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
New logo / Web site contest
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, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: [Patch] add image:insert
At 1243434830 time_t, Gregor Best wrote: Okay, I re-did the patch with imlib_blend_image_onto_image_skewed in a fashion which allows the user to quickly blend one image into another without much hassle but which gives them all parameters to imlib_blend_image_onto_image_skewed if they want them. Merged into next. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Tomorrow I was nothing, yesterday I'll be. signature.asc Description: Digital signature
Re: [PATCH] awful.util: add linewrap()
At 1243445257 time_t, Andrei Thorp wrote: Sounds great, I love more hooks. Too bad, I'm going to deprecate them. Then deprecating the deprecation hook will be fun so much fun. :) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: next branch - wibox removal gives errors
At 1243485316 time_t, koniu wrote: This patch seems to help. Merged with the culprit patch. This is a real problem anyway, since your fix works but is bad: you cannot have the new value of the wibox then. I'm getting tired of this fucking mishandled hooks. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: [PATCH] client: allow setting skip_taskbar
At 1243490010 time_t, koniu wrote: +luaA_dofunction_from_registry(L, globalconf.hooks.clients, 0, 0); Nop, call the property hook. This one is only for client list. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: [PATCH] add support for skip_taglist property for tags
At 1243492347 time_t, koniu wrote: The idea is to allow hiding tags from the taglist. There are two patches: 0001 - handles makes taglist updates ignore tags with skip_taglist set. 0002 - makes viewidx() ignore those tags Perhaps, in view of patch #2, the property should be called hide or hidden instead. Hum probably. But what about just removing the tag from the screen? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Tomorrow I was nothing, yesterday I'll be. signature.asc Description: Digital signature
Re: [PATCH] awful.util: add linewrap()
At 1243640834 time_t, koniu wrote: On Thu, May 28, 2009 at 13:14, Julien Danjou jul...@danjou.info wrote: Pushed. Ay, sorry, forgot to add string to the environment, see amended patch. Pushed. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: rounded wibox corners
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 think it's better to just have rounded via some C code for now... I trust you on that. 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... Depends, if you want to draw a triangle, it's enough. :-) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: [PATCH] add support for skip_taglist property for tags
At 1243700537 time_t, koniu wrote: Amended patches with property renamed to 'hide'. Is that ok? Should be, pushed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // In the Sixth Sense, Bruce Willis is dead. signature.asc Description: Digital signature
Re: Writing a layout - where does the p parameter come from?
Hi Nathan, At 1243891357 time_t, Nathan Huesken wrote: So I am looking at the tile layout as reference. It seems, that its parameters are stored in the current tag ... No I wonder, what would I have to do to get my parameters in. And I also wonder how I could remember which client belongs to which tile. Can I store information in clients as well? As you can see all information are passed to layouts via on_arrange() function in awful/layout/init.lua. Clients and tags have properties internal to awesome core, but since some people or libs wants to store information, we usually use a property thingie inside awful.tag and awful.client. You have a set of awful.tag.setproperty() or something like that, which can be used to store more properties. This properties are automatically collected upon objects destructution so you do not have to worry about this. Just store what you need and retrieve it when needed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust me. signature.asc Description: Digital signature
Re: Writing a layout - where does the p parameter come from?
At 1243975693 time_t, Nathan Huesken wrote: - What is the difference between workarea and geometry? Geometry is the screen geometry, i.e., the number of pixels available from left to right. Workarea is the same thing, but minus the wibox and the client that have struts (i.e. panel like gnome-panel or gkrellm in dock mode). That's the space you should use to put your windows, unless you want to put your windows above the panels and wiboxes, which I don't think you want in a layout IMHO. :-) - OK, I can set simple properties of a tag and a client using Gregor answered to that. ;) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman. signature.asc Description: Digital signature
Re: Getting the focused client in tag.lua
At 1244044432 time_t, Nathan Huesken wrote: in it. Can I somehow cat the focused client in tag.lua? Just use capi.client.focus ? Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // The more we fly, the more we climb, the more we know that heaven is a lie. signature.asc Description: Digital signature
Re: client.property.set and client.focus
At 1244103837 time_t, Nathan Huesken wrote: Good Idea! If i just bind print(client.focus.class) to a key in my rc.lua, it gives me the correct client class. But if I put a function in my modul, which simple does the same, then the output is nil. So client.focus is ~= nil but client.focus.class is nil? Is there any other attribute like .id that you can get ? If you got .id you can then request information: xwininfo -id id -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: client.property.set and client.focus
At 1244106951 time_t, Nathan Huesken wrote: Mmmh, when I do that, capi.client.focus.class/capi.client.focus.id still is nil ... Check your declaring capi before loading awful.client. :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Tomorrow I was nothing, yesterday I'll be. signature.asc Description: Digital signature
[ANNOUNCE] awesome 3.3 released
Hi folks, We finally did it, awesome 3.3 is released. It took a little longer than usual, because I was busy, and because I was waiting to have something to fix between rc4 and final. Thanks to M. Dietrich, we had a bug fixed this morning, so that was a sufficient excuse to release! Thanks to everyone that contributed to this release. Again, our contributor base is enlarging and I'm very glad seeing more and more people invested into awesome developement. We will now focus on 3.4 developement. A lot of things have started already, so prepared to get shiny new features as usual, in the next couple of months. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! awesome version 3.3 has been released. It is available from: tar.gz: http://awesome.naquadah.org/download/awesome-3.3.tar.gz md5sum: 223f5381cd5c0f72041c4eee08e56bdd tar.bz2: http://awesome.naquadah.org/download/awesome-3.3.tar.bz2 md5sum: 0dc5574dc551c6356d8cddc6ce91739c number of changes - 2 shortlog Julien Danjou (1): change codename M. Dietrich (1): fix loop over config files if none was found diffstat awesome.c |3 ++- awesomeConfig.cmake |2 +- luaa.c |4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) signature.asc Description: Digital signature
Re: Focusing areas without client
At 1244190670 time_t, Nathan Huesken wrote: In manual tiling, one might want to focus an area where no client is. (Because he wants to split that area or because he wants the next client to appear there). This means: - No client is input focus - The area should be somehow marked. Best would be, the same marking (border) as if there would be a focused client. Can the tiling algo somehow just draw the window border? No, you can't draw a border only. You need to have a window. If you really want to fill the gap, I can make a suggestion: put a wibox in this space, with a border, and set background to # (fully transparent). Another solution is to put all windows stacked upon each others by default, and only allow splitting when the stack has more than one window. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust me. signature.asc Description: Digital signature
Re: [Patch] Some fixes
At 1244300756 time_t, Marco Candrian wrote: the graph has more than one thing. You can use a line style to have one over all others. You would be able to do the same with the widget layouts, AFAIU. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // In the Sixth Sense, Bruce Willis is dead. signature.asc Description: Digital signature
Re: [Patch] Some fixes
At 1244305993 time_t, Uli Schlachter wrote: @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 I don't recall what's scale, do you mind freshing my mind? Features that are not essential, like max value should not be added. It's just complicate the widget for no gain. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: [Patch] Some fixes
At 1244303844 time_t, Uli Schlachter wrote: And if I want this now and not in 6 months? You help Gregor? Or stay with 3.3 or the old widget for the time being. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: [Patch] Some fixes
At 1244306622 time_t, Julien Danjou wrote: You help Gregor? Or stay with 3.3 or the old widget for the time being. FWIW, I don't think like I need to justificate what I did, but removing the progressbar and graph from the C side will drop around 1K SLOC, which is just around 8 % of core size. A bit too much expansive for 2 widgets replaced by 200 lines of Lua. :-) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: [Patches] wibox handling in git
At 1244224475 time_t, Gregor Best wrote: Pushed, thanks Gregor. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // This is the end of my signature. signature.asc Description: Digital signature
Re: [Patch] Some fixes
At 1244286306 time_t, Uli Schlachter wrote:
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.
Do you have a way to reproduce this, because I'm torturing my tired mind
but I can't find why your patche is needed?
---
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
Can't you do that before calling constructor?
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);
I'd be afraid about X errors. I don't know if we check later about that.
Anyway that wouldn't be your fault/responsability. :-/
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// When I get sad, I stop being sad and be awesome instead. True story.
signature.asc
Description: Digital signature
Re: [Patch] Some fixes
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.
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Ferns will rule the world.
signature.asc
Description: Digital signature
Re: [Patch] Some fixes
At 1244311597 time_t, Gregor Best wrote: Maybe I should write awful.widget.layout.sameplace then which draws all its widgets onto the same space. I'd be grateful for test cases, because my experience with graph and progressbar widgets is nearly nil Hum, IIRC 'sameplace' algo was the default is no layout function was provided in the widget table. No? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: [Patch] Some fixes
At 1244317804 time_t, Marco Candrian wrote: then again, the C code seemed to have worked nicely. It's also a seperate file etc. - nothing to care for all the time? Not really. That's evolution: adapt or die. And that's how every part of awesome's code works. I'm sorry that people feel sad when their code disappears or is being modified and so, but awesome is still a moving target. Don't misread me, I don't want to be rude. I know you have paternity over most of this code, and I (and many people using this widgets) thank you for that. :-) For pbar and graph, I've been saying that their API is bad designed since the 3.1 version of awesome at least, as it's written in my 3.2 version TODO. And it has not been done by me, well, because it has been low prio until now. Until I felt the widget layout stuff coming from Gregor and that we did not need their things like draw on top of each other, and so that they could be rewritten in a couple of hours. Which I did. I've adapted the 2 widgets in most parts, so old forms can go away. There's no reason to keep this both in the C core. Not at all. Rewritting them in Lua make them: - better documented; - more maintainable; - more evolutive; - more error proof. And remove various code duplication, actual and coming. I actually meant the C code would be much faster compared to lua, Probably under extreme condition you are right. But I do prefer being pragmatic when I can. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Ferns will rule the world. signature.asc Description: Digital signature
Re: [ANNOUNCE] awesome 3.3 released
At 1244321281 time_t, Martin Stubenschrott wrote: Is there a roadmap wiki or something? I'd be nice to know which are the 3-4 most relevant things which are being worked on for 3.4? Not really, I keep my TODO private for no reasons. I used to use FS, but I'm not that comfortable with it actually. Congrats for the 3.3 release, hope to find debs for it soon to upgrade from my 3.2. Already in. :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: [Patch] Add a scale option to awful.widget.graph
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? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: awesome crashing after drawing the cursor
At 1244414696 time_t, Koncz László wrote: I've been using the awesome Awesome WM on Arch Linux (a git snapshot packaged as 3.3pre by an Arch User Community contributor), until about a week ago it wouldn't start any more. I've upgraded to 3.3 since, but the problem persists: awesome crashes right after drawing the cursor onto the blank screen. Here is some output from gdb, hope someone can tell what's wrong: (after running 'X :1' and 'DISPLAY=:1.0 gdb $(which awesome)') [run] Program received signal SIGILL, Illegal instruction. 0xb7bfd333 in ev_timer_start () from /usr/lib/libev.so.3 Brrr. Seems weird, but I think that's not related to awesome directly. I'd rather bet a problem on libev but no one never brought that to us. Can you try to recompile with more debug symbols? Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // In the Sixth Sense, Bruce Willis is dead. signature.asc Description: Digital signature
Re: Full moon bringgs trouble down in Brighton
At 1244462897 time_t, Andrei Thorp wrote:
(and is it possible to make the mailing list software properly set
reply-to so the reply button sends back to the ml? Is it just me
struggling with this?)
No. See http://liw.iki.fi/liw/log/2003-Enemies-of-Carlotta.html.
Any good MUA has a reply to list ('l' in mutt) anyway. :)
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// When I get sad, I stop being sad and be awesome instead. True story.
signature.asc
Description: Digital signature
Re: [Patch] Add a scale option to awful.widget.graph
At 1244483306 time_t, Uli Schlachter wrote: Both patches attached. :) Both pushed. Thanks! Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: Run Prompt Rewrite Ideas
At 1244633771 time_t, Andrei Thorp wrote: Partial credit to anrxc for ideas. He also said something like, Would be cool to make the run prompt one of the killer features of Awesome that now people can't live without -- like Naughty.. I tend to agree, we could do something spectacular here. I agree, everything is ready to write such a thing. But that's a big nice work to do. I'll be glad to provide insights to anyone wanting to work on this, as usual. Something that comes to mind here also is that most of the features I've mentioned above can actually be done with the current system by making several different prompts that handle things differently and then pressing that specific bind. This is okay, but it means you need like 6 different binds rather than a smart system. I'm sure the code that we have now is reusable to some degree though. awful's prompt stuff is easily reusable. Anybody can write a new module to write something GNOME Do style. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust no one. signature.asc Description: Digital signature
Re: [PATCH] unbash awesome-client
At 1244790869 time_t, Paweł Zuzelski wrote: One -r is enough. Sorry. I've attached a new version to this e-maill. Thanks, applied. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
Re: Segfault with 3.3
At 1244816834 time_t, Uli Schlachter wrote: So this must be in some C function from awesome. Sadly they are all marked static and thus don't emit any symbol, anyone got an idea how we could further narrow this down? Recompile with -O0 -fno-inline might help. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: [Patch RFC] Move some code for setting certain clients above = true from C into lua
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. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // There is nothing under this line. signature.asc Description: Digital signature
Re: [Patch RFC] Move some code for setting certain clients above = true from C into lua
At 1244984327 time_t, Uli Schlachter wrote: 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? I just took the drop part of your patch. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Tomorrow I was nothing, yesterday I'll be. signature.asc Description: Digital signature
Re: [Patch] Another highly disruptive change ;)
At 1245075560 time_t, Uli Schlachter wrote: I'll let the patch speak for itself... Pushed. :) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: [Patch] Another high-impact patch ;)
At 1245244499 time_t, Uli Schlachter wrote: 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: Nice. Works like a charm here, and I can see we win at least 0.0045% of memory. ;) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // In the Sixth Sense, Bruce Willis is dead. signature.asc Description: Digital signature
Re: [PATCH] removed WidgetList, name_func_link_t and related function
At 1245247677 time_t, Perrin Alexandre wrote: jd could you check this patch? I compiled/run awesome with it without any problems but I'm not confident with this patch since I don't know the awesome codebase well. It remove the WidgetList, name_func_link_t and related function and use tokenize.gperf instead. Good work, merged. Thanks! Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust me. signature.asc Description: Digital signature
[ANNOUNCE] awesome 3.3.1 released
Hi folks, A small update to fix a couple of bugs we found lately. It should fix the crash some people got with Gimp. Also fix a bad bug when trying to spawn with the prompt and others. And another little bug in text rendering. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD awesome version 3.3.1 has been released. It is available from: tar.gz: http://awesome.naquadah.org/download/awesome-3.3.1.tar.gz md5: a873af7831f7f63d9d655b227b5ea76f sha1: ad187a6a93a6e822afed14f3c60fe08471a3d980 tar.bz2: http://awesome.naquadah.org/download/awesome-3.3.1.tar.bz2 md5: 4d3508b7c72bedc38cab4b6f9d2f68cf sha1: a7bc3a969fed342c593d3f0974beeb22a07c18b7 number of changes - 4 shortlog Julien Danjou (3): spawn: fix crash with command starting with white space client: fix icon value on changes change codename Katherine McKinley (1): draw: fix NULL pointer passed to pango_parse_markup() diffstat awesomeConfig.cmake |2 +- client.c|1 + draw.c |4 property.c |2 ++ spawn.c |7 ++- 5 files changed, 14 insertions(+), 2 deletions(-) signature.asc Description: Digital signature
Re: [Patch] Yes, another Really Important Thingie (tm)
At 1245351455 time_t, Uli Schlachter wrote: JD: I'm not sure about the ev_ref()/ev_unref() stuff, is this necessary? Did I get it right? Seems OK to me. Pushed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // There is nothing under this line. signature.asc Description: Digital signature
Re: [Patch] Yes, another Really Important Thingie (tm)
At 1245345332 time_t, Uli Schlachter wrote: I can't live without submiting a patch, the result of this OCD is attached. Pushed. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
[fili...@debian.org: Bug#533749: awesome: naughty doesn't show notifications when timeout = timer delay]
- Forwarded message from Filippo Giunchedi fili...@debian.org -
From: Filippo Giunchedi fili...@debian.org
To: Debian Bug Tracking System sub...@bugs.debian.org
Subject: Bug#533749: awesome: naughty doesn't show notifications when timeout
= timer delay
Date: Sat, 20 Jun 2009 11:09:57 +0200
X-Mailer: reportbug 4.4
X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.2.5
Package: awesome
Version: 3.3.1-1
Severity: normal
Hi,
I noticed that notification (pun intended) doesn't show up (or better,
they are destroyed as soon as they show, a flicker can be seen
sometimes) when called within a timer every x and notification has a
timeout of y with y = x
In other words:
awful.hooks.timer.register(10, function ()
naughty.notify({text = foo, title = bar, timeout = 10})
end)
shows sometimes a flicker like the notification is displayed and then
die()s
while
awful.hooks.timer.register(10, function ()
naughty.notify({text = foo, title = bar, timeout = 11})
end)
correctly shows the notification.
thanks,
filippo
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29.4 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages awesome depends on:
ii libc6 2.9-13 GNU C Library: Shared libraries
ii libcairo2 1.8.8-2The Cairo 2D vector graphics
libra
ii libdbus-1-3 1.2.14-3 simple interprocess messaging
syst
ii libev31:3.6-1high-performance event loop
librar
ii libglib2.0-0 2.20.3-1 The GLib library of C routines
ii libimlib2 1.4.2-4+b1 powerful image loading and
renderi
ii liblua5.1-0 5.1.4-3Simple, extensible, embeddable
pro
ii libpango1.0-0 1.24.2-1 Layout and rendering of
internatio
ii libstartup-notification0 0.10-1 library for program launch
feedbac
ii libx11-6 2:1.2.1-1 X11 client-side library
ii libxcb-atom1 0.3.5-1utility libraries for X C
Binding
ii libxcb-aux0 0.3.5-1utility libraries for X C
Binding
ii libxcb-event1 0.3.5-1utility libraries for X C
Binding
ii libxcb-icccm1 0.3.5-1utility libraries for X C
Binding
ii libxcb-image0 0.3.5-1utility libraries for X C
Binding
ii libxcb-keysyms1 0.3.5-1utility libraries for X C
Binding
ii libxcb-property1 0.3.5-1utility libraries for X C
Binding
ii libxcb-randr0 1.3-2 X C Binding, randr extension
ii libxcb-render-util0 0.3.5-1utility libraries for X C
Binding
ii libxcb-render01.3-2 X C Binding, render extension
ii libxcb-shm0 1.3-2 X C Binding, shm extension
ii libxcb-xinerama0 1.3-2 X C Binding, xinerama extension
ii libxcb-xtest0 1.3-2 X C Binding, xtest extension
ii libxcb1 1.3-2 X C Binding
ii libxdg-basedir1 1.0.1-1implementation of the XDG Base
Dir
ii menu 2.1.41 generates programs menu for all
me
Versions of packages awesome recommends:
ii rlwrap0.30-1.1 readline feature command line
wrap
ii x11-xserver-utils 7.4+2 X server utilities
awesome suggests no packages.
-- no debconf information
- End forwarded message -
--
Julien Danjou
.''`. Debian Developer
: :' : http://julien.danjou.info
`. `' http://people.debian.org/~acid
`- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Patch] SHAPE stuff *again*
At 1245756208 time_t, Uli Schlachter wrote:
+size = width * height;
Seems unused.
+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.
+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.)
+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?
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... ? :)
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Don't give up.
signature.asc
Description: Digital signature
Re: [Patch] SHAPE stuff *again*
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? 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). Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: [Patch] SHAPE stuff *again*
At 1245766970 time_t, Maarten Maathuis wrote: Could the interface be simplified to leave the border related calculations on the C side? This was done for geometry to make the code clearer, is there any reason to not do that here? Because you can have border that are not regular I guess. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: [Obvious] ?
At 1245769715 time_t, Andrei Thorp wrote: Hello developer-types. I figured I'd ask first before I started doing this. Would it be fine for Obvious related stuff to be forwarded to this mailing list? I'm not sure it's a good idea. That would brings probably more than a ten thousand of users and some hundreds of mails by day on this list, and... No. Wait. Obvious you said? I read the Linux Kernel! No problem of course. ;) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: [Obvious] CONTRIBUTING Guide Pull Request
At 1245777325 time_t, Andrei Thorp wrote: Yeah, I always enjoyed how he resolved the e-mails on the mailing list rather than just merging silently. That's better than having the guy monitoring the branch always to see if his patch has been accepted, and also helps keeping track of forgotten patches. ;) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: [Patch] Make window_hasproto non-blocking (was: [awesome bugs] #543 - Split window_hasproto)
At 1245869654 time_t, Uli Schlachter wrote:
+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))
This is bad, but not your fault. xcb-util lack of from_reply function.
:-(
+{
+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));
Why do you p_new() ? Can't you just store the struct inside client_t
directly?
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Life is life. Lalalalala.
signature.asc
Description: Digital signature
Re: lua+pgrep
At 1245863677 time_t, Alex Cornejo wrote: The problem is that if we do os.execute(pgrep -f pyscript) from lua, it will always return a process, even if pyscript is not running. Actually, you can do os.execute(pgrep -f blablafoofoobar) and it will always find a process. Weird huh? Any ideas on why this is or how to fix it? No but this seems like a question for awesome mailing list, or even lua-l. :) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Tomorrow I was nothing, yesterday I'll be. signature.asc Description: Digital signature
Re: [Obvious] Pull Request: Pop-up Run Prompt Done
At 1245874466 time_t, Andrei Thorp wrote: OH, right! I promised to attach a video. Here it is. I've recorded a small video so to save everyone bandwidth, etc. It's about 700kb, and shows just the area around the run prompt. I'm still amazed by the things you can done with awesome. :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Trust no one. signature.asc Description: Digital signature
Re: [Patch] Make window_hasproto non-blocking
At 1245918857 time_t, Uli Schlachter wrote: BTW in my testing only my test app ever triggered this code and I don't really see any reason why someone would change their WM_PROTOCOLS, so I think this is less bad than it looks (Plus some other function in there already does the same *duck*). Yup, I'm not telling what you did is bad. It's just that if you ever goes by this path, you send a request/get a reply whereas the reply is already furnished by xcb-property. So this is suboptimal. (But xcb-util's fault, not yours). I tried the following: - protocols.atoms_len is obviously initialized to 0. Ack. - In property_update_wm_protocols(): If after the _reply() call .atoms_len is 0, _reply_wipe() the struct again and set it to 0 again. Just wipe it before calling reply? - In client_unmanage, only _reply_wipe() the struct if .atoms_len is != 0 I, btw, think that collecting resources shoud be done in _gc rather than in unmanage(). This seemed ugly. As you see, the problem is how to decide when to _reply_wipe() this struct. If you are fine with the '.atoms_len == 0' hack, I can implement it, but I didn't really feel comfortable with it. I'd say always wipe+p_clear before updating. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
This is review of patch #3.
At 1245932662 time_t, Gregor Best wrote:
-- vim:
filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/lib/awful/widget/init.lua.in b/lib/awful/widget/init.lua.in
index 6d4b51c..ae0cfb2 100644
--- a/lib/awful/widget/init.lua.in
+++ b/lib/awful/widget/init.lua.in
@@ -13,6 +13,8 @@ require(awful.widget.progressbar)
require(awful.widget.graph)
require(awful.widget.layoutbox)
+require(awful.widget.layout)
+
Drop the empty line above.
+for _, k in ipairs(util.table.ikeys(widgets)) do
I did not dig too far, but isn'y ipairs enough?
diff --git a/lib/awful/widget/taglist.lua.in b/lib/awful/widget/taglist.lua.in
index 00de38c..6117942 100644
--- a/lib/awful/widget/taglist.lua.in
+++ b/lib/awful/widget/taglist.lua.in
@@ -48,7 +48,7 @@ end
-- @param label Label function to use.
-- @param buttons A table with buttons binding to set.
function new(screen, label, buttons)
-local w = {}
+local w = { }
local widgets = { }
widgets.imagebox = { }
widgets.textbox = { [margin] = { [left] = 0,
diff --git a/lib/awful/widget/tasklist.lua.in
b/lib/awful/widget/tasklist.lua.in
index 0d0897c..883a12d 100644
--- a/lib/awful/widget/tasklist.lua.in
+++ b/lib/awful/widget/tasklist.lua.in
@@ -42,7 +42,7 @@ end
-- @param label Label function to use.
-- @param buttons A table with buttons binding to set.
function new(label, buttons)
-local w = {}
+local w = { }
local widgets = { }
widgets.imagebox = { align = flex }
widgets.textbox = { align = flex,
Remove that crap. :)
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Anna Molly! Anna Molly! Anna Molly!
signature.asc
Description: Digital signature
Re: [Patch] Make window_hasproto non-blocking
At 1245920036 time_t, Uli Schlachter wrote: 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) Pushed. Thanks so much. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Ferns will rule the world. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1245936340 time_t, Gregor Best wrote: Nope, because ipairs stops when it encounters a nil value. The following table would be iterated over completely: I got that, but why would you have nil value? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // When I get sad, I stop being sad and be awesome instead. True story. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1245947013 time_t, Gregor Best wrote:
Subject: [PATCH 10/12] systray: don't crap up on odd-sized windows
diff --git a/widgets/systray.c b/widgets/systray.c
index 0504be8..bd53ef6 100644
--- a/widgets/systray.c
+++ b/widgets/systray.c
@@ -32,32 +32,27 @@
#define _NET_SYSTEM_TRAY_ORIENTATION_HORZ 0
#define _NET_SYSTEM_TRAY_ORIENTATION_VERT 1
+typedef struct
+{
+/* systray height */
+int height;
+} systray_data_t;
+
Uhm, do we really need a struct for this?
I wanted to stay consistent with the rest of the widgets, but as the
number of widgets in the C core is reduced, that might not be neccessary
anymore. JD: comments?
Actually, this struct is reduced to an int anyway since it only got
that inside. So there's not point code-wise speaking to change that
(i.e. there's no optimization to make).
I'd say leave it as it is, as a struct, 'cause there's always a chance
we'll need to store something more than the height. So there's a chance
we will re-add a struct later. And its somehow consistent with other
widgets, so it's not a problem to me.
Subject: [PATCH 11/12] awful.util: add table.clone
That's a nice, small patch, it's a candidate for merging independent of
widget
layouts. :)
If you really need it :P
Subject: [PATCH 12/12] widget.layout.*: correctly stack nested layouts
A bugfix in the very first patch series? I'd propose to merge this stuff
with
the patches which added this code
Agreed, these patches are my current working branch, so expect some
splitting and reordering.
I hope I didn't annoy you too much.
Nope, your feedback is very much appreciated, as well as everyone elses,
thanks a lot :)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// And thinking so much differently.
signature.asc
Description: Digital signature
Re: lua+pgrep
At 1245953624 time_t, Alex Cornejo wrote: Any ideas? Namely I wanted to implement a startup module for awesome which has a list of programs you would like to run when awesome start, but only runs them if they are not already running (to avoid problems when restarting awesome for example). This is trivially implemented in bash, but I wanted to do it in lua. os.execute(exec pgrep...) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // This is the end of my signature. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1245952537 time_t, Uli Schlachter wrote: You could cast the height to (void*) and... *duck* Please, recall me, where did you say you were living already? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1245973156 time_t, Gregor Best wrote: I just found a place where it makes sense to have non-integer keys in the widget table: the titlebars. Rewriting those to make use of integer keys will be quite hard, as they make excessive use of integer keys and it will make the code even less readable and understandable. I'm currently trying to think of some way to stabilize the order of non-integer keys. Would a simple table.sort() be enough? I'm not really sure here... Comments and suggestions are greatly appreciated :) If you're willing to take this road, you need to define a rule on how to order keys. table.sort() on non-numeric keys would be enough and will return always the same result (of course) so it's safe. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman. signature.asc Description: Digital signature
C API documentation generator
Hi fellows, Currently in master, we generate documentation for the C-Lua API from the source code comments founds in the various C file. That works fine. However, starting with what I'm doing in 'next' branch, things are utterly broken. I wrote a more dynamic system, which makes the extraction of comments harder. For example you do not have a luaA_myclass_index() with all property listed. You rather add properties to a class structure, and then all objects of that class will that property. So it was easy to extract things from: /** My object. * \lfield name The name of the object. */ int luaA_object_index(lua_State *L) ... -- @class object @field name The name of the object. But it's harder from: /** Set timer's timeout. */ luaA_class_add_property(timer_class, A_TK_TIMEOUT, timeout, (lua_class_propfunc_t) timer_set_timeout, (lua_class_propfunc_t) timer_get_timeout, (lua_class_propfunc_t) timer_set_timeout); (A good and small example is timer.c from the next branch.) If I've a lot of time, I could probably restart hacking fake-lua-src.lua, but I unfortunately do not have enough time for that, nor the willingness. I'd like to hear suggestions from you guys about this. I still believe that keeping the C-Lua API documentation inside the C source files is a good idea, because it really prevents forgetting to document stuff. However, I might step back and restart writing documentation inside fake Lua files if I really do not find another solution. I dig a bit into doxygen output format, but I did not find something obvious. The XML is quite fine, but does not have everything easy to handle, and requires a lot of manual parsing. I though about gtk-doc, but it seems very GTK+ oriented. So ideas, suggestions or proof-of-concept are welcome. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // In the Sixth Sense, Bruce Willis is dead. signature.asc Description: Digital signature
Re: Awesome systray support in Java
At 1246404341 time_t, dante4d wrote:
So I step into isTraySupported():
public boolean isTraySupported() {
int wm = XWM.getWMID();
if (wm == XWM.METACITY_WM || wm == XWM.KDE2_WM)
{
return true;
}
return false;
}
For god's sake, how can this guys be so lame. That's fucking impressive.
*Anyway, I question myself how should I proceed?
*
1. *Probably, I could trick Java into thinking I run Metacity WM (which
is a nasty hack I'd say)...*
Yes, probably the simpler way.
2. *I can do something so the JRE code gets updated and recognizes
awesome as systray capable WM, but that's probably a long way to go. But I
believe it's the right one...*
I don't know which versino of JRE you use, but it might be possible that
it's fixed this 1.7. I heard that the reparenting problem is also fixed
in this version, but I did not test.
3. *I can use some other way to obtain SystemTray instance...*
Probably. In fact, if the check would return true, you probably get the
SystemTray.
4. Stop using Java.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Life is life. Lalalalala.
signature.asc
Description: Digital signature
Re: awful.client.swap.bydirection() calls mouse focus hook
At 1246476994 time_t, Romain Chossart wrote: Remarks : I think it is not relevant to call this hook, as we get a random behaviour depending on the location of the mouse. However, it may be the desired effect (but it is unlikely to be the case imho). I know about this, it's on top of my TODO. Enter and leave events are not ignored when moving windows. I think it'd be easy to fix, but I'm working on other things right now. I'll be done for 3.4 anyway. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
Re: Crash when launching anything from the menu
At 1246499597 time_t, Mike Kelly wrote: Whenever I try to click on anything in the launcher menu, awesome goes down hard. On my console, I see this message: Mind testing with 3.3.1? Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // There is nothing under this line. signature.asc Description: Digital signature
Re: [PATCH] Make awful.widget.graph work with zero values
At 1246635250 time_t, Uli Schlachter wrote: Today I *finally* noticed that one of my graphs broke. The graph displays the disk I/O and it looked like my disk was rather busy. Instead of fixing my disk usage, I wrote a patch for awesome. Pushed. Thanks. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Anna Molly! Anna Molly! Anna Molly! signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1246495186 time_t, Gregor Best wrote: diff --git a/widget.h b/widget.h index f2ca048..e9d9e7e 100644 --- a/widget.h +++ b/widget.h @@ -73,7 +73,7 @@ struct widget_node_t widget_t *widget_getbycoords(orientation_t, widget_node_array_t *, int, int, int16_t *, int16_t *); void widget_render(wibox_t *); -void luaA_table2widgets(lua_State *, widget_node_array_t *); +int luaA_widget_userdata_new(lua_State *, widget_t *); void widget_invalidate_bywidget(widget_t *); void widget_invalidate_bytype(widget_constructor_t *); I merged patches 1, 2, 6, 7, 8 and 9. 1 was amended without the + line of the diff above. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1246971364 time_t, Maarten Maathuis wrote: I suggest being consistent with the other code and push the geometry to lua with borders included. Like the client code does, or change that, at least be consistent. Well, I suggested to not push any geometry, which seems far better. No? :) Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1247090952 time_t, Gregor Best wrote: It does, because it removes the calculation of the actual text position from C. Without that, widget_geometries isn't fully functional, as text doesn't get drawn where the layout function decides it should. Okay. Premature optimization is the root of all evil :) I can't disagree. +lua_insert(globalconf.L, lua_gettop(globalconf.L) - 1); +lua_pop(globalconf.L, 1); I think we said that's totally noop, no? [...] It is not. lua_insert() needs an absolute stack position, which is why the lua_gettop() is used there (-1 would be a relative position). These two lines exchange the two top stack elements and then remove the new top, effectively removing the second element from the top (which is the layout function, it's not needed anymore and it would taint the stack if it stayed on top of it). Yeah, actually I reread your code, and it can be simplified to: lua_insert(L, -2); lua_pop(L, 1); Which also can be simplified to: lua_remove(L, -2); AFAICT. I'll do. Basically, we get the size we want the systray to be drawn at upon drawing the tray, thus removing the query to the xcb_get_geometry function. As all windows embedded in the systray are squares, their size is equal to their height, so we simply force the size to be wibox_height * n x wibox_height, where n is the number of embedded windows, instead of deriving it from the largest embedded window (which, for example in the case of wicd, would be 200x200, way too much for one window on a regular wibox). I'm not sure you can assume all systray icons are square. But well, I guess you have a pragmatic approach, so it should work right now. If something happens, we'll know and we'll fix it. :) Totally. This would ease up the implementation quite a bit, I'll do it. I'm glad that even ease your work. :-) It does indeed brake resizable imageboxes, and frankly, I have no idea how we could replace that. I think the best idea would be to have things settle down and then take a closer look at it. I agree. Would be very nice :) This bastard does not sounds interested. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1247096479 time_t, Gregor Best wrote:
The layouts now
use the bounds parameter only to determine the available width and
height they can put their widgets into, the X and Y coordinates are
modified by the calling functions. (A much cleaner approach, why didn't
I think of that? :)
Don't know. Why do you keep this bounds?
You seems to only use them to check if the widgets does not try to
render outside the wibox/layouts. That's not the work of the layout.
If the widget, even packed, does not fit, well, too bad, it will be
drawn outside of the wibox, i.e. not shown.
Subject: [PATCH 1/9] widgets: add bool widget_geometries(wibox_t *)
@@ -276,7 +315,6 @@ widget_render(wibox_t *wibox)
for(int i = 0; i widgets-len; i++)
if(widgets-tab[i].widget-isvisible)
{
-widgets-tab[i].geometry.y = 0;
widgets-tab[i].widget-draw(widgets-tab[i].widget,
ctx, widgets-tab[i].geometry,
wibox);
}
You can kill the brackets.
--- a/widgets/graph.c
+++ b/widgets/graph.c
@@ -148,13 +148,13 @@ graph_plot_get(graph_data_t *d, const char *title)
}
static area_t
-graph_geometry(widget_t *widget, screen_t *screen, int height, int
width)
+graph_geometry(widget_t *widget, int screen)
{
area_t geometry;
graph_data_t *d = widget-data;
geometry.x = geometry.y = 0;
-geometry.height = height;
+geometry.height = d-width;
geometry.width = d-width;
Seems wrong to me. Why the graph would be a square?
Subject: [PATCH 2/9] widgets: get rid of align attribute
OK.
Subject: [PATCH 3/9] systray: don't crap up on odd-sized windows
OK.
Subject: [PATCH 4/9] awful.widget: add layouts
OK.
Subject: [PATCH 5/9] awesomerc.lua: add support for widget layouts
OK.
Subject: [PATCH 6/9] naughty: add support for widget layouts
OK.
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// My root password is
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1247134192 time_t, Uli Schlachter wrote: I guess the flex layout needs the bounds and since one can nest layouts, the other ones have to keep that bounds table up-to-date, too... I guess Make sense. I take back what I said. It's fine finally. :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1247130536 time_t, Julien Danjou wrote:
--- a/widgets/graph.c
+++ b/widgets/graph.c
@@ -148,13 +148,13 @@ graph_plot_get(graph_data_t *d, const char *title)
}
static area_t
-graph_geometry(widget_t *widget, screen_t *screen, int height, int
width)
+graph_geometry(widget_t *widget, int screen)
{
area_t geometry;
graph_data_t *d = widget-data;
geometry.x = geometry.y = 0;
-geometry.height = height;
+geometry.height = d-width;
geometry.width = d-width;
Seems wrong to me. Why the graph would be a square?
I just wait for clarification on this point from Gregor.
I encourage people to test the patch set. Then, it's more than probable
that everything will be merged.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// When I get sad, I stop being sad and be awesome instead. True story.
signature.asc
Description: Digital signature
Re: [Draft] Introduction of Widget Layouts
At 1247139117 time_t, Uli Schlachter wrote: Where exactly is that endless loop? I can't seem to find it. And frankly said, if you use looping tables for your widgets, you shouldn't be surprised :P You get what you deserve.. ok, you win Clearly. Somehow I wonder if luaA_isloop() is even worth keeping around. If you do bad stuff, you're screwed. We're not going to check everything the use does in Lua. We're not a sand box. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. signature.asc Description: Digital signature
