Closing this list.
Hi, Due to the very low traffic this list had in the last months, I'm now closing it in favor of the general list awes...@naquadah.org which ought to be enough. Cheers, -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature
No more notifications from FlySpray
Hi there, As I plan the merge of this list with the general awesome user mailing list, I've disabled FlySpray notifications on this list. Happy hacking, -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signature.asc Description: PGP signature
awesome moving to GitHub
Hi there, Long time now see! I'm pleased to announce that awesome is moving to GitHub for its code and issue hosting starting from now. The code is now hosted at: https://github.com/awesomewm/awesome The organization also has a few other repositories, such as the Web site, check https://github.com/awesomeWM The bug tracker (FlySpray) has been set into a partial read-only mode, e.g. it's not possible to open new bug on it, but you can still comment the old ones. New issues should be opened on GitHub at: https://github.com/awesomeWM/awesome/issues I don't think it's necessary to precise that you can also open pull requests instead of sending patches on the awesome-devel mailing list. Let me know if you have any question and/or suggestions. Happy hacking, -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc Description: PGP signature
Re: autopkgtest for lua-lgi (and awesome)
On Mon, Sep 16 2013, Enrico Tassi wrote: Hi Enrico, Ciao, I'm adding to lua-lgi some tests to be run by autopkgtest. Given that awesome uses lua-lgi, It would be nice to make lua-lgi run some awesome reletaed tests if any. In this way an upload of lua-lgi that compiles, but breaks awesome badly, could be easily spot. Does awesome come with some tests that can be run with xvfb-run? Not as far as I know. If not, would it be possible to write a few of them (even just starting the wm and doing something that requires lua-lgi would be ok). Probably, I'm Cc'ing the development mailing list to this purpose. -- Julien Danjou # Free Software hacker # independent consultant # http://julien.danjou.info signature.asc Description: PGP signature
Re: Patches for the 2.3 branch
On Fri, May 24 2013, Gregor Best wrote: Attached is another patch that fully changes the default mwfact from .5 to .618. I seem to have missed quite a few places in the first iteration. Pushed. -- Julien Danjou -- Free Software hacker - freelance consultant -- http://julien.danjou.info signature.asc Description: PGP signature
Re: Patches for the 2.3 branch
On Thu, May 23 2013, Gregor Best wrote: Of course. The attached version of the patch fixes that. I have also attached another patch that sets the default mwfact for new tags to ~0.618, which is the inverse of the golden ratio. IMHO this yields a more pleasant split between master and slave windows. It's purely cosmetic though. Merged. Of course if users start complaining about this change, I'll point at you. ;-) On Thu, May 23 2013, Gregor Best wrote: ... and because I'm on a run, yet another patch. It enables users to use -1 as an alias to all screens when running a UICB. Also, it replaces a usage of atoi with strtol and strtok with strsep, which are similar functions that allow more fine grained error detection and (with strsep) are implemented cleaner in most libc implementations. Man, UICB, I forgot about those. Now I feel like 2007 again. Pushed. -- Julien Danjou # Free Software hacker # freelance consultant # http://julien.danjou.info signature.asc Description: PGP signature
Re: Patches for the 2.3 branch
On Tue, May 21 2013, Gregor Best wrote: As threatened on IRC, here's a bunch of patches to 2.3. I didn't yet get around to adding a systray widget, but that will come. Most of the patches are fairly self explanatory, I guess, but as always, suggestions and questions are welcome :) Pushed, except: Subject: [PATCH 5/6] Replace obsolete XKeycodeToKeysym I wonder if you shouldn't change configure.ac, since I don't think we used to depend on Xkb. -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc Description: PGP signature
Re: PATCH: Fix debug.dump
On Fri, Aug 31 2012, Alexander Yakushev wrote: A little fix, bug was introduced when we all moved away from using modules. Thanks, pushed. -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgp1RlqQA5Mqs.pgp Description: PGP signature
Re: [PATCH] Remove incorrect comment from awesomeConfig.cmake
On Tue, Aug 28 2012, Steven Oliver wrote: The attached patch is pretty vanilla. The comment states that CMake will lie about which version of Lua it found. That is no longer the case. Thanks, applied to master and 3.4 branches. -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgpYkW0ka8NRG.pgp Description: PGP signature
Re: Lets get rid of awsetbg?
On Mon, Jul 23 2012, Uli Schlachter wrote: So this means I get to have some fun with wallpapers? No one objects? Since I won't have the needed time for this, who wants to open a feature request and get blame for all the time I'll have to spend on implementing this? :-) https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1024 Well, X11 only provides a single root window, so technically there is just a single, big wallpaper. People also have asked for a signal when the mouse pointer moves between screens and that's not easily possible either. (Yes, it's not really hard to implement, but... dunno) So no per-screen root objects, please. I see what you mean. I forgot that our `screen' are split in the Xinerama/XRandR case. Forget what I say. ;) And for inheriting from window objects: - border_color, border_width, opacity, struts, type properties all don't make sense for the root window - button::press/::release would require grabbing all input, I guess, which would render the keyboard unusable. So nope. - mouse::move could make sense Doesn't look like inheriting root from window would make sense to me. Actually it does, the problem is that the window class should not have border, opacity, struts… etc. If you're curious, I did this in the `next' branch years ago, it's still there. The model was: - window: .focus() .geometry() .isvisible() .raise() .lower() .grab_keyboard() .ungrab_keyboard() .grab_button() .ungrab_button() .grab_key() .ungrab_key() .window .focusable .cursor .parent .size_hints .x .y .width .height .content .movable .resizable .visible .layer - ewindow, for extended window, inherits from window and adds: .struts() .tags() .opacity .border_color .border_width .sticky .ontop .above .below .minimized .fullscreen .modal .maximized_horizontal .maximized_vertical - wibox, probably the same as drawin, inherits from ewindow and adds more stuff - client, inherits from ewindow and adds more stuff `root' is an instance of the window class and a property of all screens. But actually screens always return the same root so for i from 0 to screen.count() then screen[0].root == screen[i].root. -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgpcMQ7Vsb9YS.pgp Description: PGP signature
Re: [PATCH] wallpaper.c: capability from within Awesome
On Tue, Jul 24 2012, Arvydas Sidorenko wrote: Hi Arvydas, This is a very basic implementation of setting wallpaper from within Awesome. It uses libX11 and imlib2, thus everything works out of the box. The public function is set_wallpaper(), which currently just scales it to full screen. That's cool, but why didn't you implement this on top of root.wallpaper() function and using XCB? :( -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgpi4wcCScZkh.pgp Description: PGP signature
Re: [PATCH] wallpaper.c: capability from within Awesome
On Tue, Jul 24 2012, Arvydas Sidorenko wrote: I took a look into XCB reference and that's right, silly move to use Xlib from me. But that introduces another issue - imlib2 requires Display and Visual data structures from Xlib. Anyone for the task to port imlib2 to XCB? :P Otherwise cannot think of another alternative which would be flexible, small in loc and already available with Awesome installation. Uli said: root.wallpaper(gears.surface(/path/to/an/image)) So you should expect a Cairo surface as first argument. You can then use it to paint directly on the root window pixmap. No need to use Imlib2 to draw. -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgp1wFuPfA3ro.pgp Description: PGP signature
Re: Lets get rid of awsetbg?
On Mon, Jul 23 2012, Ignas Anikevicius wrote: 1) Write some C code which would be integrated in awesome capi and it would just do some basic setting via a single command. 2) Write some C code and LUA bindings and write all the logic in LUA. This would mean, that it might be possible to have something more interesting. E.g. different wallpapers on different tags/screens and even more. Can we use lgi for that? As far as I understood, it's impossible but I might be wrong. If we choose the option B2 option, then awesome will be even more awesome... but the question is whether having bg setter logic inside awesome is needed? The API should be very simple: add an .background property to all screen objects that can be set with any instanciated image. screen[0].background = image(/path/to/an/image) And just write the C code setting the wallpaper when .background is modified, and returning a new image if something wants to read the background. That should not be hard. -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgpu0sSwfjxTS.pgp Description: PGP signature
Re: Lets get rid of awsetbg?
On Mon, Jul 23 2012, Uli Schlachter wrote: Or, even simpler: root.wallpaper(gears.surface(/path/to/an/image)) Yeah, I didn't know we have a read function for this. I don't know how much C code would be needed for implementing this. I think that it could need opening a second connection to the X11 server. Dunno if there is some spec for the properties part of this (I think I went with _XROOTPMAP_ID just because it worked for me). If someone would try to set an image with the wrong dimensions, I'd choose the simple route and just error out. Which reminds me, there is no simple lua API for getting the root window's geometry... I think hacking luaA_root_wallpaper() to do this is the good way to do so. I just poked at the source code quickly, but I had the feeling that root should be actually screen.root, an object inheriting from `window'. That does not seem to be actually the case, that's sad, because I think it would makes sense, even for key/button bindings and in our case for getting geometry. WDYT Uli? -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgpL6mY1R7boy.pgp Description: PGP signature
[ANNOUNCE] awesome 3.4.13 released
Hey folks, A new awesome arrives! This is mainly to fix a regression introduced while fixing FS#1011 in v3.4.12. Happy hacking, -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info awesome version 3.4.13 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.4.13.tar.xz md5: 8449fde51c08ca69fe4c5bb831b3c618 sha1: 6127ba6048cb538b6c318d1f5d9926fa067492c1 tar.bz2: http://awesome.naquadah.org/download/awesome-3.4.13.tar.bz2 md5: 2c383f63f64c7a41facc7845886d2f7d sha1: e1f0827501a6d245db01a6296ea62493521103e2 number of changes - 6 number of commiters --- 3 shortlog Julien Danjou (3): Remove PREFIX, use CMAKE_INSTALL_PREFIX Simplify client focus code change codename Uli Schlachter (2): xerror: Print numeric infos about the error Revert Focus history: Don't ignore unfocusable clients Sébastien Luttringer (1): awful.titlebar use height not width diffstat awesomeConfig.cmake | 21 +++-- client.c | 22 ++ client.h |1 - event.c |6 -- lib/awful/client.lua.in | 10 ++ lib/awful/titlebar.lua.in |2 +- 6 files changed, 24 insertions(+), 38 deletions(-) pgpVH5z6FFa1y.pgp Description: PGP signature
Re: [PATCH] Yet another lua call without prefixed module
On Sun, Jun 24 2012, Arvydas Sidorenko wrote: Pushed. -- Julien pgprIOUssksWo.pgp Description: PGP signature
Re: Lua 5.2 compatibility pull request
On Fri, Jun 15 2012, Arvydas Sidorenko wrote: Here are the changes of lua code to make Awesome compatible with lua 5.1 and 5.2. I've been running it on both lua versions and on default settings haven't noticed any instability. If you are using vicious you probably will notice some funny things going on after a while, so the best is to disable the plugin for the moment if you use lua 5.2. Although I'll take a look at it when I'll have time. Looks good after a quick glance, except that it breaks the documentation building because luadoc isn't going to understand this. This is a real problem IMHO, so we should either fix luadoc, switch to something else, whatever works so we can keep having documentation generated. -- Julien pgpxqkdw1PtUb.pgp Description: PGP signature
Re: Lua 5.2 compatibility pull request
On Fri, Jun 15 2012, Uli Schlachter wrote: So everything but the Ported foo to lua 5.2-commits are OK? Shall we cherry-pick some of them? (Assuming that Arvydas doesn't mind us breaking his git history) That's only leave: Replaced deprecated math.mod to math.fmod Changed unpack in portable way which are good, indeed, we can cherry-pick them both. -- Julien pgpRTKqV7pZSd.pgp Description: PGP signature
Re: Lua 5.2 compatibility pull request
On Tue, Jun 12 2012, Arvydas Sidorenko wrote: Wrapped luaL_register Not merged, as you say in the commit message, there's a TODO point and I'm not sure it works correctly then. That function has three commits which you have recognized. They suppose to be squashed, but I didn't know about rebase feature in git. From now on will provide cleaner patches :) I attached a squashed patch though. I merged it. FYI, use git format-patch, it's better to generate patch file. :) Thanks! -- Julien pgpA75nML8J65.pgp Description: PGP signature
Re: Lua 5.2 port
On Mon, Jun 11 2012, Arvydas Sidorenko wrote: I ported Awesome to Lua v5.2. The fork is here: https://github.com/Asido/AwesomeWM To please your eyes here: http://img88.imageshack.us/img88/1704/wootk.png Be aware that up to this point the repo hold C code changes only. I haven't pushed Lua changes since it's a patch of 4300 lines hack, which was done entirely for educational purpose. I'll spend the next day or two rewriting everything from scratch, then will talk what's good what's bad. Congrats Arvydas, it's a cool job you did. Is your code compatible with Lua 5.1? At least, can we still build awesome with Lua 5.1 with that? -- Julien pgpQhKWDJJ6HB.pgp Description: PGP signature
Re: Lua 5.2 port
On Mon, Jun 11 2012, Arvydas Sidorenko wrote: Keeping Lua 5.1 compatibility is absolutely crucial since making Awesome v5.2-only would be pointless and harmful. Every single push was tested to make sure nothing got broken. That's really fantastic then, especially if you did several commits that don't break everything. You get awesome-bonus-points. I am running Awesome from my git and lua 5.1 since the beginning and not seeing anything wrong. The lua code is different though - the WM is a little broken. But it was expected and I'll fix it. Does that mean we can keep the Lua code running on 5.1 and 5.2 in the end? -- Julien pgpCUv29yVc9s.pgp Description: PGP signature
Re: Lua 5.2 port
On Mon, Jun 11 2012, Arvydas Sidorenko wrote: I'll make sure you do :) As a matter of fact the current patches could be merged right now. All changes are pretty much making Lua embedding in compatible way. The change you will notice is that Awesome starts to compiles having Lua 5.2 Then feel free to send them here for a pull request. :) -- Julien pgpki85AfQ2rV.pgp Description: PGP signature
Re: [PATCH] Get mousegrabber running state
On Wed, Jun 06 2012, Sébastien Luttringer wrote: Add a function mousegrabber.isrunning() which return a boolean state of mousegrabber Pushed, thanks! -- Julien pgpPWcgspbixA.pgp Description: PGP signature
Re: [PATCH] Get keygrabber running state
On Wed, Jun 06 2012, Sébastien Luttringer wrote: Add a function keygrabber.isrunning() which return a boolean state of keygrabber Pushed, thanks! -- Julien pgpnjGqN6QOqj.pgp Description: PGP signature
Re: [Patch] Switch from oocairo/oopango to lgi
On Sun, May 27 2012, Uli Schlachter wrote: What do others think about these patches? Any major objections which I will have to ignore when I push? :-P I feel like riding a magical sugar pony. -- Julien pgp5OhnNMzSEV.pgp Description: PGP signature
Re: awesome --version with lua --version
On Mon, Apr 23 2012, dodo wrote: with the perhaps upcoming port to lua 5.2 i thought it would be helpful for future debugging to see the lua version awesome was build with. It'd be better to say Compiled against Lua %s. -- Julien pgpIVwlv6TgYN.pgp Description: PGP signature
Re: awesome --version with lua --version
On Mon, Apr 23 2012, Gwenhael Le Moine wrote: What is printed if lua has been upgraded but awesome wasn't recompiled after? The same thing, that's way I wrote Compiled against Lua %s not Running with Lua %s. And is it the role of awesome to give lua's version? I'd say that this doesn't belong here. At worst the bug reporting guidelines should mention to include the result of lua -v . Except that, in theory, your awesome can run with a different version that the lua from your $PATH. :-) Unfortunately, I don't see any function that can be called from withing awesome to retrieve Lua version awesome is running with. :( -- Julien pgpISACr78tPn.pgp Description: PGP signature
Re: awesome --version with lua --version
On Mon, Apr 23 2012, dodo wrote: any improvements/critics for the new patch? :) Now you're saying Compiled against but you're showing the version used to run awesome, not to compile. :-) -- Julien pgprvBuBzDsMZ.pgp Description: PGP signature
Re: Spawning processes, handling their output non-blocking and separated by stdout/stderr
On Wed, Apr 04 2012, Uli Schlachter wrote: people occasionally complain about awesome awesome.spawn() (and the wrappers awful.util.spawn() and spawn_with_shell()). They want more control over the argument array that is passed to the new process. They want to handle stdout and stderr individually. They want all of this to be non-blocking, so that their WM doesn't freeze. They want the child's exist code. And the coder heard their complaints. But he didn't want to write any code. So he asked the almighty Google. Anyway, attached is a sample program which does all of the above. This needs lua-ev[0] and luaposix[1]. lua-ev handles the non-blocking part (and accidentally integrates with awesome's main loop) while luaposix let's us set up pipes, fork and execute a process. Actually, I lied. To make lua-ev work with awesome, it needs a simple patch[2]. However, I hope that gets resolved eventually. So now that I mentioned this, let's see what cool stuff you come up with. Actually, I write this mail mostly as a reminder to myself, but whatever. Cheers, Uli P.S.: Yes, POSIX is not trivial, nor is libev. So what? :-P [0] https://github.com/brimworks/lua-ev [1] https://github.com/rrthomas/luaposix [2] https://github.com/psychon/lua-ev/commit/7580fb759b8664f6598199eed4ac0c9d70c4352c This is… awesome, Uli. I saw you did a pull requests, so eventually this will end into lua-ev. What would be cool is that we provide sugar based on your example in awesome 3.5. I've opened #985 to remind us of that. Thanks for this :) -- Julien pgp9euVsJXe2R.pgp Description: PGP signature
Re: awesome 3.5?
On Sun, Mar 25 2012, Uli Schlachter wrote: Wow. It's been three years and now our overlord jd wants to make people unhappy with their broken configs again. :-) Maybe we could limit that this time? :) AFAIR it was you who taught me that titlebars are our big release blocker. Now that Emmanuel is working on that (thanks!), I guess we could start thinking about what we need. Cool. From the top of my head, I remember that the current --no-argb stuff is an ugly hack to hide the fact that my X11 driver is buggy with ARGB visuals. https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=837project=1 Can I have a explanation/pointer to this all ARGB stuff? I always hear about it but I've no idea of what this is about. :) So I guess I'd be fine with a release soon. (Where soon depends on when I can get my bachelor thesis done) You don't need that! :) P.S.: Where does this sudden release interest come from? Could it have anything to do with me turning cairo-xcb into a supported cairo backend? No, I even didn't know about that, that's a terribly great news. Is it official yet? -- Julien pgpyOCVcnkfqV.pgp Description: PGP signature
Re: [PATCH 1/3] Remove encoding=utf-8 from Vim modelines
On Sun, Mar 25 2012, cmt...@gmail.com wrote: Pushed. -- Julien pgpPnsb8sTkO3.pgp Description: PGP signature
Re: awesome 3.5?
On Mon, Mar 26 2012, Uli Schlachter wrote: Now what I did for awesome: I didn't feel like adding a special case for ARGB visual windows, hence I made the WM always use an ARGB visual for its window (and the special case disappeared!). However, now I hit bugs in my video driver where parts of the screen wheren't repainted properly after a tag switch. So I made awesome use the default visual again and opened FS#837 to remind me of how much failure X11 is made of. :-( Got it, thanks for the explanation! I understand that you tried to did the Right Thing with your implementation, but really it's acceptable IMHO to implement a special case if the generic way triggers a bug in some video drivers. I mean, we just add some comment to say some days when X is fixed we should do this in a generic way and go with it. I don't think the special case would be such a burden. -- Julien pgpJ4GfFPWBFa.pgp Description: PGP signature
Re: Shadows below the titlebar
On Tue, Feb 28 2012, dodo wrote: Some time ago I implemented titlebars for git/master, using them ever since. https://github.com/dodo/uzful/blob/master/widget/titlebar.lua If somebody is interested I can clean up the code a little bit further and provide a patch for upstream. Would be nice. I'd like to have Uli opinion on that. :) -- Julien Danjou pgpRqrJ16oYFA.pgp Description: PGP signature
Re: Need help submitting menubar
On Fri, Feb 17 2012, Uli Schlachter wrote: Well, I can contact Antonio, but what exactly should I ask him to do? Suppose if he doesn't want to license his work under GPL, does it mean that I can't reuse his code? Correct. What if he licenses it under BSD, for instance? Hm, good question. I'd ask jd on his opinion, but it would certainly complicate things. IANAL, but we can probably fork the code and license it under GPL, because BSD allows that IIUC. :) Anyway, BSD or not, we can also just put the code and update COPYING to say that this file is BSD. It doesn't really matter as long as the license is GPL compatible. -- Julien Danjou pgpOuozZwzXeC.pgp Description: PGP signature
Re: Ideas for improving awful.remote
On Tue, Dec 06 2011, Rob Hoelz wrote: 1) Wrap remote code in pcalls Currently, non-parse errors are undetected by awesome-client; you get no output indicating anything went wrong unless you examine the log. This sounds like a good idea, indeed. 2) Handle all return values Currently, awful.remote only handles return values up to the first nil in the list of return values. This is potentially problematic since the typical Lua error idiom is to return nil and then an error message. Ack. 3) Improve presentation of return values If I return a value to awesome-client, I get output resembling 'string hi'. I think this could be improved. Surely. What's your proposal? 4) Evaluate remote code in a custom environment awful.remote runs code in the default environment, so this could spell trouble for anyone who tries to run client = nil via awesome-client. I think that a certain amount of risk is understood when using awesome-client, but if we can easily protect users from silly mistakes, I believe we should. Also, if I'm using awesome-client to work with values, I'd rather they not contaminate the global Lua environment. I'm not sure this is really needed neither a good idea. I mean, you should be able to do it. I'm not sure what are the common uses cases for awesome-client, but I think it has to use pre-defined variable containing various objects the user wants to manipulate. 6) Add tab completion to awesome-client This one seems self-explanatory to me. That'd be great, and seems like a nice challenge indeed. :) -- Julien Danjou pgpokI6740Fl4.pgp Description: PGP signature
Re: [PATCH] italian translation
On Thu, Dec 01 2011, Gianluca Fiore wrote: I noticed the manpages lacked the italian translation so I added one. Please review, thanks. Pushed. Grazie mille. -- Julien Danjou pgpEWpJKnIx4R.pgp Description: PGP signature
Re: [ANNOUNCE] awesome 3.4.11 released
On Wed, Nov 23 2011, Adrian C. wrote: What happens if you don't require naughty. Is it gracefully handled? It's in the default rc.lua, so if you don't require naughty, you are supposed to delete that code too. -- Julien Danjou pgpG3gZ1mop80.pgp Description: PGP signature
Obvious and ALSA
Hi, I just hit a bad bug. awesome would not start! I discovered that this was caused by obvious. I use the volume_alsa widget, which runs amixer. But I had pulseaudio installed. And doing a: xtrace amixer -c 0 -- get Master showed that the pulseaudio plugin of alsa was run and tried to connect to the X server to fetch some atoms. The problem is that while startup, awesome is grabbing the X server. Therefore, the awesome startup was totally blocked. Removing pulseaudio resolved the problem for now, but I think we should do something in obvious to avoid that, like unsetting the DISPLAY environment variable. WDYT? -- Julien Danjou pgpTkU4e6fqu6.pgp Description: PGP signature
Re: Obvious and ALSA
On Fri, Oct 21 2011, Daniel Silverstone wrote: On Fri, Oct 21, 2011 at 03:16:40PM +0200, Julien Danjou wrote: Removing pulseaudio resolved the problem for now, but I think we should do something in obvious to avoid that, like unsetting the DISPLAY environment variable. Why not simply defer the first update of the widget to give awesome a chance to finish starting up? Why not, I'm just not sure it's easier. :) -- Julien Danjou pgprIJz97akBR.pgp Description: PGP signature
Re: Obvious and ALSA
On Fri, Oct 21 2011, Uli Schlachter wrote: @jd: Are you on the 3.4 branch or is your git clone just too old? Did I break your config badly enough to make you switch to 3.4? :-) Yeah, I'm on 3.4 for a long time now. :) -- Julien Danjou pgpuD11oBLIWw.pgp Description: PGP signature
Re: Different behavior of lua_setmetatable with luajit
On Mon, Oct 10 2011, Uli Schlachter wrote: This appears to try and set the metatable for the LIGHTUSERDATA type. (Remember light userdata don't get their own metatables in Lua 5.1) Why remember? After I got the other reply, I checked lua's doc and I couldn't find this anywhere. […] IMHO this fact is a little hidden inside lua's doc and apparently neither me nor JD knew this. Clearly, I had no idea of this. And I probably never discovered it because IIRC in awesome we only use lightuserdata for one type of object. So I never saw that the metatable was global for all lightuserdata types. :) My current plan would be to turn this into a real userdata which just contains a pointer to the screen_t* and add an __eq entry to the metatable so that comparing screens still works. That's the best plan. :) -- Julien Danjou pgpniWsemanj3.pgp Description: PGP signature
Re: [awesome bugs] #905 - urxvt in 32-bit color depth doesn't have active window border.
On Wed, May 18 2011, Uli Schlachter wrote: So finally you admit it? How come? It was a trap, wasn't it? -- Julien Danjou ❱ http://julien.danjou.info pgp3ayOdQ6NwE.pgp Description: PGP signature
Re: [ANNOUNCE] awesome 3.4.10 released
On Mon, May 16 2011, Uli Schlachter wrote: I want to change everyone who send a patch and contributed his little improvement. But change into what? -- Julien Danjou ❱ http://julien.danjou.info pgpDXHE4x13XP.pgp Description: PGP signature
Re: Next awesome release
On Tue, May 10 2011, Uli Schlachter wrote: it's been a while since the last awesome release and some interesting stuff has happened. The more important stuff here IMHO is a problem with newer cmake and the xcb-util split-up. Awesome didn't build with cmake 2.8.4. More people will run into this problem and we should get the fix out: This has been already a problem in Debian, indeed. The other big thing is Arnaud's work on xcb-util. He sent a patch for porting awesome to the new API. However, since this change isn't backwards compatible (and there was no new awesome release in a while), I'd like to have a new awesome release first (it already is in master since today). Of course, there are lots of other nice features (rules: allow defining exceptions to a rule - except, and except_any) and fixes (naughty: escape title too). What do you think? Any known issues which should be fixes first? Any last-minute patches that should get in? Does a next-weekend-release sound reasonable? Sounds good to me. I'm planning it for around this week end if that's ok for everybody. -- Julien Danjou ❱ http://julien.danjou.info pgpbBhtkFkGX3.pgp Description: PGP signature
Re: one line patch for default make target and prefix + naughty.notify work
On Thu, Jan 27 2011, James Pike wrote: Simple patch.. lets you do.. Did you forget the patch? -- Julien Danjou ❱ http://julien.danjou.info pgpYWD1lcERvf.pgp Description: PGP signature
Re: Awesome - Czech localization
On Sun, Jan 02 2011, Pavel Fric wrote: if there would be any localization support in Awesome GUI - I am offering my effort to translation of Awesome texts into Czech language. Just send me the file. (.po or .ts or .txt or ?) No, there's no localization, because I'm not sure it's really relevant. -- Julien Danjou ❱ http://julien.danjou.info pgpG2qk2NkUbK.pgp Description: PGP signature
Re: The joy of titlebars in git/master
On Sun, Dec 19 2010, Uli Schlachter wrote: However, I'd propose to restrict reparenting to drawin and all drawins without a parent are automatically top-level-windows. What you call top-level-windows is drawin with a RootWindow parent. I just add that to be clear, all window except the RootWindow instances should have a parent. So IIUC, you want only RootWindow and Drawin to have children? Sounds logical. This change would cause us to lose the alpha channel that cairo can provide. IMHO that's not a big loss. I am not sure to understand what you are talking about. For alpha compositing, if you recall correctly, I had some demo about stacking window and fake alpha transparency. That's doable with drawin, since you can repaint drawin background with what is underneath them, since you are drawing the drawin, you know what's in them. I'm not sure I'm clear though. :) Lots of the shiny new widget layout code would conflict with this. All the layouts that can contain multiple items (flex / fixed) would have to manage drawins while the single-item layouts (rotate, systray) have to continue working on widget objects. No idea what should happen with the border layout... I do not know all that code, but I think it's just a matter of adapting the under lying algorithms. Since we don't have to support Zaphod-Mode any more, drawin's (and all other kind of windows) don't need a screen property, because defining a screen conflicts with the object's geometry. (The geometry already kind of defines the screen) Totally agree. So the only object which would be left with a .screen property would be tags, but this does cause problems, too. Actually, does the C code really care about a tag's screen? Couldn't this property be moved to lua somehow... I don't think so. And ultimately, tags should be full-Lua implemented. But that's out of the current proposal I think. -- Julien Danjou ❱ http://julien.danjou.info pgp0TR43Q3ozg.pgp Description: PGP signature
Re: The joy of titlebars in git/master
On Sun, Dec 19 2010, Uli Schlachter wrote: My software engeneering prof would cry, nice :) Also, +1 for the ASCII-art. :D What do we actually gain from this? This let's us reparent Window under clients (sounds like a really bad idea) Yes, that's something that should be blocked. and reparent drawin under other drawins. Any good use case and/or sequence diagram for this? ;) You can then consider each drawin as an independent widget with it's own set of event. Then, organizing widgets with a layout is organizing drawin, so it's equivalent to organizing windows: you can merge the widget and clients layouts to be the same, allowing you to do more powerful things in a more elegant manner. Reparenting drawin is necessary if you want to force each widget to be a full drawin (which simplify event handling a lot), and can provides more feature, like easy merging of drawin. Now, imagine 2 clients in 2 drawin, with a simple layout. +--+ +--+ | Drawin | | Drawin | |++| |++| || Client || || Client || |++| |++| +--+ +--+ Obviously, is the top part is considered to be a so-called titlebar, you can either draw on it directly like it is currently done, or add more drawin to make the widget like a propose, which requires drawin reparenting between them. But you can also imagine something like: +-+ |Drawin | | ++ ++ | | | Drawin | | Drawin | | | |+--+| |+--+| | | || Client || || Client || | | || || || || | | |+--+| |+--+| | | ++ ++ | +-+ Which could be used to embed 2 windows in a container, for whatever reasons (tabs with 2 clients visible, a special grouping usage, whatever). -- Julien Danjou ❱ http://julien.danjou.info pgpvwJgholDqH.pgp Description: PGP signature
Re: idea about making awesome-client more flexible
On Thu, Dec 16 2010, Julien Danjou wrote: What's limited is how we use dbus-send in awesome-client. Because awesome-client is more a CLI than a `cat. But that's just a shell script limitation, not a awesome nor D-Bus one. Just send your code as a one big string and it will work. Someone should try to modify awesome-client to act this way. I just did into master. If that works fine, I'll cherry-pick that into 3.4. -- Julien Danjou ❱ http://julien.danjou.info pgp6oSid9AyVv.pgp Description: PGP signature
Re: [3.4-git] XRandr + multiple screen + multiple virtscreens
On Thu, Dec 02 2010, Emmanuel Lepage-Vallée wrote: NVIDIA blob do support xrandr, it is disabled by default, but supported. Option RandRRotation true in xorg.conf. After that, it appear in xrandr. Nice to know. What is a virtual screen and what is real, separate screen? 2 physical screen on NVIDIA, 3 on ATI. The NVIDIA ones use Xinerama and ATI use Virtual mode because it is all it support. Both used separately work, both combined don't. Ok. I did an hack to solve the problem, see https://github.com/Elv13/Patched-Awesome/commit/4deb0d7c53a0e8b384acffa4ec5a281826ea78a5but it is very cheap (hardcoded the layout). And I found where is the bug while I was there. xcb_xinerama_query_screens_screen_info_length(xsq); seem to cause the problem, so it is not really an Awesome bug, but an XCB one. With the ATI card only, it report 3 screens. With the NVIDIA only, it report two, but with both combined, it report 3. So it look like it have an if there is only one screen and it is in virt mode, then:... else if there is many:end instead of combining both method. Yeah, that's not an XCB bug, that's a X protocol bug. Xinerama cannot be enabled on several physical screens in the X protocol. Your configuration is not something that is possible protocol-speaking. Using XRandR instead of Xinerama would probably fix that. You can try git master which has better code for detecting screens. But not sure it will works perfectly though, your configuration is really… particular. :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpPKAifODIA9.pgp Description: PGP signature
Re: [Patch] naughty: localize obj
On Sun, Sep 19 2010, Gregor Best wrote: the attached patch fixes a minor problem in naughty. A variable was not instantiated locally in naughty.notify() which caused strict.lua to cramp up once again :) Thanks Gregor, pushed. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpcapMbkf4mv.pgp Description: PGP signature
Re: [RFC Patch] Track the number of objects alive
On Fri, Sep 17 2010, Uli Schlachter wrote:
diff --git a/luaa.c b/luaa.c
index 44009f6..f9e3b4c 100644
--- a/luaa.c
+++ b/luaa.c
@@ -689,6 +689,7 @@ luaA_init(xdgHandle* xdg)
{ exec, luaA_exec },
{ spawn, luaA_spawn },
{ restart, luaA_restart },
+{ class_stats, luaA_class_stats },
There's only that part i don't like. I think you should a stats()
function as a class method rather than here.
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
pgpRLWEEE9bW9.pgp
Description: PGP signature
Re: [RFC Patch] Track the number of objects alive
On Fri, Sep 17 2010, Uli Schlachter wrote: New patch attached. If you are OK with this, I will add the missing luadoc before merging this. Perfect, go ahead. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpkSo9zMtPcL.pgp Description: PGP signature
Re: A story about fancy cairo patterns
On Wed, Sep 15 2010, Uli Schlachter wrote: What do you guys think? Any proposals how the syntax can be improved? The syntax seems understandable from my point of view. Without having hacking with the underlying functions, I can't tell. Maybe you want to include this piece of code inside oocairo directly, in a helper lib? I mean, this does not look awesome specific after all. Is this good enough so that I can drop gradients from progressbar and graph? The problem I see here is that one now has to specify x,y coordinates for the patterns which wasn't necessary before... I don't think this is a problem. If you export this function from the widgets, you may be able to simplify the syntax a bit, without asking the user to set 0,0. P.S.: The code responsible for this is ugly and can be found at http://git.znc.in/?p=psychon/awesome.git;a=blob;f=lib/gears/color.lua.in;h=fc8bb3fcfc41334c7398e94a0814d32cf63103c8;hb=oocairo It did hurt. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpDGezSvVClE.pgp Description: PGP signature
Re: A story about fancy cairo patterns
On Wed, Sep 15 2010, Uli Schlachter wrote: I don't really like that idea. I'm thinking of oocairo as just plain lua-bindings. It shouldn't try to do more than you can do with cairo directly from C. Fair enough. That could only ever work for linear patterns. Also, the start point doesn't have to be 0,0 . For example, the attached image is the result of this color: w:set_color(linear:0,10:0,20:1,#ff:0.5,#00:0,#00ff00) Oh ok. I understood it was more the beginning of the drawing than the beginning of the gradient. My bad! Parsing strings is always lots of fun... I think the language is hurting. But I may be doing too much Elisp this days. :-) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpr5OoChiTtE.pgp Description: PGP signature
Re: Paste selection at the cursor position in prompt
On Sun, Aug 29 2010, immerrr wrote: Currently, on Shift+Insert selection gets inserted at the end of the prompt text and the cursor's shifted right by #selection characters. Apparently, this results in wrong behavior when the cursor is in the middle of entered text. The fix is trivial yet I'm not quite sure the patch is ready for inclusion so I'll just post it here for now. Patch merged in 3.4 and master. Thanks! -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpC0CPukiIep.pgp Description: PGP signature
Re: Removing our gperf usage
On Mon, Aug 30 2010, Uli Schlachter wrote:
What? I heard someone in the last row of the audience said
slow? Come on, how much impact will this have? These are
just some short strings!
It is also less comfortable to write and to read, IMHO. Switch
statement is nice for such things.
My alternative, which is probably uglier:
#define PROPERTY_VALUE(xxx) \ const char *__a_prop_matching = xxx;
\ if(0) { #define PROPERTY_IS(yyy) \ } else
if(!strcmp(__a_prop_matching, #yyy)) { #define PROPERTY_END }
int somefunc(lua_State *L) {
PROPERTY_VALUE(luaL_checkstring(L, 3)) PROPERTY_IS(name)
printf(This is a name); PROPERTY_IS(role) printf(This is
the role); PROPERTY_END; }
do we really need gperf?
Probably not.
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
pgp9TXJgJn5fb.pgp
Description: PGP signature
Re: [RFC] Bringing the ugly to awesome (new widget system)
On Sat, Aug 28 2010, Uli Schlachter wrote: So back to more realistic names: draw, funbox, graphics, gui, look... My proposal on this sunny sunday morning: - Wibox as we know them will just be X windows where you'll draw. So let's rename them to `drawin'. - Wibox is widget box. There's no more widget strictly speaking, just `drawin' objects you paint and then you arrange via layouts. This code belongs into a module, and I propose to call it `wibox'. There's a grunt work to rename wibox-drawin, but the win is for the user who will not have to deal with a new name. My 2¢, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpKsSlxRPjYc.pgp Description: PGP signature
Re: [RFC] Bringing the ugly to awesome (new widget system)
On Sun, Aug 29 2010, Uli Schlachter wrote: IMHO drawin is a little hard to read because it got so few ws. Sadly, window is already taken, else I'd propose that name. Dunnow, It's like drawing without a g. I though about `window' too, but it's too generic anyhow. What do you think about renaming wibox to window or win. After all, they will be the only root-parented windows left. The currently-in-core window class would have to go, but I think it doesn't make that much sense anyway with reparentable clients (do we want to be able to set a border on both the wibox and another border on the client that is in there?). I did not think it was a good idea because of what I did in master/next last months: the `window' class was the starting class representing a X window, including root windows, clients and wiboxes. So naming wiboxes as windows is a big lie and can be pretty confusing the day you'll start having a `window' class, parent of clients/wiboxes/root windows, like I did implement. You do want to set a border on both the wibox and the client ; the principle of the inheritance I've added to it are done just for the possibility of doing that without any cost (= without writing new code). So dropping out classes/possibilities just to save a few name choice is not a good excuse! Therefore I really think we should get a new name for C-side-wiboxes. Fortunately, no one except the real core hackers we are will know about it. If `drawin' is not ok, we'll find something else. Another idea, I propose `scribox', based on words `scribble' or `scribe', as you want, to use as a new name for C-side-wiboxes. :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpRuCT2opHnu.pgp Description: PGP signature
Re: [RFC] Bringing the ugly to awesome (new widget system)
On Fri, Aug 27 2010, Uli Schlachter wrote: Since there is a plan to split up awful, I started with that here. The new widget layouts are called User(un)friendly Graphic Library for You (thanks for the idea, Gregor!). Since that name is way too long, we need something shorter. Widgets are now part of the ugly library. I also created a gears module which is meant to get generic stuff that doesn't fit elsewhere (right now there is just some signal stuff in there). Colors are parsed by color, but I guess this should be moved to gears.color or something like that. I don't know if that name is definitive, but FWIW, I prefer positive names. `awful' was chosen by me because the initial file `awful.lua' I wrote was just a set of functions I had plan to rewrite and split soon (at that time). That thing did not happened, and awful came out where it should never have been released. ;-) So, just to say I don't like the name `ugly'. If it's for widgets for wiboxes, let's call it `funbox' (for exemple!) because they have fun inside. :-P At least that's positive. :-) Of course, all the layouts can themselves be used as widget and so you can stack layouts and widget (a align layout which contains a flex layout in the middle that). Sounds really good. Today I started porting the existing awful awful code. The only stuff that is still broken (and that I know is broken) are the taglist and tasklist. I guess it would be easier to rewrite these instead of trying to port them... Considering how a pile of rewrite them had, that's probable. Another problem is the systray. Since awesome doesn't render that one, this cant be moved to lua. I haven't figured out how to fix this yet, but I will come up with something. :) Make it be a wibox that cannot be drawn on. No? So, what do you think? Is it worth replacing the existing widgets code with that? Sure! ;) - Cairo only provides functions for reading PNG files, all the other image formats that imlib2 previously handled for us would be no longer readable. Isn't there a Lua/imlib2 binding? :-) - No more named colors. Cairo accepts colors as rgb (and possibly a) values between 0 and 1. So black would be 0, 0, 0 and green 0, 1, 0. If we want to be able to parse named colors like red and black, we would need to add an API to awesome that asks the X server about the color and returns the apropriate values. This seems rather pointless and so named colors will be removed instead. Fair enough. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpGusoCF6PvO.pgp Description: PGP signature
Re: [RFC] Bringing the ugly to awesome (new widget system)
On Sat, Aug 28 2010, Uli Schlachter wrote: Just for reference, Gregor proposed draw. So let's start collecting ideas! - Existing modules are named by adjectives, do we want to stick to that? - The new name should be related to something visual. - If a theme is beautiful, then using and displaying that theme is beautifuler? astonishing? - INSERT IDEA I'll try to think about it. :-) Other idea: keep `wibox' name, rename core's wiboxes as something else. That would at least be less confusing for users. Is this an alternative to plan E (or was it plan F?). If yes, let's call it plan Z so that we don't have any letters left that could be used for new plans. Actually, this is a start of your implementation of what was descrived in plan E. I'm comfortable with that. You'll probably end up with the same functions we have in `next', except that they would be better driven. :-) Should I continue working on this in a separate branch or should I start breaking master with my weird ideas? You can merge little things in master if that does not break it and if you are sure they will not need to be reverted if you ever throw your current work. For the rest, keep your work in a feature branch because I think you'll have a lot of thing to (re)work on. OTOH, be careful that your feature branch do not become a monster, or you'll cry when merging. So if you can/need, split it in smaller feature that we can decide to merge once at a time. (in summary: do not do another `next' ;-) Heh, didn't know that. Google says sure. It provides access to imlib's image loader, but it doesn't look like you get easy access to the image's data. Copying an image via get_pixel() sounds slow. Ok, we need to fork it to add a return argb32 data as Lua string function? :-) I just remembered another downside: Shape support is gone. I haven't seen anyone using it and just removing it was easier than porting it. No idea how hard it would be to port. cairo does provide image surfaces with 1bpp... I won't cry over it. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgppNUszDvzgB.pgp Description: PGP signature
Re: [RFC] Bringing the ugly to awesome (new widget system)
On Sat, Aug 28 2010, lukash wrote: If you don't agree, it doesn't really matter what name you give it... But it should not be a negative name as jd said. `core' is potentially a bad name; we should not clash with other existing Lua modules. And this is not describing awesome very well. :-) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpgaQVpsuwuV.pgp Description: PGP signature
[ANNOUNCE] awesome 3.4.7 released
Hi folks, awesome 3.4.7 has been released! This version has a ton of bug fixes and little invisible enhancements. Reading the change log below, I want to thank Uli for his amazing work once again. Happy hacking, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info awesome version 3.4.7 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.4.7.tar.xz md5: 28d5d185c1a6ce419ff95ffba08f08ed sha1: 4c413692eb44e163884530dfe1b58a4c17c84767 tar.bz2: http://awesome.naquadah.org/download/awesome-3.4.7.tar.bz2 md5: aa3350b10ba0e1cdb81b97148b31ca19 sha1: c8e21323d4338be9b16e14890f54caf2ba1729ac number of changes - 48 number of commiters --- 6 shortlog Uli Schlachter (43): Add systray windows to the save-set Don't reparent systray windows on exit Add all managed client windows to the safe set Don't manually unban all windows on exit Handle errors in the config better Read a textbox' text correctly textbox: Throw a lua error on invalid markup Naughty: Catch invalid markup in notifications Clear a draw_text_context_t during wipe() Kick out the systray when wiping a wibox Avoid some flickering when a new window opens Fix a brown paper bag bug in d7d70714d7943ac4 Ignore size hints on fullscreen windows Minor cleanup Fix a minor ICCCM incompatibility Fix some size hint mixups Improve aspect size handling Make fullscreen stacking respect EWMH awful.placement: Honor border width Remove windows from the save set in unmanage Remove systray icons from the save set Fix an unbalanced lua stack operation Naughty: Handle invalid UTF-8 more sanely Avoid some round-trips on startup Stop using libxcb-property Remove some unused function arguments Stop using most of libxcb-event Remove some more unused function arguments Brown paper bag commit Remove all uses of attribute unused client_unmanage: Update WM_STATE later Correctly read a textbox' ellipsize and wrap properties prompt: Only show error messages Add focusable property to client objects Check focusable in awful.client.focus.filter(c) Always unban a client that we are trying to focus Track the last timestamp received from the server Use globalconf.timestamp Don't call focus hook in client_focus() Unban the titlebar when leaving fullscreen Ignore the titlebar geometry on fullscreen clients Fixes for maximized clients Revert Don't call focus hook in client_focus() Daniel Gra?a (1): Register systray only if systray widgets are attached. (FS#503) Gregor Best (1): fix some deprecated atom constants Ignas Anikevicius (gns_ank) (1): Functionality for deleting a tag using awful.tag. Julien Danjou (1): Change codename Konstantin Stepanov (1): stack graph mode works with max_value diffstat awesome.c | 104 +++-- awesomeConfig.cmake|4 +- client.c | 121 +++ common/tokenize.gperf |1 + common/xutil.c | 10 -- common/xutil.h |7 +- draw.h |1 + event.c| 318 ++-- event.h|4 +- ewmh.c | 34 +++-- globalconf.h |6 +- lib/awful/client.lua.in|3 +- lib/awful/placement.lua.in |9 +- lib/awful/tag.lua.in | 68 + lib/awful/widget/graph.lua.in | 25 +++- lib/awful/widget/prompt.lua.in |8 +- lib/naughty.lua.in | 15 ++- luaa.c |8 +- luadoc/client.lua |1 + property.c | 155 +++- property.h |3 +- screen.h |2 + selection.c|6 +- spawn.c|2 +- systray.c | 64 +++- systray.h |2 + titlebar.c | 22 +++ wibox.c|9 + wibox.h|2 + widget.c |2 +- widgets/systray.c |2 +- widgets/textbox.c | 40 - window.c |4 +- 33 files changed, 625 insertions(+), 437 deletions(-) pgplwpEaAwZCm.pgp Description: PGP signature
Re: RFC: Drop support for zaphod mode
On Wed, Aug 18 2010, James Pearson wrote: I use two separate X sessions. If that is not zaphod mode, disregard the rest of this message. If you mean 2 X servers, this is not Zaphod mode indeed. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Patch: fix some deprecated XCB atoms
On Sun, Aug 08 2010, Uli Schlachter wrote: I took a look, but it seems like this doesn't depend on the version number of libxcb, but instead the version xcb-proto libxcb was built with(?). So I guess we can't really do anything about detecting the needed version...? % pkg-config --variable=xcbproto_version xcb 1.6 Will return the version of xcb-proto used to build your libxcb. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Removing Imlib2
On Sat, Jul 31 2010, W. Michael Petullo wrote: Would anyone be interested in a patch that replaces the image class' use of Imlib2 with Cairo/gdk-pixbuf? I have a rough one working. Sounds interesting if you can replace Imlib2 (almost) completely by cairo. That shoulds be discussed on -devel however. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgp7grzEQJBSG.pgp Description: PGP signature
Re: [Patch] Turn awesome into a reparenting WM
On Tue, Aug 03 2010, Uli Schlachter wrote: All issues should be solved and I've been using this code for a couple of days already. The only thing left on my todo list is wait for JD's ACK. So feel (again) free to give these some testing to find any remaining bugs. Acked-by: Julien Danjou jul...@danjou.info :-) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgp4otgdQ4rxC.pgp Description: PGP signature
Re: [Patch] Only use Xrandr if it makes sense
On Wed, Jul 21 2010, Uli Schlachter wrote: CC'ing JD since I want his ACK on this. I won't push this if he doesn't approve it. Of course, everyone else is welcome to post comments as well. X-Acked-by: Julien Danjou jul...@danjou.info -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgp3AjuaWMcZ0.pgp Description: PGP signature
Re: [patch] textbox/naughy: behave nicer when incorrect markup is received
On Fri, Jul 16 2010, Uli Schlachter wrote: (Also, according to the docs, print(textbox.text) will return the text with all attributes stripped. Does this qualify as a bug?) Yes. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpSoWYhwKpl6.pgp Description: PGP signature
Re: [patch] textbox/naughy: behave nicer when incorrect markup is received
On Fri, Jul 16 2010, Uli Schlachter wrote: I don't really like this approach, but I guess it works... Neither do I. I think we should raise a Lua error if `textbox.text = foo' cannot be parsed by Pango. Looks possible, doesn't it? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpUH7hhBcsqp.pgp Description: PGP signature
[ANNOUNCE] awesome 3.4.6 released
Hi folks, Here's an updated version of awesome 3.4, with a few bug fixes and small new features, as usual. Also, I'd like to use this mail to announce that I recently managed to convince Uli Schlachter to have write access to the project repository. Therefore he can also merge patches to help me. I hope this will improve the development process in the future. Happy hacking, as usual, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info awesome version 3.4.6 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.4.6.tar.xz md5: 45ce6790f52e888d72d696772c297047 sha1: 5c4c836436a811d58f58e7f6bd95235d759f11d9 tar.bz2: http://awesome.naquadah.org/download/awesome-3.4.6.tar.bz2 md5: 0f645751bfce04518b192fa41d1fcd57 sha1: 48b40e23b56de7a7d51f815353aa4eb2ee5dab08 number of changes - 18 number of commiters --- 6 shortlog Julien Danjou (7): Fix awesome-client parameters Store widgets references as wibox items Fix missing tostring naughty: return nothing, not nil dbus: only warn, dot not raises an error (FS#713) Fix mouse::leave signal emit on widgets (FS#774) change codename Perry Hargrave (4): tag.lua: move() re-index tags tag.lua: getidx() returns index of tag tag.lua: add() create tags with full table of properties tag.lua: check name argument to add() is valid Uli Schlachter (4): Remove _NET_WM_DESKTOP when client got no tags Handle _NET_WM_DESKTOP more intelligently Remove invalid variable usage Update the tasklist when a client's icon changes Gregor Best (1): dbus: fix compiling error Renato Botelho (1): Do not install txt manpages files fabschub (1): awsetbg was missing break diffstat CMakeLists.txt |4 +- awesomeConfig.cmake |2 +- dbus.c | 23 +++--- event.c | 93 +++--- ewmh.c | 11 - lib/awful/rules.lua.in |2 +- lib/awful/tag.lua.in | 68 ++-- lib/awful/widget/tasklist.lua.in |1 + lib/naughty.lua.in |2 +- utils/awesome-client |4 +- utils/awsetbg|1 + wibox.c | 14 ++ wibox.h |1 + widget.c | 39 +++- widget.h |4 +- 15 files changed, 200 insertions(+), 69 deletions(-) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpVnf6CSPDri.pgp Description: PGP signature
Re: [ANNOUNCE] awesome 3.4.6 released
On Wed, Jul 14 2010, SammyF wrote: Just to be sure : should this update cope with (most?) 3.4's rc.lua configs? Yes, as usual with micro releases. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgp2pRcCMmA9Q.pgp Description: PGP signature
Re: Dynamic tagging for awful
On Sat, Jul 10 2010, Aneesh Kumar wrote: I looked at merging the earlier set of patches i found on the mailing list with upstream -git. The only missing features for a working dyntag feature is delete and rename (we can skip move_screen i guess). Is it possible to get tag.delete() merged upstream ? Last mail on this is here http://www.mail-archive.com/awesome-devel@naquadah.org/msg05142.html but that is missing find_fallback function. So i ended up using http://www.mail-archive.com/awesome-devel@naquadah.org/msg05112.html With delete upstream i should be able to use the upstream source directly. It seems we lost track of this set of patches. Perry, would you be kind enough and resent a whole set of patches that me or Uli can review and merge? My apologies. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpWSQBwQ9eea.pgp Description: PGP signature
Re: Questions on the tasklist
On Thu, Jun 24 2010, Lukas Hrazky wrote: All I did with this code was just move it around, so there's a 99,54% chance it was there before my modifications already :) Probably, except that I just checked for the filtered signal which did not ring any bell: % git checkout 9a519552 HEAD is now at 9a51955... update taglist and tasklist to new widget layouts % git grep property::filtered lib/awful/widget/tasklist.lua.in: tag.attached_add_signal(s,property::filtered, u) % git blame lib/awful/widget/tasklist.lua.in | grep property::filtered 9a519552 (Lukas Hrazky 2009-10-24 14:53:01 +0200 141) tag.attached_add_signal(s, property::filtered, u) % git checkout 9a519552~ Previous HEAD position was 9a51955... update taglist and tasklist to new widget layouts HEAD is now at a079ab6... awful.util: change table.clone to do deep copies cigue awesome/src % git grep -c property::filtered 0 So you at least insert a new signal which nobody uses. ;) Note that I'm not finger pointing, I don't care, I should have proofread that better anyhow. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpqQozL4wTq3.pgp Description: PGP signature
Re: Questions on the tasklist
On Tue, Jun 22 2010, Uli Schlachter wrote: Does anyone mind if that code is just dropped? git-blame shows that this comes from: commit 9a51955279832a66bc46d072e4b4b484d387e55b Author: Lukas Hrazky lukk...@email.cz Date: Sat Oct 24 14:53:01 2009 +0200 update taglist and tasklist to new widget layouts Signed-off-by: Lukas Hrazky lukk...@email.cz Signed-off-by: Julien Danjou jul...@danjou.info There's 99,53% of chance that I did not proofread it correctly, considering the patch hugeness and the commit date. So you might do what you need to do on that. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpbneQslQ7cU.pgp Description: PGP signature
Re: Scalable icons support
On Sat, Jun 19 2010, Sergey Mironov wrote: Hi! What is the status of *svg scalable images support? We use Imlib2 to handle images. If Imlib2 does not support SVG (which seems likely), well, no luck for now. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpNHLXSBrjgX.pgp Description: PGP signature
Re: How to ban windows?
On Tue, Jun 15 2010, Uli Schlachter wrote: So, any suggestions how windows should be banned? The only way I can see for fixing this is reparenting, how much would I be killed if I introduced that reparenting? That'd be the best option. As you say, a frame of the same size will be invisible. We would have to manipulate the parent frame just in place of the current window. Another possibility is to demonstrate that the client is broken relative to ICCCM for example, and not fix the bug, but fix the application. Don't know if that's the case here. In other news, what's the state of FS#636 Add reparenting support between wibox and clients? Could this be used as a fix? It could be, but that'd be Lua side, something you don't want here. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpqWhi5lJGpV.pgp Description: PGP signature
Re: How to ban windows?
On Wed, Jun 16 2010, Uli Schlachter wrote: xmgrace is breaking ICCCM. It's explicitly mentioned that one has to sent a synthetic UnmapNotify to the root window for normal state - withdrawn state (which is what XWithdrawWindow() is for), but xmgrace only unmaps its window. Still, if you tell people xmgrace is broken, people will tell you but it works everywhere else! :( Personnally, I don't care that much. When I found that most of the things using eggtray for doing system tray were crashing on awesome restart, I did not lost my time trying to reproduce the behavior of others: I've fixed the eggtray usage in various software. Fix what is broken, not what is not. :-) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpi8MvtpltJ4.pgp Description: PGP signature
Re: [Patch] Better _NET_WM_DESKTOP handling
On Sun, Jun 13 2010, Uli Schlachter wrote: attached are two patches which should improve this. No idea if they are correct, but they seem to do the right thing. First one was tested via 'xprop -id id of window _NET_WM_DESKTOP' after removing all tags from a window, second one was tested by lowering the number of tags in the default config and restarting. Oh and: If a window got an empty _NET_WM_DESKTOP when awesome starts up, the C core won't tag it. This means that awful.rules will either tag it through some rule or it will call withcurrent() on it with an invalid second argument which means the client will get tagged. :) All in. Thanks Uli. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpbYZ7I4Rlmt.pgp Description: PGP signature
Re: [Patch] Update the tasklist when a client's icon changes
On Mon, Jun 14 2010, Uli Schlachter wrote: @jd: Did you miss my mail [Patch] Better _NET_WM_DESKTOP handling from yesterday? I did. Pushed, thanks. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpyAqjrH9wfj.pgp Description: PGP signature
Re: Strange behavior with twinview dual monitor setup
On Thu, Jun 10 2010, Uli Schlachter wrote: Awesome reacts to screen changes by restarting and screens are scanned for before the rc.lua is parsed, so by the time Lua can do anything, the screens were already set up. However, if someone ever manages to stop awesome from restarting on layout changes... (That sounds like lots of work to me, screen pointers are used pretty much everywhere :( ). Yeah, it's hard to work-around good design to fix other people problem. :| There's a common wish, I guess, to be able to change the screen size From the awesome point of view. I guess we could made that possible by setting some value read-write and emit some signals to say screen changes. That'd even be a first step toward proper xrandr changes support. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpTgdvJi326x.pgp Description: PGP signature
Re: Strange behavior with twinview dual monitor setup
On Wed, Jun 09 2010, Yves Frederix wrote: I just tried out the latest version from git, and for some reason on a dual screen setup, I get one single long-stretched wibox (spreading over both screens) instead of one for each screen. Apparently, awesome now suddenly sees my multiple screens (nvidia twinview) as one big one. In v3.4.5, everything was fine. Probably (hopefully ;)) this is unintended behavior. `master' now uses xrandr to detect screens with xrandr if possible, and then fallback to Xinerama, and then fallback to normal detection. You use nvidia closed source driver. They does not support xrandr correctly. You lose. Sorry for that. :-( -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpRPiQLVNIiR.pgp Description: PGP signature
Re: Strange behavior with twinview dual monitor setup
On Wed, Jun 09 2010, Uli Schlachter wrote: How bad would it be to add a flag which disables Xrandr/Xinerama?... How bad would it be to fix what's really wrong? Really really just thinking out loud too. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpUomW9NTeCE.pgp Description: PGP signature
Re: Strange behavior with twinview dual monitor setup
On Wed, Jun 09 2010, Uli Schlachter wrote: Can't we just merge the patch named very bad hack that was just posted? *hide* I'm gonna pretend I did not read your email and put back my chainsaw. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpRGo2hA1E7F.pgp Description: PGP signature
Re: Strange behavior with twinview dual monitor setup
On Wed, Jun 09 2010, Andrei Thorp wrote: So yes, I agree. In an ideal world, we'd just use xrandr for everything and that'd be that. But X isn't to that point yet, and this decision affects too many users for it to be practical now. Please reconsider or provide a workaround that's not keeping a patched awesome source tree. Now I'm gonna pretend you did not see the patch that has been proposed. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpfrXtHosBjQ.pgp Description: PGP signature
Re: Strange behavior with twinview dual monitor setup
On Wed, Jun 09 2010, Uli Schlachter wrote:
When we only listen to Xinerama, people ask for Xrandr, when we do Xrandr,
people ask for Xinerama. Can someone please fix X11? kthxbye.
At least something sane, thanks Uli.
Anyway, how much would you oppose a patch that adds a flag for this? For
example
one could do --query-dimensions={xrandr,xinerama,none}. Later on (if someone
is
crazy enough for this) we could add --query-dimensions=custom:geometry of
first
screen:query of second screen etc which would allow one to override the X
server's info.
Yup, but I'm not fan of options stuff.
Could we think about something Lua-ish to add in the API?
P.S.: Could someone *please* tell nvidia to fix their driver? I mean, the X
server announced Xrandr support but doesn't actually deliver anything
useful.
That's (y)our point of view. Only awesome would notice, since only
awesome uses screen informations that way.
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
pgpfpcaQEFJJh.pgp
Description: PGP signature
[Harri Haataja] Bug#584996: awesome-extra: obvious wlan widget dysfunction and readme
It may interest Obvious developers hanging around. ---BeginMessage--- Package: awesome-extra Version: 2010051701 Severity: normal /usr/share/awesome/lib/obvious/wlan/readme says: This widget monitors your WLAN's signal strength. To set the device it monitors, use obvious.wlan.set_device(dev) There is no such function, though. Apparently this kind of line works instead: obvious.wlan.device = eth2 Adding the actual widget to wibox leaves a blank space where I put it and the item itself appears to the left under window titles (default config). Apparently it ignores the position completely somehow. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash awesome-extra depends on no packages. Versions of packages awesome-extra recommends: ii awesome 3.4.5-1highly configurable, next generati awesome-extra suggests no packages. -- no debconf information ---End Message--- -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgp1tyCGkAcyd.pgp Description: PGP signature
Re: [PATCH] tag.lua: check name argument to add() is valid
On Tue, Jun 01 2010, Perry Hargrave wrote: Pushed. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpgr5GUeq8mK.pgp Description: PGP signature
Re: Fwd: FS#503 - awesome steals gnome systray even when its systray is disabled
On Sun, May 30 2010, Uli Schlachter wrote: Indeed, it does not. phys_screen = screens.len. Shouldn't that always break with xinerama? (Only one phys_screen, multiple virtual ones) I mis-write. I meant number_of_phys_screen = screens.len. I wonder if it wouldn't make more sense to first make sure only one systray widget can be attached to any *physical* screen. And this makes me wonder if we shouldn't fix FS#556 (Create a new physical_screen_t structure)... Long road. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgplRrUuw7JDu.pgp Description: PGP signature
Re: [Patch] Fix an attempted to concatenate nil value with the tasklist
On Sun, May 30 2010, Uli Schlachter wrote: See attached patch. Pushed. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpmDaNH3kSUX.pgp Description: PGP signature
Re: [PATCH 5/5] tag.lua: move_screen() moves tag to another screen
On Sat, May 29 2010, Uli Schlachter wrote: @jd: Am I right here? What is the expected behavior if one changes a tag's screen while the tag still got clients attached? The client could be attached to other tags, that could lead to the being attached to tags on different screens, but tag_client() doesn't seem to protect against that case either. Am I missing something important here? :/ You're probably right, and it's probably a bug. We easily missed so far because the standard config and usage does not involve tag.screen changes, after all. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpPDjhxNuTMu.pgp Description: PGP signature
Re: [PATCH 1/5] tag.lua: add() create tags with full table of properties
On Sat, May 29 2010, Perry Hargrave wrote:
+--- Add a tag.
+-- @param name The tag name, a string
+-- @param props The tags properties, a table
+-- @return The created tag
+function add(name, props)
+local properties = props or {}
+local newtag = capi.tag{name = name}
+newtag.screen = properties.screen or capi.mouse.screen
+
+if newtag ~= nil then
[…]
How can newtag be nil ? If it is ever nil, the line above setting the
screen will fail horribly.
Cheers,
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
pgpD28sAB9NER.pgp
Description: PGP signature
Re: [PATCH 3/5] tag.lua: move() re-index tags
On Sat, May 29 2010, Perry Hargrave wrote: tag.move(i, t): move tag 't', or tag.selected(), to index 'i' in the current screen's tags table. Pushed in 3.4 and master. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpjkd7otcVtK.pgp Description: PGP signature
Re: [PATCH 4/5] tag.lua: getidx() returns index of tag
On Sat, May 29 2010, Perry Hargrave wrote: tag.getidx(t): Return the index of 't' in the screen[]:tags() table. Return 'nil' if 't' is not found. Pushed in 3.4 and master. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpR9lG4sekpC.pgp Description: PGP signature
Re: Fwd: FS#503 - awesome steals gnome systray even when its systray is disabled
On Mon, May 24 2010, Daniel Graña wrote: That's cool, but I can't find a place for where I can access phys_screen and widget creation. Indeed. Widget creation is not related to a screen, that's gonna be a problem. So basically, that let's us with your initial approach if we don't want to break the API. In your approach, the X systray is not registered if the systray widget is never attached to a wibox or displayed. I merged the patch: http://gist.github.com/412326 It is much simple to read now, and it is clear (as you said) that it is registering/unregistering based on systray existence inside wibox for each phys_screen. Ack. Sorry, but I am a newbie here, can I ask why not? It doesn't makes sense to me to register for systray notifications if systray widgets can't show updates because they are not attached to a wibox. Creating a systray and registering it should be done in a row IMHO. Attaching to a wibox, making it visible, etc, should not interferes with it being registered. But as you pointed out, we lack of widget-screen assignation upon widget creation, so your approach is the only we can implement for now, so I say we'll go with it after all. I'd like a couple of OK it works from some people who tested it. Guys? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpJQNSRUgjyB.pgp Description: PGP signature
[PATCH] Store widgets references as wibox items
This will store the widgets references that the wibox have inside their
environment table, and not in the global registry, avoiding memory leaks.
This should fix FS#771.
Signed-off-by: Julien Danjou jul...@danjou.info
---
event.c | 70 ++---
wibox.c | 14
wibox.h |1 +
widget.c | 39 --
widget.h |4 +--
5 files changed, 87 insertions(+), 41 deletions(-)
diff --git a/event.c b/event.c
index bda0cc5..6e9af0b 100644
--- a/event.c
+++ b/event.c
@@ -160,7 +160,11 @@ event_handle_button(void *data, xcb_connection_t
*connection, xcb_button_press_e
ev-event_y -= wibox-geometry.y;
}
+/* Push the wibox */
luaA_object_push(globalconf.L, wibox);
+/* Duplicate the wibox */
+lua_pushvalue(globalconf.L, -1);
+/* Handle the button event on it */
event_button_callback(ev, wibox-buttons, -1, 1, NULL);
/* then try to match a widget binding */
@@ -170,10 +174,16 @@ event_handle_button(void *data, xcb_connection_t
*connection, xcb_button_press_e
ev-event_x, ev-event_y);
if(w)
{
-luaA_object_push(globalconf.L, w);
-luaA_object_push(globalconf.L, wibox);
+/* Push widget (the wibox is already on stack) */
+luaA_object_push_item(globalconf.L, -1, w);
+/* Move widget before wibox */
+lua_insert(globalconf.L, -2);
event_button_callback(ev, w-buttons, -2, 2, NULL);
}
+else
+/* Remove the wibox, we did not use it */
+lua_pop(globalconf.L, 1);
+
}
else if((c = client_getbywin(ev-event)))
{
@@ -342,12 +352,12 @@ event_handle_destroynotify(void *data __attribute__
((unused)),
}
/** Handle a motion notify over widgets.
- * \param object The object.
+ * \param wibox The wibox.
* \param mouse_over The pointer to the registered mouse over widget.
* \param widget The new widget the mouse is over.
*/
static void
-event_handle_widget_motionnotify(void *object,
+event_handle_widget_motionnotify(wibox_t *wibox,
widget_t **mouse_over,
widget_t *widget)
{
@@ -355,25 +365,46 @@ event_handle_widget_motionnotify(void *object,
{
if(*mouse_over)
{
-/* call mouse leave function on old widget */
-luaA_object_push(globalconf.L, *mouse_over);
-luaA_object_emit_signal(globalconf.L, -1, mouse::leave, 0);
+/* Emit mouse leave signal on old widget:
+ * - Push wibox.*/
+luaA_object_push(globalconf.L, wibox);
+/* - Push the widget the mouse was on */
+luaA_object_push_item(globalconf.L, -1, *mouse_over);
+/* - Emit the signal mouse::leave with the wibox as argument */
+luaA_object_emit_signal(globalconf.L, -2, mouse::leave, 1);
+/* - Remove the widget */
lua_pop(globalconf.L, 1);
-luaA_object_unref(globalconf.L, *mouse_over);
+/* Re-push wibox */
+luaA_object_push(globalconf.L, wibox);
+luaA_object_unref_item(globalconf.L, -1, *mouse_over);
*mouse_over = NULL;
+/* Remove the wibox */
+lua_pop(globalconf.L, 1);
}
if(widget)
{
/* Get a ref on this widget so that it can't be unref'd from
- * underneath us (- invalid pointer dereference). */
-luaA_object_push(globalconf.L, widget);
-luaA_object_ref(globalconf.L, -1);
+ * underneath us (- invalid pointer dereference):
+ * - Push the wibox */
+luaA_object_push(globalconf.L, wibox);
+/* - Push the widget */
+luaA_object_push_item(globalconf.L, -1, widget);
+/* - Reference the widget into the wibox */
+luaA_object_ref_item(globalconf.L, -2, -1);
+
+/* Store that this widget was the one with the mouse over */
*mouse_over = widget;
-/* emit mouse::enter signal on new widget */
-luaA_object_push(globalconf.L, widget);
-luaA_object_emit_signal(globalconf.L, -1, mouse::enter, 0);
+/* Emit mouse::enter signal on new widget:
+ * - Push the widget */
+luaA_object_push_item(globalconf.L, -1, widget);
+/* - Move the widget before the wibox we pushed just above */
+lua_insert(globalconf.L, -2);
+/* - Emit the signal with the wibox as argument */
+
+luaA_object_emit_signal(globalconf.L, -2, mouse::enter, 1);
+/* - Remove the widget from the stack */
lua_pop(globalconf.L, 1);
}
}
@@ -439,9 +470,14 @@ event_handle_leavenotify(void *data __attribute__
((unused
Re: Fwd: FS#503 - awesome steals gnome systray even when its systray is disabled
On Fri, May 21 2010, Daniel Graña wrote: This is my first attempt to ideal patch, please review it at http://gist.github.com/408472 1. You should fix the indentation to respect the one used in awesome; 2. In systray_init(): screen.systray.registered = false; is useless (it's false by default); 3. You should not do: screen.systray.registered = true; in wibox_systray_refresh(), but rather in systray_register(). This is just my opinion, feel free to correct me if you think I'm wrong. The patch would need some volunteer to test it, but it seems ok and mergeable to me. Do you plan to make an extra patch to unregister the systray when the widget disappear ? -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpWqPr3MA2DI.pgp Description: PGP signature
Re: Fwd: FS#503 - awesome steals gnome systray even when its systray is disabled
On Fri, May 21 2010, Daniel Graña wrote: Agree, but I tried hard to follow it, where I failed? I don't know; I actually only read the patch on github, and had the impression the indentation was wrong. But I may be wrong about that. :) Cool, latest patch http://gist.github.com/409014 I did the changes you suggested and reused the screent_t screen variable where possible. Loooks good. It would be nice if some people could torture the patch though. Do you plan to make an extra patch to unregister the systray when the widget disappear ? Prefer to do it in one patch, but can't find what is the best place to unregister systray. The more you split your work, the happier I am. What call systray widget destructor? luaA_widget_gc, which call the widget destructor. Note that you will have to count the systray widgets. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpNEJxQ01Y3o.pgp Description: PGP signature
Re: Fwd: FS#503 - awesome steals gnome systray even when its systray is disabled
On Fri, May 21 2010, Daniel Graña wrote: Here is another patch that unregister systray if no systray widget is found for a wibox. see http://gist.github.com/409310 Hum, that does not seems good to me, and actually, that makes me wonder if the first patch is. I think you register/unregister at the wrong time. You should register when the first systray widget is created, and unregister when the last systray widget is unregistered. In your approach, the X systray is not registered if the systray widget is never attached to a wibox or displayed. While this may works in common usage, it's not valid in theory. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpJj1Ikh79EQ.pgp Description: PGP signature
Re: Fwd: FS#503 - awesome steals gnome systray even when its systray is disabled
Hi Daniel, On Thu, May 20 2010, Daniel Graña wrote: Hello everyone, I am new to awesome and to this mailing list, want to say thanks about the great window manager you have built :) Thanks! I was trying to use awesome as wm behind gnome replacing metacity but found the bug better described by FS#503http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=503. I am trying to fix it now (or part of it at least). I cloned awesome source, prepared a patch and need someone to review it. My latests comments has some notes about the patch, see http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=503#comment1967 Well, the patch seems valid, unfortunately I'm not very comfortable with it. The ideal patch would be to enable systray window only at systray widget creation, and destroy it on widget destruction. And here is a direct link to the patch: http://gist.github.com/406858, it is against 3.4.5 Have awesome an official clone at github/gitorious from where I can fork / send pull requests? No there's no clone at gitwhatever, only on git.naquadah.oth. But you can use git request-pull or send-email, and send it to awesome-devel. Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpsNLs1oDGDT.pgp Description: PGP signature
