Re: cherry-pick c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x
On Tue, Sep 25, 2012 at 1:15 PM, Uli Schlachter psyc...@znc.in wrote: On 17.09.2012 16:00, Anurag Priyam wrote: The online documentation can't be fixed without making a release, right? So maybe someone could cherry-pick c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x -- whatever the next release branch is supposed to be, so we don't miss out on it in the next release? Meh. That would break user configs with a micro release for no good reason. Yes, it is bad that this function is called differently between 3.4 and master and the commit should have been applied to both branches back then (*if* there was no release since it was added). It doesn't look like a release was made after c623734 was added. $ git name-rev c623734 master~121 Changing it now would only annoy 3.4 users, sorry. Ok. I was thinking of it as a bug fix hence recommended it for a point release. Waiting longer will most likely break more configs later. So when do you think will it be fixed? 3.5? 4.0? Or what? Or should I remind when the next release is going to happen? What? You get a warning shortly before a release? :-) I thought if I hang out on the IRC channel I might get a clue if you are prepping a release or something. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: attemp to call nill value error in newest awesome documentation example
On Mon, Sep 17, 2012 at 2:03 AM, wojtek danilo
wojtek.danilo@gmail.com wrote:
I compled from source the newest awesome wm (without problems). I was trying
to run the example from here:
http://awesome.naquadah.org/doc/api/modules/awful.client.html#cycle
as:
[...]
awful.key({ modkey }, `, function ()
local urxvt = function (c)
return awful.rules.match(c, {class = URxvt})
end
for c in awful.client.cycle(urxvt) do
c.minimized = false
end
end),
[...]
Use awful.client.iterate instead.
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
cherry-pick c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x
From awes...@naquadah.org (subject: attemp to call nill value error in
newest awesome documentation example):
Anurag Priyam anurag08pri...@gmail.com wrote:
On Mon, Sep 17, 2012 at 2:03 AM, wojtek danilo
wojtek.danilo@gmail.com wrote:
I compled from source the newest awesome wm (without problems). I was trying
to run the example from here:
http://awesome.naquadah.org/doc/api/modules/awful.client.html#cycle
as:
[...]
awful.key({ modkey }, `, function ()
local urxvt = function (c)
return awful.rules.match(c, {class = URxvt})
end
for c in awful.client.cycle(urxvt) do
c.minimized = false
end
end),
[...]
Use awful.client.iterate instead.
awful.client.cycle added in 0d41d984687dd1c29ad2b73ad59b9ccac6d71bb3
was later renamed to awful.client.iterate in
c623734632010e4601ca4e369851bc79ab7f706f because it overrode an
existing method by the same name (awful.client.cycle).
The online documentation can't be fixed without making a release,
right? So maybe someone could cherry-pick
c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x -- whatever the next
release branch is supposed to be, so we don't miss out on it in the
next release? Or should I remind when the next release is going to
happen?
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: tasklist labels
On Mon, Sep 3, 2012 at 8:33 PM, Daniel qu...@hack.org wrote: Any chance of (in lua) adding some function for regex search-and-replace in tasklist's labels? And what would you accomplish with that? -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [RFC] Move cursor to middle of screen using awful.screen.focus()
On Wed, Aug 22, 2012 at 9:51 PM, Ignas Anikevicius anikevic...@gmail.com wrote: I have written a small patch, which changes the behaviour, so that we have the mouse repositioned to the centre of the screen. Could we have [...] What others think about this? Sloppy-focus is enabled by default. So repositioning mouse cursor to the center of the screen on screen.focus might unexpectedly shift focus from the auto-focussed client, which makes it undesirable as a default. IMO, it is more preferable to have cursor at the center of the screen, instead of top-left, especially when you are using a big screen (24). I am in favor of this patch, together with removing sloppy focus as the default. Sloppy-focus is not intuitive. No desktop environment defaults to sloppy focus. In fact, I don't there is an option to enable sloppy-focus on any. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [RFC] Move cursor to middle of screen using awful.screen.focus()
On Wed, Aug 22, 2012 at 9:51 PM, Ignas Anikevicius anikevic...@gmail.com wrote: I have written a small patch, which changes the behaviour, so that we have the mouse repositioned to the centre of the screen. Could we have Where is the patch? -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
fix run_or_raise on lua 5.2
`iterate` method call in `awful.client.run_or_raise` was missing a receiver. Fix attached. -- Anurag Priyam 0001-run_or_raise-fix-for-lua-5.2-upgrade.patch Description: Binary data
Re: [ANN] Definitely Awesome - the latest news about awesome wm
On Mon, May 14, 2012 at 7:05 PM, Alexander Yakushev unlo...@bytopia.org wrote: Awesome Weekly #11 is out: http://definitely-awesome.posterous.com/awesome-weekly-11 The link points to awesome weekly 10. Awesome Weekly # 11: http://definitely-awesome.posterous.com/awesome-weekly-11 -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Who is interested in
On Mon, May 14, 2012 at 7:11 PM, Christopher R. Parr foss...@gmail.com wrote: helping me create a community portal for the most awesome window manager? You may want to have a look at [Definitely Awesome][1]. [1]: http://definitely-awesome.posterous.com/ -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: border actions
On Mon, May 14, 2012 at 3:08 PM, Thorsten Sperber li...@aero2k.de wrote: I would like to implement border actions in my configuration, like in [...] My problem is that nothing happens. Maybe signal property::x isn't the best way to start. A better way would be something like If you set dockable property on a client with `awful.client.dockable.set(c, true)` and move it around with mouse, awesome snaps it to edges if you are 8px close to one. `awful.mouse` does the magic, so lib/awful/mouse/init.lua could be a good place to look for help. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [PATCH] Menubar enhancements
On Sat, May 12, 2012 at 2:51 PM, Ignas Anikevicius
anikevic...@gmail.com wrote:
I was also wondering, whether those extra '-' are really necessary. I
have removed them and now only the documentation is added. It is
slightly ugly in the list of the contents, but I have no idea how to fix
it since there is no table called Menubar key-bindings. I guess we
could leave it as it is for now and then if/when we implement custom
key-bindings, we can update the documentation.
If you move your comment block immediately before module definition
and remove the @class and @name tags, luadoc will attach it to the
module.
---
-- Meh around everywhere!
-- br/
-- pMeh!
-- ...
-- /p
module('meh')
That said, if psychon is ok with your patch, I have no intentions of
bothering you either :).
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: split rc.lua in separate files?
On Thu, May 10, 2012 at 4:55 PM, Rainer M Krug r.m.k...@gmail.com wrote: I thought about splitting rc.lua in a few other files (keybindings.lua, mousebindings.lua, widgets.lua, ...) ant then call these from rc.lua, so that in rc.lua are mainly recalls to the other config files. How can I achieve this? You can checkout https://github.com/ierton/awesomerc-ierton. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [PATCH] Menubar enhancements
On Mon, May 7, 2012 at 12:47 PM, Arvydas Sidorenko asi...@gmail.com wrote: What's with deleting and adding the same thing all over the patch? --- Wrap the text with the color span tag. +--- Wrap the text with the color span tag. --- Generate a pattern matching expression that ignores case. +--- Generate a pattern matching expression that ignores case. Those are from Ignas' original patch. Look carefully, there is an extra '-' in the lines added. 3 dashes exposes that function's documentation to luadoc. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Theme.lua location
On Sun, May 6, 2012 at 2:00 PM, Uli Schlachter psyc...@znc.in wrote: On 06.05.2012 04:20, Anurag Priyam wrote: Uli, what's with the `colstr` variable? It doesn't seem to be used anywhere. Same for the `if c:get_type()` block. Doesn't look like anything is being done with the rgba values that it computes. I wonder if this (attached patch) is the right approach: This was added in commit 07bbe14d02. The problem was that whenever the wibox needed to be drawn, the X server first filled that area with black and only [...] Makes sense. function set_bg(wibox, c) [...] + c = string_format(#%02x%02x%02x, r, g, b) end wibox.background_color = c wibox.draw() This patch is wrong. wibox.background_color must always be a cairo pattern object and not a string. If it really gets set to #00, everytime a wibox gets redrawn, oocairo will throw a lua error about cr:set_source() needs a Cairo pattern or surface object as argument 2. Ok. I thought the computed rgb values had to be used. Could you send (to awesome-devel) two new patches? First one will be [...] Attached. -- Anurag Priyam 0001-wibox-assume-a-default-background-and-foreground-col.patch Description: Binary data 0002-wibox.set_bg-remove-historical-cruft.patch Description: Binary data
Re: hide menu on mouse click outside it (was: Re: [patch] awful.menu [...])
ping! On Mon, Apr 23, 2012 at 12:22 AM, Anurag Priyam anurag08pri...@gmail.com wrote: On Tue, Apr 3, 2012 at 11:13 AM, Anurag Priyam anurag08pri...@gmail.com wrote: On Wed, Feb 29, 2012 at 3:59 PM, Uli Schlachter psyc...@znc.in wrote: Anyone out there who opens up a popup menu, then clicks somewhere else and expects the menu to stay open? If yes, speak up now or stay quiet forever! [...] I stumbled across an issue (bug?) with mousegrabber in an attempt to fix this. This is how the patch (attached) looks like at the moment: diff --git a/lib/awful/menu.lua.in b/lib/awful/menu.lua.in [...] Open a menu. Move the cursor around; nothing happens. Click elsewhere; the menu is now hidden (actually, clicking on the menu will hie menu as well but let's forget it for the time being). Re-launch the menu. Move the cursor around; it hides the menu ?! This behavior persists till I restart awesome. On Wed, Apr 4, 2012 at 12:30 AM, Uli Schlachter psyc...@znc.in wrote: Your code works fine here (in Xephyr). No problem with a mouse button getting stuck. What am I doing wrong? :-/ Works fine on desktop. The problem happens when the menu is opened and the mouse is clicked on top of a client. Did you have any clients open? P.S: Extremely sorry for the delayed response. Was home for my sister's marriage till two days back. -- Anurag Priyam -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Theme.lua location
[+CC: Uli] On Sun, May 6, 2012 at 6:35 AM, Anurag Priyam anurag08pri...@gmail.com wrote: On Sun, May 6, 2012 at 4:25 AM, Gerald Klein j...@zognet.com wrote: /usr/share/awesome/lib/wibox/init.lua:136 attempt to index local 'c' (a nil value) Do you have bg_focus and bg_normal keys in your theme file? Even otherwise there is something fishy about `set_bg` function. The doc says the color can be nil, but it fails to use a default if no color argument was given. Uli, what's with the `colstr` variable? It doesn't seem to be used anywhere. Same for the `if c:get_type()` block. Doesn't look like anything is being done with the rgba values that it computes. I wonder if this (attached patch) is the right approach: function set_bg(wibox, c) -local c = c -local colstr = #00 -- Default if we can't figure out the color +local c = c or #00 if type(c) == string or type(c) == table then c = color(c) end @@ -137,7 +136,7 @@ function set_bg(wibox, c) local r, g, b, a = c:get_rgba() r, g, b, a = r * 255, g * 255, b * 255, a * 255 -- Alpha isn't supported for backgrounds -colstr = string_format(#%02x%02x%02x, r, g, b) +c = string_format(#%02x%02x%02x, r, g, b) end wibox.background_color = c wibox.draw() Is that `if c:get_type()` block even necessary now that wiboxes support pseudo-transparency (SHA: 5c7a3501d01a22f6cf4637bc057b46598e41e69a)? -- Anurag Priyam 0001-wibox-assume-a-default-background-color-in-set_bg-if.patch Description: Binary data
Re: [PATCH] awful.client: un-hide the client when it regains focus
On Sat, May 5, 2012 at 1:32 PM, Uli Schlachter psyc...@znc.in wrote: However, now I feel like you should send this in as a git commit. After all, it was you who noticed it and wrote a patch for. Then I complained that I wanted this to be done differently and you did so and wrote a new patch. Let's ignore my broken patch attempt in-between. There you go. The raw patch was tested so I didn't test this one (also, I am running Unity :P at the moment and don't want to close all my apps and start awesome). -- Anurag Priyam 0001-unset-hidden-state-when-a-client-regains-focus.patch Description: Binary data
Re: [PATCH] awful.client: un-hide the client when it regains focus
On Sat, May 5, 2012 at 4:03 PM, Jonathan Sielhorst jonathan.sielho...@googlemail.com wrote: you can simply start a second X server with startx -- :1 you may want to change your .xinitrc first. After that you can switch between the two X server with Alt+Ctrl+F7 and Alt+Ctrl+F8. I used it to test new awesome configs, because the Xephyr support for multiple screens is a little buggy. Hope it makes life easier ;) That's neat. Thanks :). -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] awful.client: un-hide the client when it regains focus
On Sun, Apr 29, 2012 at 8:28 PM, Uli Schlachter psyc...@znc.in wrote: Let's keep our hacks together in one place. Could you test the attached patch? (We already do the same thing to unset the minimized state when a client gets focused, so IMHO that's also where we should unset the hidden state) Hey, I'm home for summer break. Just got an Internet connection here :). Will get back to you on the patch later tonight or tomorrow (IST). -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: unagi compositing manager
On Fri, Apr 27, 2012 at 12:50 PM, Uli Schlachter psyc...@znc.in wrote: attached patch for unagi fixes this issue. The summary could as well be awesome git/master is doing weird things that no one else does. :-) Works great. Thanks :). -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: unagi compositing manager
On Thu, Apr 26, 2012 at 7:02 AM, Arnaud Fontaine arn...@andesi.org wrote: Could you please paste your Awesome configuration ? Also, you can make sure that transparency property is set properly for a given window (and thus unagi properly rendered transparency) by checking that _NET_WM_WINDOW_OPACITY (through xprop)... On Thu, Apr 26, 2012 at 12:03 PM, Uli Schlachter psyc...@znc.in wrote: You can find the _NET_WM_WINDOW_OPACITY via xprop -frame. [...] $ xprop -frame _NET_WM_WINDOW_OPACITY(CARDINAL) = 2791728741 -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: hide menu on mouse click outside it (was: Re: [patch] awful.menu [...])
On Tue, Apr 3, 2012 at 11:13 AM, Anurag Priyam anurag08pri...@gmail.com wrote: On Wed, Feb 29, 2012 at 3:59 PM, Uli Schlachter psyc...@znc.in wrote: Anyone out there who opens up a popup menu, then clicks somewhere else and expects the menu to stay open? If yes, speak up now or stay quiet forever! [...] I stumbled across an issue (bug?) with mousegrabber in an attempt to fix this. This is how the patch (attached) looks like at the moment: diff --git a/lib/awful/menu.lua.in b/lib/awful/menu.lua.in [...] Open a menu. Move the cursor around; nothing happens. Click elsewhere; the menu is now hidden (actually, clicking on the menu will hie menu as well but let's forget it for the time being). Re-launch the menu. Move the cursor around; it hides the menu ?! This behavior persists till I restart awesome. On Wed, Apr 4, 2012 at 12:30 AM, Uli Schlachter psyc...@znc.in wrote: Your code works fine here (in Xephyr). No problem with a mouse button getting stuck. What am I doing wrong? :-/ Works fine on desktop. The problem happens when the menu is opened and the mouse is clicked on top of a client. Did you have any clients open? P.S: Extremely sorry for the delayed response. Was home for my sister's marriage till two days back. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: hide menu on mouse click outside it (was: Re: [patch] awful.menu [...])
On Wed, Apr 4, 2012 at 12:30 AM, Uli Schlachter psyc...@znc.in wrote: On 03.04.2012 08:22, Anurag Priyam wrote: Also, how can I pass a normal cursor to mousegrabger? I don't wan't the cursor to change -- looks silly. There is a list of mouse cursors in common/xcursor.c. I guess you want X_cursor, but that one seems to be broken. Bummer. Ok, I am totally clueless about how to fix it? Hints? -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Fix issue with awful.menu keygrabber collisions
On Sat, Apr 21, 2012 at 9:20 AM, dodo dodo.the.l...@googlemail.com wrote:
not quite. you tell awful.keygrabber that you want keys but if someone
after you asks for keys as well he will get it until he leaves it and
you're back in key control again.
the attachment might describe it in a better way than my words ^^
Patch 1:
[...]
+--- Keygrabber Stack
+module(awful.keygrabber)
+
+-- Private data
+local grabbers = {}
+local keygrabbing = false
+
+--- The global key grabber
+-- that distributes the key events to the last grabber in history
+local function grabber(mod, key, event)
+for i, g in ipairs(grabbers) do
+-- continue if the grabber returns explicitly false
+if g(mod, key, event) ~= false then
+break
+end
+end
+end
+
Say I run two grabbers one after the other. If the second grabber
returns false, the event will be dispatched to the first one without
removing the second one from the stack. This doesn't sound like what
you previously said ...if someone after you asks for keys as well he
will get it until he leaves it and you're back in key control again.
Also, won't bad things happen if the first grabber calls
awful.keygrabber.stop and is removed from the stack while the second
one is still running? I think it is best to send key events to only
the first grabber on the stack:
local function grabber(mod, key, event)
local g = grabbers[1]
g(mod, key, event)
end
+--- Remove a key grabber from the history
+-- @param g The key grabber that must be removed.
+function stop(g)
+for i, v in ipairs(grabbers) do
+if v == g then
+table.remove(grabbers, i)
+break
+end
+end
In the context of the above argument, I think you just need a stack 'pop' here:
table.remove(grabbers, 1)
[...]
+--- Update key grabber history.
+-- @param g The key grabber that will get the key events until it
will be deleted or a new grabber is added.
+function run(g)
+-- Remove the grabber if its in stack
+stop(g)
+-- Record the grabber has latest added
+table.insert(grabbers, 1, g)
Why not insert at the last position and assume the tail of the table
to be the head of the stack?
http://www.lua.org/pil/19.2.html
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Fix issue with awful.menu keygrabber collisions
On Sat, Apr 21, 2012 at 1:19 PM, Uli Schlachter psyc...@znc.in wrote: On 21.04.2012 09:09, Anurag Priyam wrote: Say I run two grabbers one after the other. If the second grabber returns false, the event will be dispatched to the first one without removing the second one from the stack. This doesn't sound like what you previously said ...if someone after you asks for keys as well he will get it until he leaves it and you're back in key control again. Uhm, I think this table stack works the other way around than you think it works. The newest entry has index 1 in the table. [...] Keygrabber can thus not only ask for old events, but can also pass on some of them to older keygrabbers. E.g. a menu which can only be navigated with arrow keys and ignores/passes on all other keys. Right, I got that. So my question was Is being able to bubble up events to the older grabbers intended (given the use of 'stack') and whether it is safe?, which you answered below. Does this make sense? Do you agree that this makes sense? (I take your response as a NACK to the patch and will now wait for an ACK or a timeout ;-) ) Yep, except the docs could do with some improvement: +--- The global key grabber +-- that distributes the key events to the last grabber in history +local function grabber(mod, key, event) +for i, g in ipairs(grabbers) do +-- continue if the grabber returns explicitly false It should be continue unless the grabber explicitly returns false. Perhaps the luadoc for the module should describe the event bubbling behavior too. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: hide menu on mouse click outside it (was: Re: [patch] awful.menu [...])
On Tue, Apr 3, 2012 at 11:13 AM, Anurag Priyam anurag08pri...@gmail.com wrote:
[...]
I can fix it. I need to determine that mouse was clicked outside
menu. So maybe I can attach a handler to 'press' signal on mouse, but
if it was not clicked on any visible menu (not sure how to determine
that), then close it?
Looks simpler with a signal handler:
button.connect_signal('press', function(but, cl)
if cl then
cur_menu:hide()
else
end)
But there are two issue with it:
1. If I put that code in awful.menu, awesome refuses to start without
any error. Any idea why?
2. The if block is executed only if the mouse was clicked on a client.
cl is nil otherwise.
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [patch] run or raise
On Mon, Apr 2, 2012 at 2:53 PM, Uli Schlachter psyc...@znc.in wrote: Oh. Looking forward to the patch. :P Attached. I must hold a record for maximum iterations before a patch gets in :-|. -- Anurag Priyam 0001-rename-the-iterator-methods-named-cycle-to-iterate-a.patch Description: Binary data 0002-introduce-awful.client.run_or_raise.patch Description: Binary data
Re: [patch] run or raise
On Mon, Apr 2, 2012 at 6:09 PM, Uli Schlachter psyc...@znc.in wrote:
Don't you think that might have something to do with the number of patches
that
you send in? :-)
Yeah, that too :).
On a related note, in my rc.lua, instead of separately defining ror
bindings for each client separately, I hook them on to my rules table.
Let me illustrate:
{ rule_any = { class = {Iceweasel, Google-chrome} },
except_any = { name = { Chat }, role = { Manager } },
ror = { exec = config.global.browser, key = i }
},
Note the 'ror' key in that rule snippet. Later in my rc.lua, I have:
for _, entry in ipairs(awful.rules.rules) do
if entry.ror then
globalkeys = awful.util.table.join( globalkeys,
awful.key({ config.global.modkey, }, entry.ror.key,
function()
local filter = function (c)
return (awful.rules.match(c, entry.rule) or
awful.rules.match_any(c, entry.rule_any)) and
(not awful.rules.match(c, entry.except) and
not awful.rules.match_any(c, entry.except_any))
end
awful.client.run_or_raise(entry.ror.exec, filter,
entry.ror.merge)
end))
end
end
So any rule with an ror key automatically gets its keybinding. I was
wondering if something like this could make its way upstream. And
how? Can't have it in awful.rules.apply because it doesn't have
access to the globalkeys table. Can't have it in callbacks because it
is executed only when the client starts. Also note the redundancy of
the filter function with the condition in awful.rules.apply.
Thoughts?
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
hide menu on mouse click outside it (was: Re: [patch] awful.menu [...])
Dug this up for context:
On Thu, Mar 1, 2012 at 9:38 PM, Uli Schlachter psyc...@znc.in wrote:
On 01.03.2012 10:52, Anurag Priyam wrote:
On Wed, Feb 29, 2012 at 3:59 PM, Uli Schlachter psyc...@znc.in wrote:
Anyone out there who opens up a popup menu, then clicks somewhere else and
expects the menu to stay open? If yes, speak up now or stay quiet forever!
Yeah, this is another thing that annoys me. Though I am not sure how
I can fix it. I need to determine that mouse was clicked outside
menu. So maybe I can attach a handler to 'press' signal on mouse, but
if it was not clicked on any visible menu (not sure how to determine
that), then close it?
Would need a mouse grabber. When someone dares to click elsewhere, the grabber
is stopped and the menu closed. (And the click which caused that is discarded,
but that's also what gtk/qt are doing)
But yeah, you are right. That'd stop the normal event processing and would
force
the code to do magic with mouse.object_under_pointer() (which should use the
mouse position at the time the event was sent, not the current position, but
that API can be fixed relatively easily).
I stumbled across an issue (bug?) with mousegrabber in an attempt to
fix this. This is how the patch (attached) looks like at the moment:
diff --git a/lib/awful/menu.lua.in b/lib/awful/menu.lua.in
index 8dd1763..7cf9238 100644
--- a/lib/awful/menu.lua.in
+++ b/lib/awful/menu.lua.in
@@ -28,6 +28,7 @@ local capi = {
mouse = mouse,
client = client,
keygrabber = keygrabber,
+mousegrabber = mousegrabber,
awesome = awesome,
oocairo = oocairo }
@@ -323,6 +324,14 @@ function show(menu, args)
if not cur_menu then
capi.keygrabber.run(grabber)
+capi.mousegrabber.run(function (mouse)
+for _, v in ipairs(mouse.buttons) do
+if v then
+menu:hide()
+end
+end
+return true
+end, 'fleur')
end
cur_menu = menu
menu.wibox.visible = true
@@ -346,6 +355,7 @@ function hide(menu)
end
if not cur_menu then
capi.keygrabber.stop()
+capi.mousegrabber.stop()
end
menu.wibox.visible = false
end
Open a menu. Move the cursor around; nothing happens. Click elsewhere;
the menu is now hidden (actually, clicking on the menu will hie menu
as well but let's forget it for the time being). Re-launch the menu.
Move the cursor around; it hides the menu ?! This behavior persists
till I restart awesome.
So I put in `gears.debug.dump(mouse.buttons, 'buttons')` in the
callback to mousegrabber the first thing and guess what I get each
time after first mouse click:
buttons : table: 0xb93c30
1 : true (boolean)
2 : false (boolean)
3 : false (boolean)
...
Once a button is clicked when mousegrabber was running, its state
remains the same. Is that expected?
Also, how can I pass a normal cursor to mousegrabger? I don't wan't
the cursor to change -- looks silly.
--
Anurag Priyam
0001-awful.menu-close-menu-if-clicked-outside-it.patch
Description: Binary data
Re: hide menu on mouse click outside it (was: Re: [patch] awful.menu [...])
On Tue, Apr 3, 2012 at 11:13 AM, Anurag Priyam anurag08pri...@gmail.com wrote: So I put in `gears.debug.dump(mouse.buttons, 'buttons')` in the callback to mousegrabber the first thing and guess what I get each time after first mouse click: buttons : table: 0xb93c30 1 : true (boolean) 2 : false (boolean) 3 : false (boolean) ... If I have not clicked the mouse even once when keygrabber is running, the output looks like: buttons : table: 0x8d9230 1 : false (boolean) 2 : false (boolean) 3 : false (boolean) ... All false. But after I click once, that button come up as true all the time (as pointed out in the previous mail). -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] awful.client: use dockable.get in focus.filter to determine dock or not
On Mon, Apr 2, 2012 at 1:52 AM, Uli Schlachter psyc...@znc.in wrote: [...] _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows. Oops! Had forgotten to attach patch. Patch 1: - or c.type == dock + or dockable.get(c) Uhm, the one kind of dock (see above) doesn't have anything to do with the other kind of dock. client.dockable.get() is for clients which stick to the corner of the workarea when they are moved near to it (the client has to be floating for this to work). That client then always stays in that position and makes the workarea smaller. I use that e.g. for gimp's utility windows, so that they are always visible even though they are floating. I guessed dockable.set was a glorified way to set a client as a 'dock' (the kind you explained above) from within awesome -- since you can't say c.dock = true from Lua code -- even if the client doesn't request a _NET_WM_WINDOW_TYPE_DOCK -- which would automatically cause c.dock to be set to true, (right?). I say glorified because dockable.get included 'utility' and 'toolbar' to be sort of dock; a nice abstraction, I thought. But why doesn't the code elsewhere use it then? Shouldn't all docks (toolbar, utility) behave the same, i.e. skip taksbar and be unfocussable? Of course, the code mustn't have been updated after dockable.get/set was written, I answered my own questions :P. Hence the patch. Oh, now that I looked at dockable.get(): This would make gimp's utility windows unfocusable. With my assumptions, that was expected behavior (why call it dock otherwise?). I am not arguing a case for the patch, but rather what I was thinking when sending it. I realize the patch isn't really required :). Hard way to learn the use of a feature/function, eh? -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [patch] run or raise
[+CC: Benjamin Stava bennam...@gmail.com]
On Mon, Apr 2, 2012 at 1:30 AM, Uli Schlachter psyc...@znc.in wrote:
On 31.03.2012 13:40, Anurag Priyam wrote:
Fixed a bug.
I diff'd the two patches. I wouldn't quite call that a bug, but ok. :-P
Left that way, it would have become a bug :P.
+-- pSwitch to a client matching the given condition if running, else
spawn it.
This tag is never closed?
+-- If multiple clients match the given condition then the next one is
focussed.
+--
+-- @param cmd the command to execute
+-- @param matcher a function that returns true to indicate a matching client
+-- @param merge if true then merge tags when clients are not visible
+--
+-- @usage run or raise urxvt (perhaps, with tabs) on modkey + semicolon
+-- pcode
Neither does this 'p' ever get the joy of being matched by a kind and
friendly
'/p'.
That was intentional, since all browsers gracefully handle unclosed
paragraphs. I will change it, nevertheless.
+-- awful.key({ modkey, }, 'semicolon', function () br/
+-- local cmd = 'urxvt' br/
I don't really care, but does this need a local var? Can't it just be given
inline in the argument to run_or_raise()?
Yeah, of course. Don't know why I use another variable for it.
+-- local matcher = function (c) br/
+-- return awful.rules.match(c, {class = 'URxvt'}) br/
+-- end br/
+-- awful.client.run_or_raise(cmd, matcher)
+-- end);
+-- /code
+function run_or_raise(cmd, matcher, merge)
+ local clients = capi.client.get(s)
This 's' is falling out of thin air? Didn't you mean to have that as an
argument
to this function? (Or just always as nil?)
Copy paste error from awful.client.cycle :P.
+ local findex = util.table.hasitem(clients, capi.client.focus) or 1
+ local start = util.cycle(#clients, findex + 1)
+
+ for c in cycle(matcher, start) do
If you use 's' above to calculate the index, you should pass in 's' here, too.
Also, I didn't know we had such a function, nice find.
Huh? I added that function only few days back, specifically for this.
How can you forget it so soon? Btw, I just realized that I had made
a mistake in naming it cycle: there is another function with the same
name (around line 387) that swaps clients in a cyclic fashion. Why is
it needed? Maybe we should call my function 'iterate'?
+ jumpto(c, merge)
+ return
+ end
+
+ -- client not found, spawn it
+ util.spawn(cmd)
I wonder if this should be turned into a callback instead? Well, at first I
was
thinking about someone needing spawn_with_shell, then I thought about that.
I don't think we need the flexibility provided by a callback here.
Hm, on second thought (actually, third) I don't think that 'spawn_with_shell'
thingie is a valid use case and if someone asks for it, he will get told to
use
bash -c.
Actually, let's make it make it spawn_with_shell instead: better than
documenting or answering on the ML a thousand times that one can use
'bash -c'. And we just found a case in Benjamin's mail later in this
thread.
Gotta run for class now. Will send in the modified patch later.
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
unselect a tag
So awful.client.jumpto let's you pass a second argument, 'merge' (apart from the client to jumpto, 'c'), which if true selects c's tag as well. Underneath, all it does is: local t = c:tags()[1] t.selected = true Now, can I somehow undo it, i.e, unselect 't'? awful.tag.history.restore doesn't seem to take care of this. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [patch] awful.client.jumpto
On Wed, Mar 7, 2012 at 6:01 PM, Uli Schlachter psyc...@znc.in wrote: On 07.03.2012 10:54, Anurag Priyam wrote: I simply split `awful.client.urgent.jumpto` to get this; needed it in my rc.lua. I'm not really happy with the luadoc, but since you catched me in a tired moment (and are one of the few people who add a Signed-Off-by): The attached patch should make you happy :). Or am I missing something else too? -- Anurag Priyam 0001-awful.client.jumpto-add-missing-luadoc-for-the-param.patch Description: Binary data
Re: [PATCH] awful.client: use dockable.get in focus.filter to determine dock or not
On Sat, Mar 31, 2012 at 5:43 PM, Anurag Priyam anurag08pri...@gmail.com wrote: Otherwise, setting a client dockable from rc.lua using awful.client.dockable.set doesn't work as expected. Oops! Had forgotten to attach patch. And in the mean time I found another one on the same lines. -- Anurag Priyam 0001-awful.client-use-dockable.get-in-focus.filter-to-det.patch Description: Binary data 0002-tasklist-exclude-docks-from-the-taskbar-properly.patch Description: Binary data
Re: layout troubles
On Mon, Mar 19, 2012 at 7:15 PM, Gerald Klein j...@zognet.com wrote: Hi, All of sudden my browser chrome doesn't pay attention to requests for layouts. They all fill the screen but not fullscreen mode and I can change layouts and the icon shows it is changing but the browsers don't change. Now if I open other apps like editors or whatever it's fine. Anyone have any idea what this is? Happened to me a few days back. The problem was automatically resolved after a system upgrade. I am running Chrome 19.0.1068.1 dev now. So maybe upgrading to the latest Chrome helps? -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
github mirror
Hi, I setup a mirror on Github: https://github.com/yeban/awesome; updated automatically on a daily basis. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Switching Colorschemes on the fly?
On Tue, Mar 13, 2012 at 7:06 AM, Ignas Anikevicius anikevic...@gmail.com wrote: Mainly I want to change the colours. Would a simple hack work to just change the theme table with some hackish function I might come up with or is there a proper way to do it? Is beautiful.init(mytheme) suitable for the job? `beautiful.init` will re-init the theme table but the only visible change you are likely to see are wallpaper, and font (font family, and color). For widgets and others to start using the new theme, you will have to restart awesome. I'd be very grateful if anybody could help me on this. Perhaps, there might be an interest in the community to have this in core? (I would love to.) Maybe a `beautiful.apply`, which does `beautiful.init` followed by `awesome.restart`. A potential issue might be that restarting awesome after switching theme is not 'safe' -- awesome may not restart (properly) because of an error in the theme. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Set clients allways master
On Mon, Mar 12, 2012 at 5:38 PM, Денис nispe...@gmail.com wrote: [...] And dialog-windows appears allways as slaves? https://awesome.naquadah.org/wiki/FAQ#How_to_start_clients_as_slave_windows_instead_of_master.3F -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: More problems with menu keygrabbing
On Sun, Mar 11, 2012 at 10:57 PM, Alexander Yakushev yakushev.a...@gmail.com wrote: When a menu keygrabbing feature is turned on (which now is by default) then the keygrabbing works until an action which menu item performs finishes. Something like: you launch Firefox, but Firefox takes some time to launch, so until Firefox is launched the keygrabber is still active? My guess is that it should be easy to fix. It means that if I, for instance, I create a menu item to run prompt (like Modkey-R) it won't work because menu keygrabber is still active. And as far as I understand this keygrabbing doesn't stop when the action is started performing, but rather after the action is stopped. Has it something to do with your menubar extension? I had a feeling that if you try to 'embed' prompt in an always-on-keygrabber menu might cause issues. I might have a workaround for it, but I will need to check out your menubar code first and toy around a bit, which I can't at the moment because of recent issues with my stupid college proxy which blocks everything except 80 and 443. Also, I am a little strapped for time at the moment. Is there a way to fix this? Perhaps stop the menu keygrabbing as soon as the item is clicked? I need to understand the issue better and experiment a bit. If it is not urgent, I would like to postpone it till the coming weekend. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Awesome - The name!
On Wed, Mar 7, 2012 at 1:57 PM, David Sorkovsky davidsorkov...@hotmail.com wrote: While I understand your comment, I must say that there is a lot more out there than your (a) (b) and (no disrespect intended) the awesome wiki is not so awesome :-( You can always add things to the wiki if you find it lacking in any aspect :). Anyway - It was just throwing out my 2c to see what people thought I have never been very happy about the name, including awful and naughty. But because of the way full text search (and hence Google) works, I don't think that adding a 'wm' to it is gonna make a huge difference. Most of the time 'wm' (and 'window manager') is anyway used in conjunction with 'awesome' in the same document. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Awesome - The name!
On Wed, Mar 7, 2012 at 2:48 PM, Anurag Priyam anurag08pri...@gmail.com wrote: I have never been very happy about the name, including awful and naughty. But because of the way full text search (and hence Google) works, I don't think that adding a 'wm' to it is gonna make a huge difference. Most of the time 'wm' (and 'window manager') is anyway used in conjunction with 'awesome' in the same document. Though I wonder if I get relevant search results because of personalization. I have been around in the awesome community for reasonably long. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
[patch] awful.client.jumpto
I simply split `awful.client.urgent.jumpto` to get this; needed it in
my rc.lua.
--
Anurag Priyam
From 67a6ebb39623a083d60ab515bd52eeb8cd66bdce Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Wed, 7 Mar 2012 03:39:45 +0530
Subject: [PATCH] introducing awful.client.jumpto
I simply moved out the code to 'jumpto' a client from
`awful.client.urgent.jumpto` into a separate function of its own so that it can
be reused.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/client.lua.in | 46 +++---
1 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/lib/awful/client.lua.in b/lib/awful/client.lua.in
index 6549488..03dcfab 100644
--- a/lib/awful/client.lua.in
+++ b/lib/awful/client.lua.in
@@ -39,6 +39,32 @@ floating = {}
dockable = {}
property = {}
+---
+-- Jump to the given client. Takes care of focussing the screen, the right tag,
+-- etc.
+-- @param merge If true then merge tags when clients are not visible.
+function jumpto(c, merge)
+local s = capi.client.focus and capi.client.focus.screen or capi.mouse.screen
+-- focus the screen
+if s ~= c.screen then
+capi.mouse.screen = c.screen
+end
+
+-- Try to make client visible, this also covers e.g. sticky
+local t = c:tags()[1]
+if t and not c:isvisible() then
+if merge then
+t.selected = true
+else
+tag.viewonly(t)
+end
+end
+
+-- focus the client
+capi.client.focus = c
+c:raise()
+end
+
--- Get the first client that got the urgent hint.
-- @return The first urgent client.
function urgent.get()
@@ -60,25 +86,7 @@ end
function urgent.jumpto(merge)
local c = urgent.get()
if c then
-local s = capi.client.focus and capi.client.focus.screen or capi.mouse.screen
--- focus the screen
-if s ~= c.screen then
-capi.mouse.screen = c.screen
-end
-
--- Try to make client visible, this also covers e.g. sticky
-local t = c:tags()[1]
-if t and not c:isvisible() then
-if merge then
-t.selected = true
-else
-tag.viewonly(t)
-end
-end
-
--- focus the client
-capi.client.focus = c
-c:raise()
+jumpto(c, merge)
end
end
--
1.7.9
Re: keygrabber api
On Fri, Mar 2, 2012 at 1:20 PM, Uli Schlachter psyc...@znc.in wrote:
However, I successfully started a program with the prompt (via pressing enter
and all that) and still had this problem. This is the part which I still don't
understand.
I can't reproduce it.
awful.prompt is quite messy that way: a giant (200 lines) of
callback to `keygrabber.run` with too many return true and false.
The return true would just be replaced by return and I only count a single
return false. I don't say this code is great, but the patch wouldn't be all
that bad.
Hmm. I gave it a shot but it there still remains a glitch (see 2nd patch):
When I close the prompt, either by executing a command or by pressing
'Escape, the keygrabber stops but the prompt with its text remains
stuck up there :-/.
That's why I have been postponing a patch to replace all `return
false` with `keygrabber.stop`. I wonder if a better approach would be
to do something like:
capi.keygrabber.run(function ()
if not grabber() then capi.keygrabber.stop()
end
Where `grabber` is the old callback. But if I have to define
`grabber` before `run`, the diff will probably be very ugly: a giant
code block moved from here to there :-|.
What do you think?
If it's messy, clean it up. ;-)
I will see if I can :).
The diff would be big is a bad excuse for not doing something IMHO. However,
this if feels like a big hack saying I changed the API, but on second
thought
I'd rather have the old one again.
Big diff wasn't an excuse. Just that I try to avoid doing anything
that makes it difficult for me to get some info out of git later. For
example, I can't determine properly (or efficiently) which commit
changed a given code block if it has been moved around or changed
indentation a couple of times. Perhaps I just don't know better :-|.
I would see that if hack as, I changed the API, but I don't want to
use it in my existing code yet for practical reasons (messy code, it
may break, I don't have time), so I will temporarily emulate the old
behavior with a simple wrapper :).
I'm playing my usual sorry, no time to code this myself-card and return to
doing non-awesome stuff. (Yes, I do mean both meanings of this sentence)
What else takes up your time? Just curious. College? Job? Apart
from my undegrad studies, I work on some Comp. Bio. stuff when I get
time.
--
Anurag Priyam
From b30a297bf7459cc2e7b042e9071484abe4c024c1 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Thu, 1 Mar 2012 15:43:29 -0500
Subject: [PATCH 1/2] awful.menu: remove superfluous return true from
keygrabber's callback
Returning true from the callback to `keygrabber` is no longer necessary to
continue grabbing the keyboard.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/menu.lua.in |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/lib/awful/menu.lua.in b/lib/awful/menu.lua.in
index 3f3fea0..8dd1763 100644
--- a/lib/awful/menu.lua.in
+++ b/lib/awful/menu.lua.in
@@ -194,9 +194,7 @@ end
local function grabber(mod, key, event)
-if event == release then
- return true
-end
+if event ~= press then return end
local sel = cur_menu.sel or 0
if util.table.hasitem(menu_keys.up, key) then
@@ -216,8 +214,6 @@ local function grabber(mod, key, event)
else
check_access_key(cur_menu, key)
end
-
-return true
end
--
1.7.5.4
From 92d8d4ac6e3431107e35f746a15f9dbea5938aab Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Sun, 4 Mar 2012 14:30:23 -0500
Subject: [PATCH 2/2] awful.prompt: do not return a boolean to talk to
keygrabber
Keygrabber no longer entertains boolean value from its callback to continue or
stop grabbing. It continues grabbing till `keygrabber.stop()` is explicitly
called, so we remove superfluous `return true` and replace `return false` with
`keygrabber.stop()`
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/prompt.lua.in | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/lib/awful/prompt.lua.in b/lib/awful/prompt.lua.in
index c398fc9..e29061e 100644
--- a/lib/awful/prompt.lua.in
+++ b/lib/awful/prompt.lua.in
@@ -204,7 +204,7 @@ function run(args, textbox, exe_callback, completion_callback, history_path, his
capi.keygrabber.run(
function (modifiers, key, event)
-if event ~= press then return true end
+if event ~= press then return end
-- Convert index array to hash table
local mod = {}
for k, v in ipairs(modifiers) do mod[v] = true end
@@ -213,14 +213,11 @@ function run(args, textbox, exe_callback, completion_callback, history_path, his
or (not mod.Control and key == Escape) then
textbox:set_markup()
if done_callback then done_callback() end
-return false
+capi.keygrabber.stop()
elseif (mod.Control
Re: keygrabber api
On Sun, Mar 4, 2012 at 4:11 PM, Uli Schlachter psyc...@znc.in wrote: I guess that fixed your earlier issue? :-) It did :). Thanks! -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: keygrabber api
On Fri, Mar 2, 2012 at 11:47 AM, Uli Schlachter psyc...@znc.in wrote: On 21.02.2012 16:47, Anurag Priyam wrote: [...] Lua's C stack based API is not very intuitive (or maybe I haven't got a hang of it yet). Hope I have got it right. The patch does seem to work here. This patch broke awful.prompt. The keygrabber never gets stopped. I guess that's because the return false in that code gets ignored, but it should already have called keygrabber.stop() before that. Let's see if this can be figured out... Right, keygrabber doesn't stop if you press 'Escape' to close the prompt. awful.prompt is quite messy that way: a giant (200 lines) of callback to `keygrabber.run` with too many return true and false. That's why I have been postponing a patch to replace all `return false` with `keygrabber.stop`. I wonder if a better approach would be to do something like: capi.keygrabber.run(function () if not grabber() then capi.keygrabber.stop() end Where `grabber` is the old callback. But if I have to define `grabber` before `run`, the diff will probably be very ugly: a giant code block moved from here to there :-|. What do you think? -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [patch] awful.menu: enable keyboard navigation by default
On Wed, Feb 29, 2012 at 3:59 PM, Uli Schlachter psyc...@znc.in wrote:
On 26.02.2012 05:56, Anurag Priyam wrote:
[...]
Here is the correct patch, tested on both values (keygrabber =
true/false) this time. But before this patch is applied, we should
perhaps consider removing keygrabber support from menu instead.
So should I merge this or not? Sending a patch with the words but before this
patch is applied feels wrong (but has it's uses...).
Right. I am sorry. I wanted to know your take on it first :).
Optionally allowing keygrabbers adds to the complexity of the code.
And for what gains? Without keygrabber enabled, you can't even close
the menu by pressing 'Escape' key (this is what prompted me to change
the default to true).
I guess I wouldn't mind. If it simplifies the code a lot, I'm all settled for
this. However, I don't really have the time to look closely into this.
Patch attached. If you like it, let's scrap the previous one
(keygrabber = true by default).
Anyone out there who opens up a popup menu, then clicks somewhere else and
expects the menu to stay open? If yes, speak up now or stay quiet forever!
Yeah, this is another thing that annoys me. Though I am not sure how
I can fix it. I need to determine that mouse was clicked outside
menu. So maybe I can attach a handler to 'press' signal on mouse, but
if it was not clicked on any visible menu (not sure how to determine
that), then close it?
--
Anurag Priyam
From 4986efeb759903637c5760ac8e69f6fa2c53d491 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Thu, 1 Mar 2012 14:12:56 -0500
Subject: [PATCH] awful.menu: always enable keyboard navigation
I don't see why people would not want keyboard-enabled-menu by default.
Without it, you can't even use 'Escape' to quit the menu or press 'Enter' to
execute an entry. But instead of just enabling keyboard support by default, we
remove the option of disabling keyboard support altogether, which also
simplifies the implementation a bit.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
awesomerc.lua.in |2 +-
lib/awful/menu.lua.in | 24
2 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 3929d9f..ceac430 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -210,7 +210,7 @@ globalkeys = awful.util.table.join(
awful.client.focus.byidx(-1)
if client.focus then client.focus:raise() end
end),
-awful.key({ modkey, }, w, function () mymainmenu:show({keygrabber=true}) end),
+awful.key({ modkey, }, w, function () mymainmenu:show() end),
-- Layout manipulation
awful.key({ modkey, Shift }, j, function () awful.client.swap.byidx( 1)end),
diff --git a/lib/awful/menu.lua.in b/lib/awful/menu.lua.in
index 3e8566f..3f3fea0 100644
--- a/lib/awful/menu.lua.in
+++ b/lib/awful/menu.lua.in
@@ -316,26 +316,16 @@ end
--- Show a menu.
-- @param menu The menu to show.
--- @param args.keygrabber A boolean enabling or not the keyboard navigation.
-- @param args.coords Menu position defaulting to mouse.coords()
function show(menu, args)
args = args or {}
local coords = args.coords or nil
local screen_index = capi.mouse.screen
-local keygrabber = args.keygrabber or false
if not set_size(menu) then return end
set_coords(menu, screen_index, coords)
-if menu.parent then
-menu.keygrabber = menu.parent.keygrabber
-elseif keygrabber ~= nil then
-menu.keygrabber = keygrabber
-else
-menu.keygrabber = false
-end
-
-if not cur_menu and menu.keygrabber then
+if not cur_menu then
capi.keygrabber.run(grabber)
end
cur_menu = menu
@@ -358,7 +348,7 @@ function hide(menu)
if cur_menu == menu then
cur_menu = cur_menu.parent
end
-if not cur_menu and menu.keygrabber then
+if not cur_menu then
capi.keygrabber.stop()
end
menu.wibox.visible = false
@@ -366,7 +356,6 @@ end
--- Toggle menu visibility.
-- @param menu The menu to show if it's hidden, or to hide if it's shown.
--- @param args.keygrabber A boolean enabling or not the keyboard navigation.
-- @param args.coords Menu position {x,y}
function toggle(menu, args)
if menu.wibox.visible then
@@ -380,9 +369,7 @@ end
-- @param menu The mnenu to update.
function update(menu)
if menu.wibox.visible then
-menu:show({
-keygrabber = menu.keygrabber,
-coords = { x = menu.x, y = menu.y } })
+menu:show({ coords = { x = menu.x, y = menu.y } })
end
end
@@ -488,7 +475,6 @@ end
--- Build a popup menu with running clients and shows it.
-- @param menu Menu table, see new() function for more informations
--- @param args.keygrabber A boolean enabling or not the keyboard navigation.
-- @return The menu.
function clients(menu, args) -- FIXME crude api
menu = menu
Re: gradients in master
On Wed, Feb 29, 2012 at 2:57 PM, Uli Schlachter psyc...@znc.in wrote: On 26.02.2012 05:01, Anurag Priyam wrote: [...] + elseif type(col) == table then + local t = col.type `type` is a core Lua function. I wonder if it is a good practice to use it is a variable name in our code. Might it be a better idea to redefine the standard `type` as `__type` instead? Uhm? Variable? Where? Also, if someone breaks lua by overwriting standard functions, that's their bug and only half mine. And if you mean col.type:I don't think that really counts as a variable name. I think there is no place in lua where there would be any ambiguity. Still, if you think it should be changed, patches welcome. What should be used instead of type for the type? (cairo calls it type, too, cairo_pattern_get_type()) Ok. I was just thinking out loud. I would wait for it to actually break or come up with a more concrete reasons before sending a patch :). There are more fun things to hack on for now, like libnotify 1.1 spec for naughty. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [ANN] Definitely Awesome - the latest news about awesome wm
On Sun, Feb 26, 2012 at 3:10 AM, Alexander Yakushev yakushev.a...@gmail.com wrote: Well, here it is: definitely-awesome.posterous.com [...] What do you think? Wow! Thanks for doing this Alex. We can also call it AWN for fun :) (like LWN). -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: gradients in master
[- CC: awes...@naquadah.org] [+CC: awesome-devel@naquadah.org] On Fri, Feb 17, 2012 at 10:24 PM, Uli Schlachter psyc...@znc.in wrote: You might be interested in the following commit: commit 2216b6a341ddb840200ea85207f8a59a5b3d61a6 Author: Uli Schlachter psyc...@znc.in Date: Fri Feb 17 17:48:11 2012 +0100 gears.color: Add table-based color definitions Signed-off-by: Uli Schlachter psyc...@znc.in The syntax is almost identical to what you proposed above. The only difference is that I went with type instead of gradient. [...] -- @return a cairo pattern object function create_png_pattern(file) +local file = file Why do we write `local file = file`? Aren't function arguments lexically scoped? [...] +elseif type(col) == table then +local t = col.type `type` is a core Lua function. I wonder if it is a good practice to use it is a variable name in our code. Might it be a better idea to redefine the standard `type` as `__type` instead? -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: gradients in master
On Sun, Feb 26, 2012 at 9:31 AM, Anurag Priyam anurag08pri...@gmail.com wrote: On Fri, Feb 17, 2012 at 10:24 PM, Uli Schlachter psyc...@znc.in wrote: You might be interested in the following commit: commit 2216b6a341ddb840200ea85207f8a59a5b3d61a6 Author: Uli Schlachter psyc...@znc.in Date: Fri Feb 17 17:48:11 2012 +0100 gears.color: Add table-based color definitions Signed-off-by: Uli Schlachter psyc...@znc.in The syntax is almost identical to what you proposed above. The only difference is that I went with type instead of gradient. And I caught a bug that you introduced :D. [...] Subject: [PATCH] gears.color: call the correct creator function in local string_pattern function The corresponding pattern factory that `string_pattern` delegates to is stored in the `creator` parameter, and not `v`; probably a typo. Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- lib/gears/color.lua.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/gears/color.lua.in b/lib/gears/color.lua.in index d285c4a..1299ff6 100644 --- a/lib/gears/color.lua.in +++ b/lib/gears/color.lua.in @@ -105,7 +105,7 @@ local function string_pattern(creator, arg) table.insert(args, v) end -- And call our creator function with the values -local p = v(unpack(args)) +local p = creator(unpack(args)) add_iterator_stops(p, iterator) return p Copy-paste error? Looks like a reminiscent of the older metatable hack. -- Anurag Priyam From 3f84ddb65ccfbb2c611e9db58e248741aa1e84b9 Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Sun, 26 Feb 2012 09:39:09 +0530 Subject: [PATCH] gears.color: call the correct creator function in local string_pattern function The corresponding pattern factory that `string_pattern` delegates to is stored in the `creator` parameter, and not `v`; probably a typo. Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- lib/gears/color.lua.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/gears/color.lua.in b/lib/gears/color.lua.in index d285c4a..1299ff6 100644 --- a/lib/gears/color.lua.in +++ b/lib/gears/color.lua.in @@ -105,7 +105,7 @@ local function string_pattern(creator, arg) table.insert(args, v) end -- And call our creator function with the values -local p = v(unpack(args)) +local p = creator(unpack(args)) add_iterator_stops(p, iterator) return p -- 1.7.9
Re: [patch] awful.menu: enable keyboard navigation by default
On Tue, Feb 21, 2012 at 10:45 PM, Anurag Priyam
anurag08pri...@gmail.com wrote:
On Tue, Feb 21, 2012 at 10:33 PM, Daniel Silverstone
dsilv...@digital-scurf.org wrote:
[...]
local keygrabber = (args.keygrabber == nil) and true or args.keygrabber
That might work better for you
Thanks Daniel.
I will resend it tomorrow. Need to study for tomorrow's exam now.
Sorry people. I was caught up with exams and post exams partying around :).
Here is the correct patch, tested on both values (keygrabber =
true/false) this time. But before this patch is applied, we should
perhaps consider removing keygrabber support from menu instead.
Optionally allowing keygrabbers adds to the complexity of the code.
And for what gains? Without keygrabber enabled, you can't even close
the menu by pressing 'Escape' key (this is what prompted me to change
the default to true).
--
Anurag Priyam
From 5f8412a6e80824e7b5401ce3e26452760871b7c9 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Tue, 21 Feb 2012 21:52:53 +0530
Subject: [PATCH] awful.menu: enable keyboard navigation by default
Thanks to Daniel Silverstone for pointing out how to better deal with falsy
parameters.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
awesomerc.lua.in |2 +-
lib/awful/menu.lua.in |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 3929d9f..ceac430 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -210,7 +210,7 @@ globalkeys = awful.util.table.join(
awful.client.focus.byidx(-1)
if client.focus then client.focus:raise() end
end),
-awful.key({ modkey, }, w, function () mymainmenu:show({keygrabber=true}) end),
+awful.key({ modkey, }, w, function () mymainmenu:show() end),
-- Layout manipulation
awful.key({ modkey, Shift }, j, function () awful.client.swap.byidx( 1)end),
diff --git a/lib/awful/menu.lua.in b/lib/awful/menu.lua.in
index 3e8566f..6dcdfc3 100644
--- a/lib/awful/menu.lua.in
+++ b/lib/awful/menu.lua.in
@@ -317,12 +317,13 @@ end
--- Show a menu.
-- @param menu The menu to show.
-- @param args.keygrabber A boolean enabling or not the keyboard navigation.
+-- Default is true.
-- @param args.coords Menu position defaulting to mouse.coords()
function show(menu, args)
args = args or {}
local coords = args.coords or nil
local screen_index = capi.mouse.screen
-local keygrabber = args.keygrabber or false
+local keygrabber = (args.keygrabber == nil) and true or args.keygrabber
if not set_size(menu) then return end
set_coords(menu, screen_index, coords)
@@ -367,6 +368,7 @@ end
--- Toggle menu visibility.
-- @param menu The menu to show if it's hidden, or to hide if it's shown.
-- @param args.keygrabber A boolean enabling or not the keyboard navigation.
+-- Default is true.
-- @param args.coords Menu position {x,y}
function toggle(menu, args)
if menu.wibox.visible then
@@ -489,6 +491,7 @@ end
--- Build a popup menu with running clients and shows it.
-- @param menu Menu table, see new() function for more informations
-- @param args.keygrabber A boolean enabling or not the keyboard navigation.
+-- Default is true.
-- @return The menu.
function clients(menu, args) -- FIXME crude api
menu = menu or {}
--
1.7.9
Re: Menu inside a module
On Sat, Feb 18, 2012 at 3:54 AM, Ignas Anikevicius
anikevic...@gmail.com wrote:
I want to make a widget, which would have a menu appearing when clicking
on the widget itself in the wibox. What would be the proper way of doing
it, because if I try to execute the following inside the module, it
errors out, by saying something about beautiful.
What exactly is the error?
[...]
So this code doesn't work, if I put it inside a file on
~/.config/awesome/mywidget/init.lua
and then import it to rc.lua via
require(mywidget)
In your rc.lua, are you requiring it before require('beautiful') or
after? Does requiring before require('beautiful') help?
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: keygrabber api
On Mon, Feb 20, 2012 at 7:39 PM, Uli Schlachter psyc...@znc.in wrote: On 19.02.2012 14:56, Anurag Priyam wrote: It feels silly to return true from the callback to keygrabber.run to keep grabbing. [] Pointers? I would like to change it if possible. keygrabber.run() saves the given function in globalconf.keygrabber. This function is then called from event.c in event_handle_key(). This code also checks the return value from the function via lua_isboolean() and lua_toboolean() (event.c, line 519) and possibly calls keygrabber.stop(). Lua's C stack based API is not very intuitive (or maybe I haven't got a hang of it yet). Hope I have got it right. The patch does seem to work here. -- Anurag Priyam From e86dc4725bca7c0d64691157047dc787a627d02b Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Tue, 21 Feb 2012 20:25:55 +0530 Subject: [PATCH] keygrabber: continue grabbing till keygrabber.stop is explicitly called Returning true from the callback just to signal keygrabber to continue grabbing felt redundant (and silly :|). This will break old code that relied on returning false to stop grabbing, instead of calling keygrabber.stop. And fix keygrabber docs. Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- event.c |2 -- keygrabber.c |3 +-- luadoc/keygrabber.lua | 16 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/event.c b/event.c index db18807..c28a3ca 100644 --- a/event.c +++ b/event.c @@ -516,8 +516,6 @@ event_handle_key(xcb_key_press_event_t *ev) warn(error running function: %s, lua_tostring(globalconf.L, -1)); luaA_keygrabber_stop(globalconf.L); } -else if(!lua_isboolean(globalconf.L, -1) || !lua_toboolean(globalconf.L, -1)) -luaA_keygrabber_stop(globalconf.L); } lua_pop(globalconf.L, 1); /* pop returned value or function if not called */ } diff --git a/keygrabber.c b/keygrabber.c index 85c20a9..6f683a5 100644 --- a/keygrabber.c +++ b/keygrabber.c @@ -88,8 +88,7 @@ keygrabber_handlekpress(lua_State *L, xcb_key_press_event_t *e) } /** Grab keyboard and read pressed keys, calling callback function at each key - * pressed. The callback function must return a boolean value: true to - * continue grabbing, false to stop. + * press, until keygrabber.stop is called. * The function is called with 3 arguments: * a table containing modifiers keys, a string with the key pressed and a * string with either press or release to indicate the event type. diff --git a/luadoc/keygrabber.lua b/luadoc/keygrabber.lua index f7ae788..8b70196 100644 --- a/luadoc/keygrabber.lua +++ b/luadoc/keygrabber.lua @@ -3,21 +3,21 @@ -- @copyright 2008-2009 Julien Danjou module(keygrabber) Grab keyboard and read pressed keys, calling callback function at each key --- pressed. The callback function must return a boolean value: true to --- continue grabbing, false to stop. --- The function is called with 3 arguments: +--- +-- Grab keyboard and read pressed keys, calling callback function at each key +-- press, until keygrabber.stop is called. +-- The callback function is passed three arguments: -- a table containing modifiers keys, a string with the key pressed and a -- string with either press or release to indicate the event type. --- @param func A callback function as described above. +-- @param callback A callback function as described above. -- @name run -- @class function -- @usage Following function can be bound to a key, and used to resize a client -- using keyboard. -- pcode -- function resize(c) br/ --- keygrabber.run(function(mod, key, event) /br --- if event == release then return true end /brbr/ +-- keygrabber.run(function(mod, key, event) /br +-- if event == release then return end /br/br -- -- if key == 'Up' then awful.client.moveresize(0, 0, 0, 5, c) br/ -- elseif key == 'Down' then awful.client.moveresize(0, 0, 0, -5, c) br/ @@ -26,7 +26,7 @@ module(keygrabber) -- else keygrabber.stop() br/ -- end br/br/ -- --- return true br/ +-- end) br/ -- end br/ -- /code/p -- 1.7.9
Re: keygrabber api
On Tue, Feb 21, 2012 at 9:25 PM, Uli Schlachter psyc...@znc.in wrote: I was going to complain that this breaks awful, however a closer look revealed that everything in there only ever does 'return true'. Yeah, I checked that actually :). Still, how about a patch which removes some superfluous return statements and 'return true's from lua? :-) I was thinking why bother if it works. On second thought, we should remove `return true` to avoid confusion. Another patch would do, or you want the changes squashed into one? Will merge when I find the time (= not before friday). No problems :). -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[patch] awful.menu: enable keyboard navigation by default
Here is another one,
It got pretty annoying today evening when playing around with menus
when I had to restart awesome after adding the damned {keygrabber =
true} every time. Most of the time, it is just redundant. I don't
see why would anyone want keyboard navigation turned off by default.
I mean, people take navigating menus from keyboard for granted,
courtsey whatever window manager or desktop environment they had been
using before, right? Hence the patch. What do you think?
--
Anurag Priyam
From 0ea140f0031d9105f5144f3f098a8670578ed59e Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Tue, 21 Feb 2012 21:52:53 +0530
Subject: [PATCH] awful.menu: enable keyboard navigation by default
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
awesomerc.lua.in |2 +-
lib/awful/menu.lua.in |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 3929d9f..ceac430 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -210,7 +210,7 @@ globalkeys = awful.util.table.join(
awful.client.focus.byidx(-1)
if client.focus then client.focus:raise() end
end),
-awful.key({ modkey, }, w, function () mymainmenu:show({keygrabber=true}) end),
+awful.key({ modkey, }, w, function () mymainmenu:show() end),
-- Layout manipulation
awful.key({ modkey, Shift }, j, function () awful.client.swap.byidx( 1)end),
diff --git a/lib/awful/menu.lua.in b/lib/awful/menu.lua.in
index 3e8566f..64f8ae8 100644
--- a/lib/awful/menu.lua.in
+++ b/lib/awful/menu.lua.in
@@ -317,12 +317,13 @@ end
--- Show a menu.
-- @param menu The menu to show.
-- @param args.keygrabber A boolean enabling or not the keyboard navigation.
+-- Default is true.
-- @param args.coords Menu position defaulting to mouse.coords()
function show(menu, args)
args = args or {}
local coords = args.coords or nil
local screen_index = capi.mouse.screen
-local keygrabber = args.keygrabber or false
+local keygrabber = args.keygrabber or true
if not set_size(menu) then return end
set_coords(menu, screen_index, coords)
@@ -367,6 +368,7 @@ end
--- Toggle menu visibility.
-- @param menu The menu to show if it's hidden, or to hide if it's shown.
-- @param args.keygrabber A boolean enabling or not the keyboard navigation.
+-- Default is true.
-- @param args.coords Menu position {x,y}
function toggle(menu, args)
if menu.wibox.visible then
@@ -489,6 +491,7 @@ end
--- Build a popup menu with running clients and shows it.
-- @param menu Menu table, see new() function for more informations
-- @param args.keygrabber A boolean enabling or not the keyboard navigation.
+-- Default is true.
-- @return The menu.
function clients(menu, args) -- FIXME crude api
menu = menu or {}
--
1.7.9
Re: [patch] awful.menu: enable keyboard navigation by default
On Tue, Feb 21, 2012 at 10:33 PM, Daniel Silverstone dsilv...@digital-scurf.org wrote: On Tue, Feb 21, 2012 at 05:53:16PM +0100, Uli Schlachter wrote: - local keygrabber = args.keygrabber or false + local keygrabber = args.keygrabber or true Let's assume that args.keygrabber is false. Now we have: local keygrabber = args.keygrabber or true local keygrabber = false or true local keygrabber = true Something or true will always be true. Ugh!! That was super silly on my part :-/. Indeed, the 'foo or bar' or 'foo and bar or baz' only works when you're not dealing with a desired falsehood on the left of the 'or' local keygrabber = (args.keygrabber == nil) and true or args.keygrabber That might work better for you Thanks Daniel. I will resend it tomorrow. Need to study for tomorrow's exam now. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
keygrabber api
Hi, It feels silly to return true from the callback to keygrabber.run to keep grabbing. Isn't it more obvious to keep grabbing unless it is instructed by calling `keygrabber.stop`? I can't see how it makes it easier to use keygrabber in any use case (from awesomerc). Maybe because I have seen very limited examples of keygrabber in action. Or is it because the limitation of Lua's C API? I can't really make out from the code how/when the callback is called and where is its return value checked for. Pointers? I would like to change it if possible. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: View next/prev non-empty tag
On Fri, Feb 17, 2012 at 2:33 PM, Daniel qu...@hack.org wrote: local num_tags = #screen[s]:tags() local num_tags = #(screen[s]:tags()) Might help? Also you may have to use `capi.screen` instead. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [patch] filter tables
On Fri, Feb 17, 2012 at 8:04 PM, Uli Schlachter psyc...@znc.in wrote:
I just noticed that this would bring us awful.util.cycle and
awful.util.table.cycle which do completely different things. How about
awful.util.table.iterate? Anyone has any good ideas? (I definitely don't)
I want to keep the name cycle because it actually cycles through the
table -- if you start from index 4, it stops at 3, returning clients
that match the given filter. I think it is ok to have the same key in
two different tables because you can infer which is which from the
context. Instead, how about splitting awful.util.table into a module
of its own? awful.table perhaps?
Second patch:
+-- c.minimized = false br/
+-- end br/
+--
+-- /code/p
I actually have not much clue about luadoc, so: Why the empty line?
No purpose actually. Must have introduced it by accident.
Also: Urgh, really have to add br / inside of code examples? :-(
Yeah. Otherwise all code comes up on the same line in the final HTML
out. This is the most important reason for which I want to see
markdown in commit messages.
Finally: What about indentation?
Luadoc ignores it. IIRC, only one code example in the entire doc uses
indentation: awful.menu.new. It is painfully difficult to add
indentation; see 514fd796f3272583ee409b784fcd9ee2a6f95875 (one of my
first patches :-|).
[...]
+function cycle(filter, start)
+ local clients = capi.client.get()
+ local focused = capi.client.focus
^^^
+ local start = start or util.table.hasitem(clients, focussed)
Typo? (The second one has ss, the first one is correct with s)
Phooey! :-/
+ return util.table.cycle(clients, filter, start)
+end
Could this get a screen argument (called 's', I guess)?
It would only have to be cycle(filter, start, s) and could be directly
passed
to capi.client.get().
Umm, ok. But I am not doing:
local screen = s or mouse.screen
Cheers,
Pedantic-Uli
Your signature eerily changes with the feedback you give :-).
PFA, revised 2nd patch.
--
Anurag Priyam
From 2a2c65a5c5ba932cbe0f1238bf93973f46659db4 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Fri, 17 Feb 2012 02:32:28 +0530
Subject: [PATCH 2/2] add awful.client.cycle to iterate through clients that
match a given condition
A common use case is to cycle through clients that match a given rule and take
certain action on them: raise, set or get property, etc.; see usage example in
the docs.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/client.lua.in | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/lib/awful/client.lua.in b/lib/awful/client.lua.in
index 2d5ec45..04236aa 100644
--- a/lib/awful/client.lua.in
+++ b/lib/awful/client.lua.in
@@ -862,6 +862,29 @@ function property.set(c, prop, value)
c:emit_signal(property:: .. prop)
end
+---
+-- Returns an iterator to cycle through, starting from the client in focus or
+-- the given index, all clients that match a given criteria.
+-- @param filter a function that returns true to indicate a positive match
+-- @param start what index to start iterating from. Defaults to using the
+-- index of the currently focused client.
+-- @usage e.g.: un-minimize all urxvt instances
+-- pcode
+-- local urxvt = function (c) br/
+-- return awful.rules.match(c, {class = URxvt}) br/
+-- end br/
+-- /br
+-- for c in awful.client.cycle(urxvt) do br/
+-- c.minimized = false br/
+-- end br/
+-- /code/p
+function cycle(filter, start, s)
+local clients = capi.client.get(s)
+local focused = capi.client.focus
+local start = start or util.table.hasitem(clients, focused)
+return util.table.cycle(clients, filter, start)
+end
+
-- Register standards signals
capi.client.add_signal(property::floating_geometry)
capi.client.add_signal(property::floating)
--
1.7.9
Re: [patch] filter tables
On Fri, Feb 17, 2012 at 8:41 PM, Anurag Priyam anurag08pri...@gmail.com wrote: Also: Urgh, really have to add br / inside of code examples? :-( Yeah. Otherwise all code comes up on the same line in the final HTML out. This is the most important reason for which I want to see markdown in commit messages. I meant documentation. Finally: What about indentation? Luadoc ignores it. IIRC, only one code example in the entire doc uses indentation: awful.menu.new. It is painfully difficult to add indentation; see 514fd796f3272583ee409b784fcd9ee2a6f95875 (one of my first patches :-|). Even if you use pre tag around it. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [patch] filter tables
On Fri, Feb 17, 2012 at 8:52 PM, Uli Schlachter psyc...@znc.in wrote:
Thanks, both patches are merged. However, I had to mess with the commit
messages
(my git hooks refuse commits with a too long summary) and I added some luadoc
for the new s argument.
Yeah, first one was 80 or 81 chars. Thanks for the luadoc :).
Sadly, cherry pick into 3.4 failed, so this won't end up in 3.4.12 (no, I will
not manually fix up stuff).
It conflicts because modeline changed in
c2ea920ca016a8f19d464fd8a961ad45afcce8b3 !!
PFA, the same patches based on 3.4 branch.
--
Anurag Priyam
From 7107b73aaca96a829628df6aed6c234dff2d53df Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Fri, 17 Feb 2012 02:30:41 +0530
Subject: [PATCH 1/2] add awful.util.table.cycle
awful.util.table.cycle iterates through elements of the table that match the
given condition.
This will help writing concise code when one wants to apply a function to
(read, take some action) on a select list of elements in a table (of say,
clients and tags).
Conflicts:
lib/awful/util.lua.in
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/util.lua.in | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/lib/awful/util.lua.in b/lib/awful/util.lua.in
index ce14e32..77ba55c 100644
--- a/lib/awful/util.lua.in
+++ b/lib/awful/util.lua.in
@@ -363,4 +363,25 @@ function table.clone(t)
return c
end
+---
+-- Returns an iterator to cycle through, starting from the first element or the
+-- given index, all elments of a table that match a given criteria.
+-- @param t the table to iterate
+-- @param filter a function that returns true to indicate a positive match
+-- @param start what index to start iterating from. Default is 1 (= start of
+-- the table)
+function table.cycle(t, filter, start)
+local count = 0
+local index = start or 1
+local length = #t
+
+return function ()
+while count length do
+local item = t[index]
+index = cycle(#t, index + 1)
+count = count + 1
+if filter(item) then return item end
+end
+end
+end
-- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
--
1.7.9
From 64a2d05e765b2f8af58dfbc0324d24b3ad69db2c Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Fri, 17 Feb 2012 02:32:28 +0530
Subject: [PATCH 2/2] add awful.client.cycle
add awful.client.cycle to iterate through clients that match a given condition
A common use case is to cycle through clients that match a given rule and take
certain action on them: raise, set or get property, etc.; see usage example in
the docs.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/client.lua.in | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/lib/awful/client.lua.in b/lib/awful/client.lua.in
index b63a646..fa60566 100644
--- a/lib/awful/client.lua.in
+++ b/lib/awful/client.lua.in
@@ -862,6 +862,30 @@ function property.set(c, prop, value)
c:emit_signal(property:: .. prop)
end
+---
+-- Returns an iterator to cycle through, starting from the client in focus or
+-- the given index, all clients that match a given criteria.
+-- @param filter a function that returns true to indicate a positive match
+-- @param start what index to start iterating from. Defaults to using the
+-- index of the currently focused client.
+-- @param s which screen to use. nil means all screens.
+-- @usage e.g.: un-minimize all urxvt instances
+-- pcode
+-- local urxvt = function (c) br/
+-- return awful.rules.match(c, {class = URxvt}) br/
+-- end br/
+-- /br
+-- for c in awful.client.cycle(urxvt) do br/
+-- c.minimized = false br/
+-- end br/
+-- /code/p
+function cycle(filter, start, s)
+local clients = capi.client.get(s)
+local focused = capi.client.focus
+local start = start or util.table.hasitem(clients, focused)
+return util.table.cycle(clients, filter, start)
+end
+
-- Register standards signals
capi.client.add_signal(focus, focus.history.add)
capi.client.add_signal(unmanage, focus.history.delete)
--
1.7.9
Re: Switch focus to window by absolute index?
On Thu, Feb 16, 2012 at 5:20 AM, Derek Thurn de...@thurn.ca wrote:
The motivation behind this is that I want a keyboard shortcut that
does something like always switch to this chrome window, regardless
of which client and screen currently has focus. I figure I could just
make sure the right chrome window always have absolute position 1 in
the client list, and then write a keyboard shortcut that always
switches to position one.
Or you can select chrome from the list of clients based on client properties:
-- untested
local clients = client.get()
local property = {class = Google-chrome}
for _, c in ipairs(clients) do
if (awful.rule.match(c, property) then return c end
end
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Autostart application on specific tag (not permanent with awful.rules.rules)
On Thu, Feb 16, 2012 at 10:25 PM, Paweł Rumian gork...@gmail.com wrote: is it possible to place application to a specific tag of specific screen when autostarting, but not making it permanent for all similar applications? E.g. I want to open terminal at tag 4 of screen 2, but obviously auto-putting ALL further terminal windows there makes no sense. Easiest would be no rules + go to screen 2 tag 4 to launch your first terminal :-|. When I had multiple tags, I used to 'summon' the same terminal (running tmux for tabs) on whatever workspace I was on. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Autostart application on specific tag (not permanent with awful.rules.rules)
On Thu, Feb 16, 2012 at 10:25 PM, Paweł Rumian gork...@gmail.com wrote:
is it possible to place application to a specific tag of specific
screen when autostarting, but not making it permanent for all similar
applications?
You can probably do this using a callbacks in rules:
E.g. I want to open terminal at tag 4 of screen 2, but obviously
auto-putting ALL further terminal windows there makes no sense.
We check if the terminal launched is the first one then put it on
screen 2 tag 4, otherwise do nothing.
{ rule = { class = URxvt },
-- properties = {},
callback = function(cl)
local clients = client.get()
local property = {class = URxvt}
-- return if a terminal is in the client list already
for _, c in ipairs(clients) do
if (awful.rule.match(c, property) then return end
end
-- if this gets executed, it must be the first terminal to be
-- invoked, so we move it to a tag
c:tags({tags[2][4]})
end
},
Sorry, I can't test it because I use one tag only.
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Autostart application on specific tag (not permanent with awful.rules.rules)
[+CC: awesome@naquadah.org]
You forgot to CC the list :).
On Thu, Feb 16, 2012 at 11:35 PM, Paweł Rumian gork...@gmail.com wrote:
Thank you very much for your solution Anurag - unfortunately it's not
THAT easy.
Saying about 'terminal' was an unnecessary simplification made by me -
in fact it is a monitoring application opened in urxvt. And there
should be two or sometimes three instances of it...
Of course they are all reporting WM_CLASS=urxvt, and the same WM_NAME.
Doesn't `-name` option of urxvt help? For a terminal launched as:
$ urxvt -name foo
you can match it in awesome with:
{ rule = { instance = foo },
...
}
Opening three terminals by hand and launching the clients inside is
what I do now, I just wanted to simplify this.
And you can directly run a command with `-e` switch:
urxvt -name irssi -e irssi
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Switch focus to window by absolute index?
On Fri, Feb 17, 2012 at 1:30 AM, Derek Thurn de...@thurn.ca wrote: That works unless I have multiple Chrome windows, which is why I thought about absolute positioning. function next_client(property) local clients = client.get() local start= awful.util.table.hasitem(clients, client.focus) local i = start repeat i = awful.util.cycle(#clients, i + 1) if (awful.rule.match(clients[i], property) then return clients[i] end until i == start -- full cycle end Untested. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
[patch] filter tables
It seems to be a common idiom to apply a particular operation on select elements of a table. Something like: for _, i in pairs(t) do if (func1(i)) then func2(i) end end So, how about (first patch) : --- lib/awful/util.lua.in | 9 + [...] +--- +-- For each element that matches the filtering criteria, call the callback +-- function, passing it the matched element. If the callback returns true, +-- further matching is terminated. +function table.apply(t, filter, callback) + for _, i in pairs(t) do + if filter(i) and callback(i) == false then return end + end +end The functionality to terminate matching by returning false can be useful if one wants to take an action on only the first matching item, like raising a client, etc. Next we define wrappers in awful.client (second patch) and awful.tag: --- lib/awful/client.lua.in |6 ++ [...] +--- +-- Filter clients. +function apply(filter, callback) +util.table.apply(capi.client.get(), filter, callback) +end However, most of the times starting to iterate from the currently focused client helps, so I can iterate through Chrome instances in order starting from the one focused. But I am not sure how to best incorporate that. Naive approach is to add a starting index to the apply function but that dirties the API. Can you implement that using an appropriate filtering function somehow (using closures or something)? Common filters can be included in the distribution or re-used from awful.widget.tasklist? If you like the idea I will document the functions, write proper commit message and re-send the patches. -- Anurag Priyam From 397d3a41f158d433be5199b828c622f89f1552b0 Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Fri, 17 Feb 2012 02:30:41 +0530 Subject: [PATCH 1/2] add awful.util.table.apply --- lib/awful/util.lua.in |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/lib/awful/util.lua.in b/lib/awful/util.lua.in index 1c719a7..47f99e5 100644 --- a/lib/awful/util.lua.in +++ b/lib/awful/util.lua.in @@ -367,4 +367,13 @@ function table.clone(t) return c end +--- +-- For each element that matches the filtering criteria, call the callback +-- function, passing it the matched element. If the callback returns true, +-- further matching is terminated. +function table.apply(t, filter, callback) +for _, i in pairs(t) do +if filter(i) and callback(i) == false then return end +end +end -- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:textwidth=80 -- 1.7.9 From f2a2594f75ea54d05d18af6c6314742259cd8944 Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Fri, 17 Feb 2012 02:32:28 +0530 Subject: [PATCH 2/2] add awful.client.apply --- lib/awful/client.lua.in |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/lib/awful/client.lua.in b/lib/awful/client.lua.in index 2d5ec45..78d426a 100644 --- a/lib/awful/client.lua.in +++ b/lib/awful/client.lua.in @@ -862,6 +862,12 @@ function property.set(c, prop, value) c:emit_signal(property:: .. prop) end +--- +-- Filter clients. +function apply(filter, callback) +util.table.apply(capi.client.get(), filter, callback) +end + -- Register standards signals capi.client.add_signal(property::floating_geometry) capi.client.add_signal(property::floating) -- 1.7.9
Re: [patch] filter tables
On Fri, Feb 17, 2012 at 4:01 AM, Anurag Priyam anurag08pri...@gmail.com wrote: [...] However, most of the times starting to iterate from the currently focused client helps, so I can iterate through Chrome instances in order starting from the one focused. I started off wanting to make this task easy -- iterating through clients based on certain rules/filter. Maybe all I need is a generic function that lets me iterate through collections based on the given criteria. Something like (if it is possible) : for c in awful.client.cycle(filter) do ... end Let me try again :). -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [patch] cycle through marked clients
On Tue, Feb 7, 2012 at 2:23 AM, Uli Schlachter psyc...@znc.in wrote: On 05.02.2012 22:30, Anurag Priyam wrote: This was discussed sometime back on the users list: http://comments.gmane.org/gmane.comp.window-managers.awesome/7290. I wonder if it would be of general interest. He, almost a year old :-) Yeah. I remembered since I had posted to that thread :). [...] +do + -- iteration state + local i = 0 I don't think I like this. Couldn't you lookup client.focus in the list of marked clients and cycle based on that? That would indeed be better. In fact, the code snippet I had posted in the previous (year old) thread starts iteration from the currently focused client :-|. [...] This also raises the question of what exactly is marking a client supposed to do?. From the existing code it looks like one is supposed to mark a couple of clients and then do something with all of them at once. I realized this much later. [...] Cycling through marked clients doesn't really fit into that use IMHO. This would then just reimplement tags, wouldn't it? Right. I probably developed this workflow because I never figured how to use tags effectively (I don't use tags now). Let's scrap this patch then. It might encourage incorrect practice. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[patch] cycle through marked clients
Hi,
This was discussed sometime back on the users list:
http://comments.gmane.org/gmane.comp.window-managers.awesome/7290. I
wonder if it would be of general interest.
diff --git a/lib/awful/client.lua.in b/lib/awful/client.lua.in
index 2d5ec45..e0d6ded 100644
--- a/lib/awful/client.lua.in
+++ b/lib/awful/client.lua.in
@@ -38,6 +38,7 @@ swap = {}
floating = {}
dockable = {}
property = {}
+marked = {}
--- Get the first client that got the urgent hint.
-- @return The first urgent client.
@@ -554,6 +555,23 @@ function getmarked()
return t
end
+do
+-- iteration state
+local i = 0
+
+---
+-- Cycle through marked clients.
+function marked.cycle()
+i = i + 1
+
+local clients = data.marked
+local c = clients[util.cycle(#clients, i)]
+
+tag.viewonly(c:tags()[1])
+capi.client.focus = c
+end
+end
+
--
Anurag Priyam
From 3cf63102f9d74e72c1e621045234dfb92378d952 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Sun, 5 Feb 2012 17:59:25 +0530
Subject: [PATCH] awful.client: add helper method to cycle through marked
clients
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/client.lua.in | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/lib/awful/client.lua.in b/lib/awful/client.lua.in
index 2d5ec45..e0d6ded 100644
--- a/lib/awful/client.lua.in
+++ b/lib/awful/client.lua.in
@@ -38,6 +38,7 @@ swap = {}
floating = {}
dockable = {}
property = {}
+marked = {}
--- Get the first client that got the urgent hint.
-- @return The first urgent client.
@@ -554,6 +555,23 @@ function getmarked()
return t
end
+do
+-- iteration state
+local i = 0
+
+---
+-- Cycle through marked clients.
+function marked.cycle()
+i = i + 1
+
+local clients = data.marked
+local c = clients[util.cycle(#clients, i)]
+
+tag.viewonly(c:tags()[1])
+capi.client.focus = c
+end
+end
+
--- Set a client floating state, overriding auto-detection.
-- Floating client are not handled by tiling layouts.
-- @param c A client.
--
1.7.9
Re: Missing line numbers and more weirdness with vim
On Fri, Jan 27, 2012 at 9:05 AM, Perry Hargrave resix...@gmail.com wrote: Do you get the problem with vim -u NONE Or with gvim? -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Awesome wm in Kindle Touch!
On Sun, Jan 22, 2012 at 7:32 PM, Uli Schlachter psyc...@znc.in wrote: [Lot's of guesswork here] Indeed. So anyone feels like asking gpl-violations.org for their input? IMHO this isn't a big violation. They are publishing everything, they just added their own copyright/license header where there previously wasn't one at all. Still, the default config should be covered by the GPL. Publishing code online hardly means anything. We need to be looking at ways to get Amazon involved with our community. And by knowing if and how Amazon violates GPL, we can _probably_ take step in that direction. For example, if GPL requires them to submit modifications (if any) back to the community we ask them to do so, and make sure they feel welcomed (which Uli is pretty good at :)). Immediate advantages of having Amazon on our side is that they can sponsor Awesome's development by hiring Uli and/or others or asking their developers to work 20% on Awesome. I own a Kindle, so in the long term I see the 'community' (Amazon included) evolving a system where I can configure my Kindle the way I configure my workstation (running Awesome). And even submit the modifications upstream for others to use. We could be collectively engineering the user interface of Kindle. Now imagine a generation of devices based on this same idea ... [more childlike vision of the world here :D]. I am thrilled. Amazon has a history of having build on open source but not contributing back. They know it. We know it. But as far as I know, they are trying to change that. Let's help them out. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Awesome wm in Kindle Touch!
On Wed, Jan 25, 2012 at 8:45 AM, Anurag Priyam anurag08pri...@gmail.com wrote: We could be collectively engineering the user interface of Kindle. Not just the user interface but also the software feature set depending on the hardware capabilities. Of course, there are a lot of parameters in the equation and it is more easily said than done. But you get the general idea. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Awesome wm in Kindle Touch!
On Sun, Jan 22, 2012 at 7:32 PM, Uli Schlachter psyc...@znc.in wrote: [Lot's of guesswork here] So anyone feels like asking gpl-violations.org for their input? I will see if I can get anything done in this regard in the coming weekend. Too many assignment submission to take care of till then :-|. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: tooltip bug?
On Sun, Jan 15, 2012 at 8:43 PM, Uli Schlachter psyc...@znc.in wrote:
Patch gets a NACK, see next paragraph. :-)
Attached is a 3 parts series I wrote in the evening, but decided to
get a snack before sending it to the list. The first can be applied as
it is, but I will need to re-roll 2nd and 3rd to account for the
changes you just made. I am still sending the original series in case
you decide my approach is better and want to revert your commit -- I
decided to put the `by_ccord` in `awful.screen` as
`awful.screen.getbycoord`.
--
Anurag Priyam
From 91d63bda08e02d91301894d46617d1d5176ca976 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Sun, 15 Jan 2012 16:42:03 +0530
Subject: [PATCH 1/3] do not set non existent, screen property on wiboxes
The `screen` property on wibox (drawin) was removed in the commit - 'drawin:
Remove screen property'.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/mouse/finder.lua.in |2 --
lib/awful/tooltip.lua.in |2 --
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/lib/awful/mouse/finder.lua.in b/lib/awful/mouse/finder.lua.in
index 32c9b52..d1d61fb 100644
--- a/lib/awful/mouse/finder.lua.in
+++ b/lib/awful/mouse/finder.lua.in
@@ -77,8 +77,6 @@ local function show(self)
-- do nothing if the mouse finder is already shown
if data[self].wibox.visible then return end
if not data[self].timer.started then
--- make sure the mouse finder is on the same screen as the mouse
-data[self].wibox.screen = mouse.screen
data[self].wibox:geometry({width = data[self].radius, height = data[self].radius })
a_wibox.rounded_corners(data[self].wibox, data[self].radius/2 -1)
data[self].timer:start()
diff --git a/lib/awful/tooltip.lua.in b/lib/awful/tooltip.lua.in
index 92dad35..49b0b7b 100644
--- a/lib/awful/tooltip.lua.in
+++ b/lib/awful/tooltip.lua.in
@@ -92,8 +92,6 @@ end
local function show(self)
-- do nothing if the tooltip is already shown
if self.visible then return end
--- make sure the tooltip is on the same screen as the mouse
-self.wibox.screen = mouse.screen
if data[self].timer then
if not data[self].timer.started then
data[self].timer_function()
--
1.7.8.2
From 34b63837c78d6cebd53c7929a672e0a2a2e40c7d Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Sun, 15 Jan 2012 15:58:17 +0530
Subject: [PATCH 2/3] awful.screen: define getbycoord() to compute screen
number of a pixel
Given an object's coordinates, `awful.screen.getbycoord` can be used to
determine the screen than the object is, or should be attached to.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/screen.lua.in | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/lib/awful/screen.lua.in b/lib/awful/screen.lua.in
index d15d516..9fba87b 100644
--- a/lib/awful/screen.lua.in
+++ b/lib/awful/screen.lua.in
@@ -20,6 +20,22 @@ module(awful.screen)
local data = {}
data.padding = {}
+---
+-- Return Xinerama screen number corresponding to the given (pixel) coordinates.
+-- The number returned can be used as an index into the global
+-- `screen` table/object.
+-- @param x The x coordinate
+-- @param y The y coordinate
+function getbycoord(x, y)
+for i = 1, capi.screen:count() do
+local geometry = capi.screen[i].geometry
+if((x 0 or (x = geometry.x and x geometry.x + geometry.width))
+ and (y 0 or (y = geometry.y and y geometry.y + geometry.height))) then
+return i;
+end
+end
+end
+
--- Give the focus to a screen, and move pointer.
-- @param screen Screen number.
function focus(screen)
--
1.7.8.2
From c8255ad2a968a8426281c73c6b5ed47e5f782531 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Sun, 15 Jan 2012 16:27:47 +0530
Subject: [PATCH 3/3] awful.placement: can now operate on any object with a
set geometry
So the utility of `awful.placement` is not merely limited to client objects,
but also to wiboxes.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/placement.lua.in | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/lib/awful/placement.lua.in b/lib/awful/placement.lua.in
index fa3d37b..a3d0926 100644
--- a/lib/awful/placement.lua.in
+++ b/lib/awful/placement.lua.in
@@ -16,6 +16,7 @@ local capi =
client = client
}
local client = require(awful.client)
+local screen = require(awful.screen)
local layout = require(awful.layout)
--- Places client according to special criteria.
@@ -105,8 +106,9 @@ end
function no_offscreen(c)
local c = c or capi.client.focus
local geometry = c:geometry()
+local screen = c.screen or screen.getbycoord(geometry.x, geometry.y)
local border = c.border_width
-local screen_geometry = capi.screen[c.screen].workarea
+local screen_geometry = capi.screen[screen
Re: tooltip bug?
On Sun, Jan 15, 2012 at 8:49 PM, Uli Schlachter psyc...@znc.in wrote:
So I guess just a new patch which fixes this problem via the new
screen.by_coords(x, y)?
I tried the attached patch (based on `screen.by_coords()), but I am
getting the following stack trace:
W: awesome: luaA_dofunction:108: error while running function
stack traceback:
[C]: ?
/usr/local/share/awesome/lib/awful/placement.lua:110: in function
'no_offscreen'
/usr/local/share/awesome/lib/awful/tooltip.lua:72: in function 'place'
/usr/local/share/awesome/lib/awful/tooltip.lua:86: in function
'set_geometry'
/usr/local/share/awesome/lib/awful/tooltip.lua:101: in function 'show'
/usr/local/share/awesome/lib/awful/tooltip.lua:186: in function 'func'
/usr/local/share/awesome/lib/gears/object.lua:71: in function
'emit_signal'
/usr/local/share/awesome/lib/wibox/init.lua:177: in function
'emit_difference'
/usr/local/share/awesome/lib/wibox/init.lua:202: in function 'func'
/usr/local/share/awesome/lib/gears/object.lua:71: in function
'emit_signal'
/usr/local/share/awesome/lib/wibox/init.lua:214: in function
/usr/local/share/awesome/lib/wibox/init.lua:213
error: /usr/local/share/awesome/lib/awful/placement.lua:110: bad
argument #2 to '?' (number expected, got userdata)
--
Anurag Priyam
From a6235a16e264303bbdb12b977c3273ad105f2a32 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Sun, 15 Jan 2012 16:27:47 +0530
Subject: [PATCH] awful.placement: can now operate on any object with a set
geometry
So the utility of `awful.placement` is not merely limited to client objects,
but also to wiboxes.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/placement.lua.in | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/lib/awful/placement.lua.in b/lib/awful/placement.lua.in
index fa3d37b..7fcc5ad 100644
--- a/lib/awful/placement.lua.in
+++ b/lib/awful/placement.lua.in
@@ -105,8 +105,9 @@ end
function no_offscreen(c)
local c = c or capi.client.focus
local geometry = c:geometry()
+local screen = c.screen or capi.screen.by_coords(geometry.x, geometry.y)
local border = c.border_width
-local screen_geometry = capi.screen[c.screen].workarea
+local screen_geometry = capi.screen[screen].workarea
if geometry.x + geometry.width + 2*border screen_geometry.x + screen_geometry.width then
geometry.x = screen_geometry.x + screen_geometry.width - geometry.width
@@ -126,10 +127,11 @@ end
--- Place the client where there's place available with minimum overlap.
-- @param c The client.
function no_overlap(c)
-local cls = client.visible(c.screen)
+local cls = client.visible(screen)
local curlay = layout.get()
-local areas = { capi.screen[c.screen].workarea }
+local areas = { capi.screen[screen].workarea }
local geometry = c:geometry()
+local screen = c.screen or capi.screen.by_coords(geometry.x, geometry.y)
for i, cl in pairs(cls) do
if cl ~= c and cl.type ~= desktop and (client.floating.get(cl) or curlay == layout.suit.floating) then
areas = area_remove(areas, cl:geometry())
@@ -192,11 +194,12 @@ end
function centered(c, p)
local c = c or capi.client.focus
local c_geometry = c:geometry()
+local screen = c.screen or capi.screen.by_coords(c_geometry.x, c_geometry.y)
local s_geometry
if p then
s_geometry = p:geometry()
else
-s_geometry = capi.screen[c.screen].geometry
+s_geometry = capi.screen[screen].geometry
end
return c:geometry({ x = s_geometry.x + (s_geometry.width - c_geometry.width) / 2,
y = s_geometry.y + (s_geometry.height - c_geometry.height) / 2 })
@@ -209,11 +212,12 @@ end
function center_horizontal(c, p)
local c = c or capi.client.focus
local c_geometry = c:geometry()
+local screen = c.screen or capi.screen.by_coords(c_geometry.x, c_geometry.y)
local s_geometry
if p then
s_geometry = p:geometry()
else
-s_geometry = capi.screen[c.screen].geometry
+s_geometry = capi.screen[screen].geometry
end
return c:geometry({ x = s_geometry.x + (s_geometry.width - c_geometry.width) / 2 })
end
@@ -225,11 +229,12 @@ end
function center_vertical(c, p)
local c = c or capi.client.focus
local c_geometry = c:geometry()
+local screen = c.screen or capi.screen.by_coords(c_geometry.x, c_geometry.y)
local s_geometry
if p then
s_geometry = p:geometry()
else
-s_geometry = capi.screen[c.screen].geometry
+s_geometry = capi.screen[screen].geometry
end
return c:geometry({ y = s_geometry.y + (s_geometry.height - c_geometry.height) / 2 })
end
--
1.7.8.2
Re: tooltip bug?
On Sun, Jan 15, 2012 at 9:26 PM, Uli Schlachter psyc...@znc.in wrote:
Heh. First two patches are merged.
Cool.
For the third one:
local client = require(awful.client)
+local screen = require(awful.screen)
[...]
function no_offscreen(c)
local c = c or capi.client.focus
local geometry = c:geometry()
+ local screen = c.screen or screen.getbycoord(geometry.x, geometry.y)
We now have two variables named screen, the global one and the local one. Also
local foo = bar or foo.foobar() looks weird.
However, I don't have any ideas how to change that. The best I can think of is
local a_screen = require(awful.screen) instead of the above version.
I went with that since that seems to be the convention.
+ local cls = client.visible(screen)
Uhm, what?! This doesn't look like it has any chance of not erroring out.
Oops. This is why I waited to get a snack before sending the patch
series; I intended to review and hopefully catch this silly error. But
seeing your mail the first thing when I got back, I couldn't resist.
(client.visible() will call capi.client.get(screen) and the C code will
complain
that awful.screen is not a screen object)
You mean index, not screen object, right?
Search and replace error?
Yep :-|. My tooltip was working, so that lowered my guards too.
Fixed in the attached patch.
git fetch origin isn't returning anything. You messaged too early?
Or server issues?
--
Anurag Priyam
From 44d6903d983d1690a5e6725409075e415ffa9472 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Sun, 15 Jan 2012 16:27:47 +0530
Subject: [PATCH] awful.placement: can now operate on any object with a set
geometry
So the utility of `awful.placement` is not merely limited to client objects,
but also to wiboxes.
[us: use appropriate naming convention; catch misplaced statement]
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/placement.lua.in | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/lib/awful/placement.lua.in b/lib/awful/placement.lua.in
index fa3d37b..9520faa 100644
--- a/lib/awful/placement.lua.in
+++ b/lib/awful/placement.lua.in
@@ -17,6 +17,7 @@ local capi =
}
local client = require(awful.client)
local layout = require(awful.layout)
+local a_screen = require(awful.screen)
--- Places client according to special criteria.
module(awful.placement)
@@ -105,8 +106,9 @@ end
function no_offscreen(c)
local c = c or capi.client.focus
local geometry = c:geometry()
+local screen = c.screen or a_screen.getbycoord(geometry.x, geometry.y)
local border = c.border_width
-local screen_geometry = capi.screen[c.screen].workarea
+local screen_geometry = capi.screen[screen].workarea
if geometry.x + geometry.width + 2*border screen_geometry.x + screen_geometry.width then
geometry.x = screen_geometry.x + screen_geometry.width - geometry.width
@@ -126,10 +128,11 @@ end
--- Place the client where there's place available with minimum overlap.
-- @param c The client.
function no_overlap(c)
-local cls = client.visible(c.screen)
-local curlay = layout.get()
-local areas = { capi.screen[c.screen].workarea }
local geometry = c:geometry()
+local screen = c.screen or a_screen.getbycoord(geometry.x, geometry.y)
+local cls = client.visible(screen)
+local curlay = layout.get()
+local areas = { capi.screen[screen].workarea }
for i, cl in pairs(cls) do
if cl ~= c and cl.type ~= desktop and (client.floating.get(cl) or curlay == layout.suit.floating) then
areas = area_remove(areas, cl:geometry())
@@ -192,11 +195,12 @@ end
function centered(c, p)
local c = c or capi.client.focus
local c_geometry = c:geometry()
+local screen = c.screen or a_screen.getbycoord(c_geometry.x, c_geometry.y)
local s_geometry
if p then
s_geometry = p:geometry()
else
-s_geometry = capi.screen[c.screen].geometry
+s_geometry = capi.screen[screen].geometry
end
return c:geometry({ x = s_geometry.x + (s_geometry.width - c_geometry.width) / 2,
y = s_geometry.y + (s_geometry.height - c_geometry.height) / 2 })
@@ -209,11 +213,12 @@ end
function center_horizontal(c, p)
local c = c or capi.client.focus
local c_geometry = c:geometry()
+local screen = c.screen or a_screen.getbycoord(c_geometry.x, c_geometry.y)
local s_geometry
if p then
s_geometry = p:geometry()
else
-s_geometry = capi.screen[c.screen].geometry
+s_geometry = capi.screen[screen].geometry
end
return c:geometry({ x = s_geometry.x + (s_geometry.width - c_geometry.width) / 2 })
end
@@ -225,11 +230,12 @@ end
function center_vertical(c, p)
local c = c or capi.client.focus
local c_geometry = c:geometry()
+local screen = c.screen or a_screen.getbycoord(c_geometry.x, c_geometry.y)
local s_geometry
if p
Re: tooltip bug?
On Sun, Jan 15, 2012 at 9:56 PM, Anurag Priyam anurag08pri...@gmail.com wrote: Fixed in the attached patch. Author: Anurag Priyam anurag08pri...@gmail.com Date: Sun Jan 15 16:27:47 2012 +0530 awful.placement: can now operate on any object with a set geometry So the utility of `awful.placement` is not merely limited to client objects, but also to wiboxes. [us: use appropriate naming convention; catch misplaced statement] This is something I picked from git.git (no, I am not a git contributor, but I do read the code and git log and git mailing list sometimes): 'us' is your initials. It can always be uniquely looked up from the list of 'Signed-off-by' at the end of the commit message. Followed by it is a small description of how you contributed to the patch. Ideally, you would have made the change yourself (unless the patch needs a complete rewrite), add your contribution to the commit message in the above format, and sign off. Basically, it tracks almost everything that went into creating that patch: me as the author, your as reviewer cum improver, ... Since you sign off again anyway, I took the liberty of adding that for you. Feel free to remove it. Signed-off-by: Anurag Priyam anurag08pri...@gmail.com -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: tooltip bug?
On Fri, Jan 13, 2012 at 10:20 PM, Uli Schlachter psyc...@znc.in wrote: On 13.01.2012 15:17, Anurag Priyam wrote: [...] That essentially means awful.tooltip and awful.mouse.finder are broken (in git master). Doesn't look like it has anything to do with my particular setup. I will see if I can fix it later. Looking through awful.mouse.finder, I can only find one place where .screen is still used and that can just be dropped. [...] local screen = c.screen or calculate_screen(c:geometry()) (Where calculate_screen() figures out on which screen the point given by arg.x and arg.y is, this is just what the old screen property did, too) This does seem like an easy fix for now. I have attached a patch for review. It is not the entire series; just an implementation of `calculate_screen` and its use in `awful.placement.no_offscreen`. I shamelessly copied the logic from `screen_getbycoord` in `screen.c`. Can't I somehow just call `screen_getbycoord` from Lua, instead of re-implementing it in Lua? So, Xinerama treats multiple heads as one giant screen? I can't see how this logic could possibly work otherwise. Also, would you prefer local screen = c.screen or c:screen() instead? And perhaps define `screen()` in drawin? Alternatively someone could come up with a magic way to modify common/luaobject.c so that lua code can add arbitrary properties to an object. That'd be nicer, but I don't see that happening any time soon. :-( +1. This would be super awesome. I am completely oblivious to the lua-C interface, but still, how do you think can one approach this? -- Anurag Priyam From 951d504be596758c8369b2e7987610d7d4121798 Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Sat, 14 Jan 2012 17:29:33 +0530 Subject: [PATCH] awful.tooltip: determine screen number from client geometry --- lib/awful/placement.lua.in | 18 +- 1 files changed, 17 insertions(+), 1 deletions(-) diff --git a/lib/awful/placement.lua.in b/lib/awful/placement.lua.in index fa3d37b..0e8bd19 100644 --- a/lib/awful/placement.lua.in +++ b/lib/awful/placement.lua.in @@ -21,6 +21,21 @@ local layout = require(awful.layout) --- Places client according to special criteria. module(awful.placement) +-- Compute screen number of an object from the given geometry +-- @param geometry +local function calculate_screen(geometry) +local x = geometry.x +local y = geometry.y + +for i = 1, capi.screen:count() do +local s_geometry = capi.screen[i].geometry +if((x 0 or (x = s_geometry.x and x s_geometry.x + s_geometry.width)) + and (y 0 or (y = s_geometry.y and y s_geometry.y + s_geometry.height))) then +return i; +end +end +end + -- Check if an area intersect another area. -- @param a The area. -- @param b The other area. @@ -105,8 +120,9 @@ end function no_offscreen(c) local c = c or capi.client.focus local geometry = c:geometry() +local screen = c.screen or calculate_screen(geometry) local border = c.border_width -local screen_geometry = capi.screen[c.screen].workarea +local screen_geometry = capi.screen[screen].workarea if geometry.x + geometry.width + 2*border screen_geometry.x + screen_geometry.width then geometry.x = screen_geometry.x + screen_geometry.width - geometry.width -- 1.7.8.2
Re: tooltip bug?
On Thu, Jan 12, 2012 at 8:04 PM, Uli Schlachter psyc...@znc.in wrote: On 12.01.2012 10:27, Anurag Priyam wrote: self.wibox.screen = mouse.screen [...] How would you explain that? Meh. You are using git master. commit 08cd44dda71b2c62d441941c50c64e1165975d7b Author: Uli Schlachter psyc...@znc.in Date: Sun Mar 27 16:21:49 2011 +0200 drawin: Remove screen property That essentially means awful.tooltip and awful.mouse.finder are broken (in git master). Doesn't look like it has anything to do with my particular setup. I will see if I can fix it later. -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [RFC] documentation system (was: [PATCH] gears.colors)
On Fri, Jan 13, 2012 at 1:14 PM, Uli Schlachter psyc...@znc.in wrote: On 11.01.2012 14:30, Anurag Priyam wrote: I am not sure how exactly to proceed, but here is the general idea: [...] * figure out how to integrate into awesome's build system This last step can be skipped. I'd volunteer for integrating this with cmake (and all other parts which dont have to be done immediately and are annoying). Cool. Thanks :). 2. See if luadoc supports custom templates * choose, or write (this will be painful; I suck at design) one for Awesome, to be used at https://awesome.naquadah.org/doc/api/ JD, do you want to make a webpage? If luadoc supports templates, it should be pretty easy. The inspiration for me, here, are the documentation tools in Ruby. Particularly, [Yard][1]. See the following page for example, created with Yard for one of my projects: http://rubydoc.info/github/yannickwurm/sequenceserver/frames Looks elegant and is even searchable. Though I never dug into Yard to see how the searching is implemented. Not sure if luadoc can do it, and if it is worth implementing it. These are the sort of ideas I meant for step 3 (other goodies) later. I definitely can't work on this before 21st of Jan. Probably not till Jan end actually. But, if anyone finds this particularly interesting, and have time, please, by all means, go ahead with it. I will join hands as soon as I can find time. I have put up a clone of awesome on Github: http://github.com/yeban/awesome. So you can easily track when I am on it. I might have time from march 1st for two weeks (then I'll be offline for a while)... Hmm. I certainly wouldn't miss luadoc syntax. I wouldn't miss luadoc either. I once managed to break luadoc and then had to figure out from the lua error which documentation bit was wrong. Urgh. Luadoc doesn't go away; we leverage it. Besides that, I have to admit that I don't test the luadoc documentation (= I don't have luadoc installed and thus wouldn't notice if it errors out). Wow! :P However, I have some questions: How do you intend to use markdown from lua? Is there a lua-markdown library which is even less common than luadoc? There is lua-discount which is a Lua wrapper over the Discount markdown library in C. I had mentioned it in the previos Also, why markdown? It is nice for e.g. writing webpages, but for documentation it misses stuff like @param. So if everyone comes up with his own syntaxes for function arguments, return values, etc then this might come out messy. Luadoc semantics still apply. From what I understand, luadoc parses the comments in a given source file and converts it into an internal structure (sort of like an object model) first. Next, you process this internal structure to produce final HTML output. This is where Markdown steps in. You can customize both the steps by defining custom tags and output generator respectively. See http://keplerproject.github.com/luadoc/architecture.html. I am hoping that I will be able to convert this internal representation into something directly consumable by lua-discount. [1]: http://yardoc.org/ -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
tooltip bug?
Looks like I have hit a bug with awful.tooltip.
Tooltip creation:
gmailwidget = wibox.widget.textbox()
gmailwidget_t = awful.tooltip({ objects = { gmailwidget, mailicon
}, timer_function = function () return 'meh' end})
Now when I point my mouse at `gmailwidget` or `mailicon`, I get the
following backtrace:
W: awesome: luaA_dofunction:108: error while running function
stack traceback:
[C]: ?
/usr/local/share/awesome/lib/awful/placement.lua:113: in function
'no_offscreen'
/usr/local/share/awesome/lib/awful/tooltip.lua:74: in function 'place'
/usr/local/share/awesome/lib/awful/tooltip.lua:85: in function
'set_geometry'
/usr/local/share/awesome/lib/awful/tooltip.lua:213: in function
'timer_function'
/usr/local/share/awesome/lib/awful/tooltip.lua:107: in function 'show'
/usr/local/share/awesome/lib/awful/tooltip.lua:196: in function 'func'
/usr/local/share/awesome/lib/gears/object.lua:71: in function
'emit_signal'
/usr/local/share/awesome/lib/wibox/init.lua:177: in function
'emit_difference'
/usr/local/share/awesome/lib/wibox/init.lua:202: in function 'func'
/usr/local/share/awesome/lib/gears/object.lua:71: in function
'emit_signal'
/usr/local/share/awesome/lib/wibox/init.lua:214: in function
/usr/local/share/awesome/lib/wibox/init.lua:213
error: /usr/local/share/awesome/lib/awful/placement.lua:113: bad
argument #2 to '?' (number expected, got nil)
So I looked into placement.lua, line 113, which is:
local screen_geometry = capi.screen[c.screen].workarea
There is only one argument in there, `c.screen`. So I put a print
statement there:
print(' in placement.no_offscreen *** ')
print(c.screen)
print(' ')
Compiled and re-installed awesome. And, lo:
...
in placement.no_offscreen ***
nil
...
WTF! `c.screen` is nil.
So I went looking in tooltip.lua to see how tooltip is created and the
screen is set. Looks like the following line in the function `show`:
self.wibox.screen = mouse.screen
I added some print statements there:
print(' in tooltip.show ')
print(mouse.screen)
print(self.wibox.screen)
self.wibox.screen = mouse.screen
print(self.wibox.screen)
print(' ')
Compiled and re-installed awesome. And the output this time is pretty weird:
...
in tooltip.show
1
nil
nil
...
How would you explain that?
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: gradients in master
On Wed, Jan 11, 2012 at 11:20 AM, Anurag Priyam
anurag08pri...@gmail.com wrote:
How would the following, 3.4.x code, translate to master:
[...]
-- but what about gradients ??
cpugraph:set_gradient_angle(0)
cpugraph:set_gradient_colors({ beautiful.fg_end_widget,
beautiful.fg_center_widget, beautiful.fg_widget
})
Ok, this seems to work:
cpugraph:set_color(linear:0,0:8,14:0,#FF5656:0.5,#88A175:1,#AECF96)
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: gradients in master
On Wed, Jan 11, 2012 at 5:05 PM, Uli Schlachter psyc...@znc.in wrote:
On 11.01.2012 09:50, Anurag Priyam wrote:
[...]
cpugraph:set_color(linear:0,0:8,14:0,#FF5656:0.5,#88A175:1,#AECF96)
nice to know you managed to fight through that mess.
Now that you saw the evil, any ideas how this syntax can be improved?
Perhaps it makes sense to bury the idea of this must be a string and turn
into tables again? Dunno.
I was initially very impressed by the string syntax. I still hold that
it is neat. But as soon as I had to define a linear gradient for my
memory usage graph (widget), picking color values from theme:
membar:set_color(linear:0,0:8,14:0, .. beautiful.fg_end_widget ..
:0.5, .. beautiful.fg_center_widget .. :1, .. beautiful.fg_widget)
I found myself wishing tables were supported, so I could write as:
membar:set_color({gradient = 'linear, from = {0,0}, to = { 8, 14 },
stops = {{ 0, beautiful.fg_end_widget}, {0.5,
beautiful.fg_center_widget}, {1, beautiful.fg_widget}})
This gives me a lot of flexibility. For example, I could _easily_
rewrite `to = {8, 14}` as `to = { width, height }`, where width and
height are width and height of my progressbar. It is easier to store
presets in a global config table, etc.
So I am definitely +1 for allowing tables.
Here is another idea, borrowed from [jQuery][1]:
membar:linear_gradient(0, 0, 8, 14):add_stop(0,
beautiful.fg_end_widget):add_stop(...)
It is called method chaining. Essentially, each method call returns an
object on which the next method can be called. Not sure if it can be
done in Lua and how easy/difficult it would be to implement. Besides,
this would make the API inconsistent.
P.S: Your code is pretty neat actually. The way redundancy has been
minimized with automatic function generation is super sweet.
[1]: http://jquery.com/
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: [PATCH] gears.colors: expose docs for 2 functions
On Wed, Jan 11, 2012 at 12:28 PM, Anurag Priyam
anurag08pri...@gmail.com wrote:
gears.color: expose documentation for create_(linear|radial)_pattern functions
Spotted a few more quirks in gears.color's documentation when looking
for a way to define gradients for graph and progressbar widgets:
1. 0002-gears.colors-docs-fix-pattern-string-used-in-the-exa.patch
gears.colors() docs: fix pattern string used in the example
In general, patterns are specified as 'type:arguments', where 'arguments' is
specific to the pattern used. The example provided in the documentation,
defined the pattern type to be 'linear', but used arguments meant to create
radial pattern. So we modify the example to use the correct type -- 'radial'.
[...]
2. 0003-gears.color-docs-replace-literal-and-with-respective.patch
gears.color docs: replace literal '' and '' with respective HTML entities
Luadoc confuses 'stop' with an HTML tag otherwise.
[...]
Both the patches are based off the one in the previous mail. Though,
they should apply cleanly in any order.
--
Anurag Priyam
From 43fca38aa71ec42660f2a08efca09c548e874082 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Wed, 11 Jan 2012 15:18:35 +0530
Subject: [PATCH 2/3] gears.colors() docs: fix pattern string used in the
example
In general, patterns are specified as 'type:arguments', where 'arguments' is
specific to the pattern used. The example provided in the documentation,
defined the pattern type to be 'linear', but used arguments meant to create
radial pattern. So we modify the example to use the correct type -- 'radial'.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/gears/color.lua.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/gears/color.lua.in b/lib/gears/color.lua.in
index 6b1c7e4..266b162 100644
--- a/lib/gears/color.lua.in
+++ b/lib/gears/color.lua.in
@@ -130,7 +130,7 @@ types = {
-- This function can create solid, linear, radial and png patterns. In general,
-- patterns are specified as type:arguments. arguments is specific to the
-- pattern used. For example, one can use
--- linear:50,50,10:55,55,30:0,#ff:0.5,#00ff00:1,#ff
+-- radial:50,50,10:55,55,30:0,#ff:0.5,#00ff00:1,#ff
-- Any argument that cannot be understood is passed to create_solid_pattern().
-- @see create_solid_pattern, create_png_pattern, create_linear_pattern,
-- create_radial_pattern
--
1.7.8.2
From e5c69379a05e715a599ae880a3ef3d2103302b36 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Wed, 11 Jan 2012 15:44:26 +0530
Subject: [PATCH 3/3] gears.color docs: replace literal '' and '' with
respective HTML entities
Luadoc confuses 'stop' with an HTML tag otherwise.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/gears/color.lua.in |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/gears/color.lua.in b/lib/gears/color.lua.in
index 266b162..9b0a992 100644
--- a/lib/gears/color.lua.in
+++ b/lib/gears/color.lua.in
@@ -81,9 +81,9 @@ end
--- Create a linear pattern object.
-- The pattern is created from a string. This string should have the following
--- form: x0,y0:x1,y1:stops
+-- form: x0,y0:x1,y1:#60;stops#62;
-- x0,y0 and x1,y1 are the start and stop point of the pattern.
--- For the explanation of stops, see add_stops().
+-- For the explanation of #60;stops#62;, see add_stops().
-- @param arg The argument describing the pattern
-- @return a cairo pattern object
-- @name create_linear_pattern
@@ -91,10 +91,10 @@ end
--- Create a radial pattern object.
-- The pattern is created from a string. This string should have the following
--- form: x0,y0,r0:x1,y1,r1:stops
+-- form: x0,y0,r0:x1,y1,r1:#60stops#62
-- x0,y0 and x1,y1 are the start and stop point of the pattern.
-- r0 and r1 are the radii of the start / stop circle.
--- For the explanation of stops, see add_stops().
+-- For the explanation of #60stops#62, see add_stops().
-- @param arg The argument describing the pattern
-- @return a cairo pattern object
-- @name create_radial_pattern
--
1.7.8.2
[RFC] documentation system (was: [PATCH] gears.colors)
On Wed, Jan 11, 2012 at 4:01 PM, Anurag Priyam anurag08pri...@gmail.com wrote: gears.color docs: replace literal '' and '' with respective HTML entities I remember, I had sent a similar patch earlier too. It was to fix markup for awful.menu's documentation. Such patches are indicative of a larger problem, in my opinion. Awesome's API documentation is full of broken or bad or missing markup and English and content. I feel my patches are merely addressing the symptoms. Using [Markdown][1] as a documentation format can alleviate a lot of the problems: 1. HTML in both: code and diff, looks super ugly. Unrendered documentation (in the source files) is virtually unreadable; see `lib/awful/tooltip.lua.in` for example. Hell, even the final output is hardly legible. 2. The set of HTML tags that luadoc supports right out of the box is limited. 3. Since HTML is relatively more painful to write, the developers don't have an incentive to write good documentation. I don't mind contributing _proper_ documentation. But fixing broken markup is hardly gratifying. Sometimes a better tool can make a lot of difference. Markdown, on the other hand, is way simpler, prettier, and readable. For complex use cases you can embed HTML within. I am not sure how exactly to proceed, but here is the general idea: 1. Implement a [Doclet][2] to convert Markdown in the documentation to HTML * uncertain of the implementation apart from what has already been done in `luadoc/src/luadoc/doclet/html.lua` * probably leverage [lua-discount][3] to make the job easy * not sure if such a module should go to luadoc, or remain a part of awesome's source tree * figure out how to integrate into awesome's build system 2. See if luadoc supports custom templates * choose, or write (this will be painful; I suck at design) one for Awesome, to be used at https://awesome.naquadah.org/doc/api/ 3. We can think of other goodies once this much has been done and merged Notes: I definitely can't work on this before 21st of Jan. Probably not till Jan end actually. But, if anyone finds this particularly interesting, and have time, please, by all means, go ahead with it. I will join hands as soon as I can find time. Of course, this doesn't do much to improve the English. And I am not sure if we can actually do something about it unless more people with native English proficiency step up to improve the docs. Other advantages: improved docs could mean more users, which in turn could mean more contributors, ... P.S: This email is written in Markdown :) [1]: http://daringfireball.net/projects/markdown/ [2]: http://keplerproject.github.com/luadoc/architecture.html [3]: http://asbradbury.org/projects/lua-discount/ -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: ANN: Menubar - decent application menu for Awesome
On Tue, Jan 10, 2012 at 4:21 PM, Alexander Yakushev yakushev.a...@gmail.com wrote: Though I'm a bit anxious myself to migrate to git-version. Is there a place to read all implications connected with it? I moved only a couple of days back. Migration is pretty easy. Since I couldn't find anything to read I created this page [1] an hour back to document some of the changes I had to make. Though, I haven't added anything yet. You can refer to my awesomerc[2], SHA: b18c69d073c6c50dce1e3f681b2b37d81a1b7b9b [3] if you want. I haven't got tooltips, and gradient in graph widgets working yet. Mind you, I shamelessly amend public commits when it comes to my configuration files. [1]: https://awesome.naquadah.org/wiki/Awesome_3.4_to_git_master [2]: https://github.com/yeban/awesomerc/ [3]: https://github.com/yeban/awesomerc/commit/b18c69d073c6c50dce1e3f681b2b37d81a1b7b9b -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
gradients in master
How would the following, 3.4.x code, translate to master:
```lua
cpugraph = awful.widget.graph()
-- these five lines are usable as it is
cpugraph:set_width(45)
cpugraph:set_height(14)
cpugraph:set_background_color(beautiful.fg_off_widget)
cpugraph:set_color(beautiful.fg_end_widget)
-- but what about gradients ??
cpugraph:set_gradient_angle(0)
cpugraph:set_gradient_colors({ beautiful.fg_end_widget,
beautiful.fg_center_widget, beautiful.fg_widget
})
```
I looked into gears.color, but I am unable to make much sense of it.
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
[PATCH] fix errors in awful.tooltip docs
Directly posting the commit message, since I don't have anything else
to say about the patch:
awful.tooltip docs: replace references to undefined variable 'K' with 'myclock'
Most probably, the original author chose to use 'K' first, switched to
'myclock' later, and forgot to update remaining occurrences of 'K'.
--
Anurag Priyam
From bebe1ad4e9ee0b8f72fcb161ef60ce21217c82cd Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Tue, 10 Jan 2012 15:52:11 +0530
Subject: [PATCH] awful.tooltip docs: replace references to undefined variable
'K' with 'myclock'
Most probably, the original author chose to use 'K' first, switched to
'myclock' later, and forgot to update remaining occurrences of 'K'.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/awful/tooltip.lua.in |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/awful/tooltip.lua.in b/lib/awful/tooltip.lua.in
index a34b509..92dad35 100644
--- a/lib/awful/tooltip.lua.in
+++ b/lib/awful/tooltip.lua.in
@@ -24,7 +24,7 @@ local ipairs = ipairs
-- code
-- myclock = awful.widget.textclock({}, %T, 1)br/
-- myclock_t = awful.tooltip({br/
--- objects = { K },br/
+-- objects = { myclock },br/
-- timer_function = function()br/
-- return os.date(Today is %A %B %d %Y\nThe time is %T)br/
-- end,br/
@@ -36,7 +36,7 @@ local ipairs = ipairs
-- myclock_t:add_to_object(obj1)br/
-- myclock_t:add_to_object(obj2)br/
-- /code
--- Now the same tooltip is attached to codeK/code, codeobj1/code,
+-- Now the same tooltip is attached to codemyclock/code, codeobj1/code,
--codeobj2/code.br/
-- /p
-- pHow to remove tooltip from many objects?br/
@@ -44,7 +44,7 @@ local ipairs = ipairs
-- myclock_t:remove_from_object(obj1)br/
-- myclock_t:remove_from_object(obj2)br/
-- /code
--- Now the same tooltip is only attached to codeK/code.br/
+-- Now the same tooltip is only attached to codemyclock/code.br/
-- /p
module(awful.tooltip)
--
1.7.8.2
[PATCH] gears.colors: expose docs for 2 functions
gears.color: expose documentation for create_(linear|radial)_pattern functions
The documentation for these functions were hidden (intentionally?) from luadoc
because of misspelt @class and @name tags. Fixed the spelling, so luadoc can do
its job.
[...]
--
Anurag Priyam
From 6856e227f6a888b35f6292eaa4a347d5a17d2587 Mon Sep 17 00:00:00 2001
From: Anurag Priyam anurag08pri...@gmail.com
Date: Wed, 11 Jan 2012 12:07:12 +0530
Subject: [PATCH] gears.color: expose documentation for
create_(linear|radial)_pattern functions
The documentation for these functions were hidden (intentionally?) from luadoc
because of misspelt @class and @name tags. Fixed the spelling, so luadoc can do
its job.
Signed-off-by: Anurag Priyam anurag08pri...@gmail.com
---
lib/gears/color.lua.in |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/gears/color.lua.in b/lib/gears/color.lua.in
index d04c05e..6b1c7e4 100644
--- a/lib/gears/color.lua.in
+++ b/lib/gears/color.lua.in
@@ -86,8 +86,8 @@ end
-- For the explanation of stops, see add_stops().
-- @param arg The argument describing the pattern
-- @return a cairo pattern object
--- @nname create_linear_pattern
--- @nclass function
+-- @name create_linear_pattern
+-- @class function
--- Create a radial pattern object.
-- The pattern is created from a string. This string should have the following
@@ -97,8 +97,8 @@ end
-- For the explanation of stops, see add_stops().
-- @param arg The argument describing the pattern
-- @return a cairo pattern object
--- @nname create_radial_pattern
--- @nclass function
+-- @name create_radial_pattern
+-- @class function
for k, v in pairs({ linear = capi.oocairo.pattern_create_linear,
radial = capi.oocairo.pattern_create_radial}) do
--
1.7.8.2
Re: Wallpaper widgets
Anurag Priyam anurag08pri...@gmail.com wrote:
On Fri, Dec 16, 2011 at 11:43 PM, Alexander Yakushev
yakushev.a...@gmail.com wrote:
I use transparent wiboxes instead of conky. Here's how it look (top
screenshot): http://www.linux.org.ru/gallery/6455144.png .
So, how exactly is it done?
[...]
Never mind; I got it. Though, it would be great if someone could
explain why/how this works:
```lua
TODO: don't hard-code these values
wibox_agenda[s] = wibox({ x = 1024, y = 200, width = 200, height =
180, screen = s })
wibox_agenda[s].visible = true
```
I was initially using `awful.wibox` which was getting in the way by
setting position, and width, and struts, and what not, by itself.
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
[PATCH] client property hints in tasklist
Started using awesome from git master few hours back. Couldn't help notice the sweet, client property hints (for ontop, floating and stuff) in the tasklist :). Attached are two minor improvements that I think will make it even better. -- Anurag Priyam From 9f564a4b7e81346cabcb01e91042948ace1251c5 Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Thu, 5 Jan 2012 19:03:42 +0530 Subject: [PATCH 1/2] tasklist: visually separate client-property-hints (for floating, ontop, etc.) Basically, we enclose the corresponding characters within square brackets. So '^' (for ontop) becomes '[^] '. Such visual distinction is particularly helpful, for example, when using 'floating' and 'ontop' together. Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- lib/awful/widget/tasklist.lua.in |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/awful/widget/tasklist.lua.in b/lib/awful/widget/tasklist.lua.in index 8d4c48c..61bb1bb 100644 --- a/lib/awful/widget/tasklist.lua.in +++ b/lib/awful/widget/tasklist.lua.in @@ -38,10 +38,10 @@ local function tasklist_label(c, args) local bg = nil local text = span font_desc='..font..' local name = -if c.ontop then name = name .. ⌃ end -if client.floating.get(c) then name = name .. ✈ end -if c.maximized_horizontal then name = name .. '⬌' end -if c.maximized_vertical then name = name .. ⬍ end +if c.ontop then name = name .. [⌃] end +if client.floating.get(c) then name = name .. [✈] end +if c.maximized_horizontal then name = name .. '[⬌] ' end +if c.maximized_vertical then name = name .. [⬍] end if c.minimized then name = name .. (util.escape(c.icon_name) or util.escape(c.name) or util.escape(untitled)) else -- 1.7.7.3 From 6156c60457d614a61a7d70e4c0e4dc49ded39c9b Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Thu, 5 Jan 2012 21:27:10 +0530 Subject: [PATCH 2/2] =?UTF-8?q?tasklist:=20introduce=20client-property-hint=20?= =?UTF-8?q?for=20'sticky':=20'[=E2=96=AA]'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit So a [▪] before the client name in the tasklist implies it is sticky. Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- lib/awful/widget/tasklist.lua.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/awful/widget/tasklist.lua.in b/lib/awful/widget/tasklist.lua.in index 61bb1bb..2a1b755 100644 --- a/lib/awful/widget/tasklist.lua.in +++ b/lib/awful/widget/tasklist.lua.in @@ -39,6 +39,7 @@ local function tasklist_label(c, args) local text = span font_desc='..font..' local name = if c.ontop then name = name .. [⌃] end +if c.sticky then name = name .. [▪] end if client.floating.get(c) then name = name .. [✈] end if c.maximized_horizontal then name = name .. '[⬌] ' end if c.maximized_vertical then name = name .. [⬍] end -- 1.7.7.3
Re: [PATCH] client property hints in tasklist
On Thu, Jan 5, 2012 at 10:46 PM, Uli Schlachter psyc...@znc.in wrote: Subject: [PATCH 1/2] tasklist: visually separate client-property-hints (for floating, ontop, etc.) Basically, we enclose the corresponding characters within square brackets. [...] Instead, this should be made configurable, somehow. Cool. I thought that would be too much for such a simple thing. But then, it was the first thing I set out to change after the move :P. And personal preferences are, well, personal preferences. [...] local str_float = args.tasklist_floating or theme.tasklist_floating or ✈ I would have preferred theme only. But considering how other options are dealt with, args + theme + default seems to be the way to go. Subject: [PATCH 2/2] =?UTF-8?q?tasklist:=20introduce=20client-property-hint=20?= =?UTF-8?q?for=20'sticky':=20'[=E2=96=AA]'?= Woah, wtf? Encodings are evil and ugly. Ooops. So a [▪] before the client name in the tasklist implies it is sticky. I'm not sure if I'd associate that icon with sticky immediately. Someone on IRC will ask there is a black square in my tasklist, why? ;-) [...] I thought of it like 'pinning' a client. Like sticky notes with thumb tacks in one corner. So I used a bullet first, but it was hardly noticeable. Hence the square. Do you think a bullet would be better? Could you change the first patch, turn [▪] into ▪ in the second patch and re-send? In a while. Thanks for the review :). -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] client property hints in tasklist
On Thu, Jan 5, 2012 at 11:14 PM, Anurag Priyam anurag08pri...@gmail.com wrote: On Thu, Jan 5, 2012 at 10:46 PM, Uli Schlachter psyc...@znc.in wrote: Could you change the first patch, turn [▪] into ▪ in the second patch and re-send? In a while. There you go. Though, I would still argue for '[foo]', instead of just 'foo'. I think it makes for a better default. I use floating + ontop very frequently, and it feels a little weird when those symbols clutter up. -- Anurag Priyam From eb2f1bfd1468fb6aaf84e144f3034c58deb0c07f Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Fri, 6 Jan 2012 00:01:27 +0530 Subject: [PATCH 1/2] tasklist: allow 'symbols' used to mark certain client properties to be themed Symbols (or, visual hints) used to indicate that a client is: 'ontop' or 'floating' or 'maximized_horizontal' or 'maximized_vertical', can now be defined in the theme, or passed to awful.widget.tasklist() as the last, 'style' argument (see docs). Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- lib/awful/widget/tasklist.lua.in | 20 +++- 1 files changed, 15 insertions(+), 5 deletions(-) diff --git a/lib/awful/widget/tasklist.lua.in b/lib/awful/widget/tasklist.lua.in index 8d4c48c..0cc58fa 100644 --- a/lib/awful/widget/tasklist.lua.in +++ b/lib/awful/widget/tasklist.lua.in @@ -38,10 +38,17 @@ local function tasklist_label(c, args) local bg = nil local text = span font_desc='..font..' local name = -if c.ontop then name = name .. ‚åÉ end -if client.floating.get(c) then name = name .. ‚úà end -if c.maximized_horizontal then name = name .. '‚¨å' end -if c.maximized_vertical then name = name .. ‚¨ç end + +-- symbol to use to indicate certain client properties +local ontop = args.ontop or theme.tasklist_ontop or '‚åÉ' +local floating = args.floating or theme.tasklist_floating or '‚úà' +local maximized_horizontal = args.maximized_horizontal or theme.tasklist_maximized_horizontal or '‚¨å' +local maximized_vertical = args.maximized_vertical or theme.tasklist_maximized_vertical or '‚¨ç' + +if c.ontop then name = name .. ontop end +if client.floating.get(c) then name = name .. floating end +if c.maximized_horizontal then name = name .. maximized_horizontal end +if c.maximized_vertical then name = name .. maximized_vertical end if c.minimized then name = name .. (util.escape(c.icon_name) or util.escape(c.name) or util.escape(untitled)) else @@ -96,7 +103,10 @@ end -- fg_urgent The foreground color for urgent clients. -- bg_minimize The background color for minimized clients. -- fg_minimize The foreground color for minimized clients. --- floating_icon The icon for flating clients. +-- floating Symbol to use for floating clients. +-- ontop Symbol to use for ontop clients. +-- maximized_horizontal Symbol to use for clients that have been horizontally maximized. +-- maximized_vertical Symbol to use for clients that have been vertically maximized. -- font The font. function new(screen, filter, buttons, style) local w = flex.horizontal() -- 1.7.7.3 From 9f17ca2ad6b3cd4e7e6b5faccda9504436383c08 Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Fri, 6 Jan 2012 00:54:33 +0530 Subject: [PATCH 2/2] tasklist: indicate sticky clients with a solid square as the default Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- lib/awful/widget/tasklist.lua.in |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/awful/widget/tasklist.lua.in b/lib/awful/widget/tasklist.lua.in index 0cc58fa..61fee41 100644 --- a/lib/awful/widget/tasklist.lua.in +++ b/lib/awful/widget/tasklist.lua.in @@ -40,11 +40,13 @@ local function tasklist_label(c, args) local name = -- symbol to use to indicate certain client properties +local sticky = args.sticky or theme.tasklist_sticky or ▪ local ontop = args.ontop or theme.tasklist_ontop or '⌃' local floating = args.floating or theme.tasklist_floating or '✈' local maximized_horizontal = args.maximized_horizontal or theme.tasklist_maximized_horizontal or '⬌' local maximized_vertical = args.maximized_vertical or theme.tasklist_maximized_vertical or '⬍' +if c.sticky then name = name .. sticky end if c.ontop then name = name .. ontop end if client.floating.get(c) then name = name .. floating end if c.maximized_horizontal then name = name .. maximized_horizontal end -- 1.7.7.3
Re: [PATCH] client property hints in tasklist
0002-tasklist-indicate-sticky-clients-with-a-solid-square.patch Please use the patch attached with this email instead of second patch from the previous one. I hadn't connected 'property::sticky' signal with the function 'u' earlier. So the tasklist didn't update immediately when making a client sticky, but instead on some other signal later. Thanks :). -- Anurag Priyam From 740e5a16befaeb7efc8ac9a68036555435b25648 Mon Sep 17 00:00:00 2001 From: Anurag Priyam anurag08pri...@gmail.com Date: Fri, 6 Jan 2012 00:54:33 +0530 Subject: [PATCH] tasklist: indicate sticky clients with a solid square as the default Signed-off-by: Anurag Priyam anurag08pri...@gmail.com --- lib/awful/widget/tasklist.lua.in |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lib/awful/widget/tasklist.lua.in b/lib/awful/widget/tasklist.lua.in index 0cc58fa..c52e4cd 100644 --- a/lib/awful/widget/tasklist.lua.in +++ b/lib/awful/widget/tasklist.lua.in @@ -40,11 +40,13 @@ local function tasklist_label(c, args) local name = -- symbol to use to indicate certain client properties +local sticky = args.sticky or theme.tasklist_sticky or ▪ local ontop = args.ontop or theme.tasklist_ontop or '⌃' local floating = args.floating or theme.tasklist_floating or '✈' local maximized_horizontal = args.maximized_horizontal or theme.tasklist_maximized_horizontal or '⬌' local maximized_vertical = args.maximized_vertical or theme.tasklist_maximized_vertical or '⬍' +if c.sticky then name = name .. sticky end if c.ontop then name = name .. ontop end if client.floating.get(c) then name = name .. floating end if c.maximized_horizontal then name = name .. maximized_horizontal end @@ -116,6 +118,7 @@ function new(screen, filter, buttons, style) capi.screen[screen]:connect_signal(tag::detach, u) tag.attached_connect_signal(screen, property::selected, u) capi.client.connect_signal(property::urgent, u) +capi.client.connect_signal(property::sticky, u) capi.client.connect_signal(property::ontop, u) capi.client.connect_signal(property::floating, u) capi.client.connect_signal(property::maximized_horizontal, u) -- 1.7.7.3
Re: Wallpaper widgets
On Fri, Dec 16, 2011 at 11:43 PM, Alexander Yakushev yakushev.a...@gmail.com wrote: I use transparent wiboxes instead of conky. Here's how it look (top screenshot): http://www.linux.org.ru/gallery/6455144.png . So, how exactly is it done? I can't get my wiboxes to be 'unobstrusive' -- unlike the default, top wibox, I want clients to draw over this new transparent wibox of mine, so it looks like a part of the wallpaper. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Feeding output to naughty
On Tue, Jan 3, 2012 at 7:21 AM, Phynix phynix...@gmail.com wrote:
Is there an easy way or perhaps a website that can be suggested where I can
pipe output from a command to awesome and bind it to a keypress.
https://awesome.naquadah.org/wiki/Naughty#Feeding_Naughty
e.g:
$ echo naughty.notify({text = '$(mpc current)'}) | awesome-client
--
Anurag Priyam
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Wallpaper widgets
On Fri, Dec 16, 2011 at 11:43 PM, Alexander Yakushev yakushev.a...@gmail.com wrote: I use transparent wiboxes instead of conky. Here's how it look (top screenshot): http://www.linux.org.ru/gallery/6455144.png . Is that todo list sort of thing on the right from org-mode? -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: no-input window possible???
On Wed, Dec 14, 2011 at 10:56 AM, Juan Antonio Zuloaga Mellino skir...@gmail.com wrote: With no input, I mean that if I click the window, I actually click the one that is behind it... [...] But I wanted to know if there is some way to do this with the awesome api, to be able to turn the no input on/off dynamically. Just wanted to +1 this. It would be a nice feature to have (unless we have it already). I could use such a window to display lyrics of the currently playing song unobtrusively. Earlier, I used to display lyrics in a tooltip for my mpd widget. -- Anurag Priyam -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
