Re: [PATCH + RFC] awful.doc reactivation
At 1251821489 time_t, koniu wrote: Alternative solution is to catch these duplicates in awful.help.format.kb_list(), perhaps under condition that the modifiers might be different but keysym is the same + the doc.description is the same. This would add yet another loop to format.kb_list() which is already pretty loaded, which is why I chose this shortcut. I could try hack up duplicate detection tho. Would be cleaner IMHO. My initial plan was to clearly split help generation into frontend and backend where everything is returned in some standard manner and then you can display it in naughty or just get a string or whatever. Eventually my awful.help functions ended up in having a load of pango markup so I just left naughty as a dependency. Having used it for more than 3 months now I have to say that I've experienced no ill-effects to that. Well I am sure there's no ill effect, it's just a cyclic-dependency we should try to avoid. What's your view? Well, my view is rather more complicated than it should be, and not only related to awful.doc. The thing is that naughty is handling 2 things currently: wibox creation, placement, etc and notification system (Lua + D-Bus). What we're needing more and more inside awesome is not notification itself, but wibox creation/placement handling. You need it for your keybinding stuff in awful.doc. and for example, I'd need it if I wanted to add a wibox with a mini-calendar when clicking on the awful.widget.textclock there's on my wibox-statusbar. So ultimately, naughty should be somehow splitted to handle notification and use wibox creation/system from awful. Ok, I know this is not gonna be solve the problem of awful.doc *right now*, but that's currently how I see things. Now, to solve *that* problem, there's 2 solution: - move awful.doc outside awful, so it can depends on awful + naughty, which would on the same level as it; - just implement a callback system where you give a function to awful.doc that will be called with text to be printed as argument. This is something I'm gonna be looking into. Also luadoc is pretty flexible and you can have any fields you want so perhaps we could look into closer integration. Great idea. Keep me in touch. :) 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] fix wibox position
At 1251816622 time_t, Gregor Best wrote: Patchy attachy :) Pushed. :) 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
[PATCH] luadoc client.lua fix
%s/@name client./@name / From a0405723c131273ff77a39afcca5f70a95d5a00f Mon Sep 17 00:00:00 2001 From: koniu gkusni...@gmail.com Date: Wed, 2 Sep 2009 09:46:57 +0100 Subject: [PATCH] luadoc: remove module name from functions in client.lua Signed-off-by: koniu gkusni...@gmail.com --- luadoc/client.lua | 32 1 files changed, 16 insertions(+), 16 deletions(-) diff --git a/luadoc/client.lua b/luadoc/client.lua index 92cd94f..6cabe24 100644 --- a/luadoc/client.lua +++ b/luadoc/client.lua @@ -47,89 +47,89 @@ module(client) --- Get all clients into a table. -- @param screen An optional screen number. -- @return A table with all clients. --- @name client.get +-- @name get -- @class function --- Check if a client is visible on its screen. -- @param - -- @return A boolean value, true if the client is visible, false otherwise. --- @name client.isvisible +-- @name isvisible -- @class function --- Return client geometry. -- @param arg1 A table with new coordinates, or none. -- @return A table with client coordinates. --- @name client.geometry +-- @name geometry -- @class function --- Return client struts (reserved space at the edge of the screen). -- @param struts A table with new strut values, or none. -- @return A table with strut values. --- @name client.struts +-- @name struts -- @class function --- Get or set mouse buttons bindings for a client. -- @param buttons_table An array of mouse button bindings objects, or nothing. -- @return A table with all buttons. --- @name client.buttons +-- @name buttons -- @class function --- Get or set keys bindings for a client. -- @param keys_table An array of key bindings objects, or nothing. -- @return A table with all keys. --- @name client.keys +-- @name keys -- @class function --- Access or set the client tags. -- @param tags_table A table with tags to set, or none to get the current tags table. -- @return A table with all tags. --- @name client.tags +-- @name tags -- @class function --- Kill a client. -- @param - --- @name client.kill +-- @name kill -- @class function --- Swap a client with another one in global client list. -- @param c A client to swap with. --- @name client.swap +-- @name swap -- @class function --- Raise a client on top of others which are on the same layer. -- @param - --- @name client.raise +-- @name raise -- @class function --- Lower a client on bottom of others which are on the same layer. -- @param - --- @name client.lower +-- @name lower -- @class function --- Redraw a client by unmapping and mapping it quickly. -- @param - --- @name client.redraw +-- @name redraw -- @class function --- Stop managing a client. -- @param - --- @name client.unmanage +-- @name unmanage -- @class function --- Add a signal. -- @param name A signal name. -- @param func A function to call when the signal is emitted. --- @name client.add_signal +-- @name add_signal -- @class function --- Remove a signal. -- @param name A signal name. -- @param func A function to remove. --- @name client.remove_signal +-- @name remove_signal -- @class function --- Emit a signal. -- @param name A signal name. -- @param ... Various arguments, optional. --- @name client.emit_signal +-- @name emit_signal -- @class function -- 1.6.3.3
Re: [PATCH] luadoc client.lua fix
At 1251881406 time_t, koniu wrote: %s/@name client./@name / Pushed. -- 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 + RFC] awful.doc reactivation
At 1251904856 time_t, koniu wrote: There's incremental commits that will eventually be squashed. Please do so if you think it reduce the review size. ;) On Wed, Sep 2, 2009 at 09:33, Julien Danjoujul...@danjou.info wrote: At 1251821489 time_t, koniu wrote: this shortcut. I could try hack up duplicate detection tho. Would be cleaner IMHO. Done. I think that perhaps the new function awful.help.compare_kb() could replace awful.key.match() altho then I'd have to add analogous function to awful.button. Gonna look into it. As you please. ;) My initial plan was to clearly split help generation into frontend and backend - just implement a callback system where you give a function to awful.doc that will be called with text to be printed as argument. That's what I was thinking. Question is, where ought the default callback function(s) be defined. rc.lua ? Another small issue - awful.help.get(widget) doesn't get descriptions for 'buttons' and 'extents': http://omploader.org/vMjlvYg. That's a more general/logic problem: there are object methods, and we only set object methods available on object. We should probably export object methods to their module also: mywidget:buttons() and mywidget.buttons(mywidget) already and then we should have widget.buttons(mywidget) working also. I can't see why we should not do that. i.e. it's like Lua string module. That's something I can add as soon as I've time, if no one goes into it before me. 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: [PATCH + RFC] awful.doc reactivation
Another little update on a previously discussed matter: 16:37 koniu lol i tried retrieving keybinding descriptions for the cheat-sheet from descriptions of functions they're bound to and it's unimpressive :) http://omploader.org/vMjlwNg 16:40 koniu too many inline functions in the default rc 16:42 koniu i think i'm gonna stick with documenting everything as it is, at least it gives pretty verbose explanation to anyone who's looking at the default config Having said that, I will keep the attempt to retrieve descriptions from functions in awful.key but these will be overridden by any definitions made in awful.key.new(). At least people who haven't migrated their configs to include descriptions will have _something_ there. k -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH + RFC] awful.doc reactivation
At 1251906585 time_t, koniu wrote: Having said that, I will keep the attempt to retrieve descriptions from functions in awful.key but these will be overridden by any definitions made in awful.key.new(). At least people who haven't migrated their configs to include descriptions will have _something_ there. +1. -- 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 + RFC] awful.doc reactivation
On Wed, Sep 2, 2009 at 16:39, Julien Danjoujul...@danjou.info wrote: At 1251904856 time_t, koniu wrote: There's incremental commits that will eventually be squashed. Please do so if you think it reduce the review size. ;) I'll keep the increments for now, since it's easier for me to track progress and squash them when we'll be getting closer to finalizing the review. - just implement a callback system where you give a function to awful.doc that will be called with text to be printed as argument. That's what I was thinking. Question is, where ought the default callback function(s) be defined. Actually, looking at the extent of naughty dependency (and therefore a necessity to do a lot of different callbacks) I'm leaning towards your first suggestion which is splitting it out of awful and calling it 'handy' instead (unless someone has a better name - ideas welcome). Another small issue - awful.help.get(widget) doesn't get descriptions for 'buttons' and 'extents': http://omploader.org/vMjlvYg. We should probably export object methods to their module also: mywidget:buttons() and mywidget.buttons(mywidget) already That's something I can add as soon as I've time, if no one goes into it before me. That would be great. I'll leave this to you (or whomever wants to boost their commit rank, hint hint psychon :p). kk -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [awesome bugs] #613 - awful.menu miscalculates wibox height [PATCH]
I've attached a patch that works around the problem by resizing the wiboxes in awful.menu to accomodate the labels if they are taller than the theme specified menu_height. It requires that the menu_height variable in your theme be a number and *not* a string -Stephen On Wed, Sep 2, 2009 at 11:47 AM, awesome jul...@danjou.info wrote: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Uli Schlachter (psychon) Attached to Project - awesome Summary - awful.menu miscalculates wibox height Task Type - Bug Report Category - Core Status - New Assigned To - Operating System - All Severity - Medium Priority - Normal Reported Version - git/master Due in Version - 3.4 Due Date - Undecided Details - Hi, for a while now awful.menu miscalculates its wibox height for me (the wibox dont have enough space vertically). Recently this was turned into no text being displayed. This is triggered by this in the theme: theme.font = sans 10 Uli More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=613 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #613 - awful.menu miscalculates wibox height (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#613 - awful.menu miscalculates wibox height User who did this - Stephen Sugden (grncdr) -- I've attached a patch that works around the problem by checking the requested height against the height needed for the labels on the menu, and resizing the menu height as necessary. This will probably break if your theme.menu_height is specified as a string and not a number -- One or more files have been attached. More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=613#comment1378 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #613 - awful.menu miscalculates wibox height (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#613 - awful.menu miscalculates wibox height User who did this - Stephen Sugden (grncdr) -- Ok, so I attached an empty file... could happen to anyone... here's the actual fix, with another little check to not break on menu_heights specified as strings -- One or more files have been attached. More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=613#comment1379 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #611 - beautiful fails to override the default wallpaper
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#611 - beautiful fails to override the default wallpaper User who did this - koniu (koniu) -- I can't think of a way of tackling this without hassle. To be honest, I'd just revert 4823a1254108b3bd5ec086861080ba97018a3868 and 42c47eeccee804c138a8d7baed01e893196e7873. I see no advantage to these commits apart from the fact that awesomerc.lua.in can be loaded straight as a config file without worrying about @bla...@. Another disadvantage of implicit theme loading is when someone sets their X background in their display manager and just wants to leave it at that - they'll see flicker (at the best). In plain words it's just too obtrusive - I want choice. On the contrary, it was better prior to those commits when the user could instantly see how to load a theme, where the default one is etc. The educational value of the default rc is important imo. Worst case scenario maybe we could put the default theme setting function in some kind of startup signal so that we can do sth like: awesome.remove_signal(startup, beautiful.load_default_theme) I have to admit I have no clear idea of how this could work. -- More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=611#comment1380 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
