sorry, for the late response ..
On 26 March 2012 17:28, Uli Schlachter <[email protected]> wrote:
> On 26.03.2012 16:55, Alexander Yakushev wrote:
>> The problem was described here:
>> http://thread.gmane.org/gmane.comp.window-managers.awesome.devel/6921
>>
>> The patch looks not very elegant but I don't know how to make it better
>> provided we want to save the "visible == true" functionality. I guess it
>> was done so that clicking some specific menu entry leaves menu unclosed
>> (does Awesome use it anywhere?). This means that menu must stay the
>> whole time while command executes and only after decide to close itself
>> (and subsequently stop keygrabber) or not.
>>
>> Patch is attatched.
>
> This patch stops the keygrabber, but if the menu should continue running, the
> keygrabber is never restarted. The problem is that restarting the keygrabber
> could fail and I have no idea how that should be handled.
code to reproduce it:
myawesometestmenu = {
{ "Run: …", function (m)
awful.widget.prompt.run({
widget = m.label,
prompt = "Run: " })
return true
end },
{ "random", function (m)
m.label:set_text(math.random())
return true
end },
} -- add it as submenu to myawesomemenu
> Also I didn't even know that this "visible" feature exists. According to git
> blame, this was added in commit ea40a922 when awful.menu was rewritten. I
> guess
> I wouldn't mind dropping that and waiting for complaints. :-)
>
> CC'ing the author of said commit to see if he can shed some light on this.
thanks to Alexander for doing it.
>
> Dodo, why does awful.menu allow the functions for executing menu entries to
> return false in which case the menu isn't closed? What bad would happen if
> that
> is removed?
nothing bad would happen i guess ...
but counter question first, why is the keygrabber global? why cant i
attach key event handlers to a wibox?
i mean wouldnt it make more sense to let the menu listen for key
events on its wibox?
when a sub menu opens it gets the focus, when a prompt opens it gets
the focus and so on …
and when they close the previous focus gets restored.
its nice to have a global keygrabber, for locking the window manager
or something, but not for widgets. X solves this already pretty well,
so imho we should just use that.
atm i see three different ways to solve this problem:
1. add key events to drawins (listen for all keys should be possible
too) and use this for every widget.
2. add awful.keygrabber which would handle a stack and `route` the key
events to the right widget.
3. or we remove this little feature from awful.menu and forget about all this.
-- thanks for asking, dodo
ps there might be more ways to solve this problem :P
--
To unsubscribe, send mail to [email protected].
