Ignas Anikevicius | 2 Mar 14:45 2012
Picon

Re: [PATCH] Account for border-width when maximizing

On 02/03/12 09:22, Uli Schlachter wrote:
> On 02.03.2012 00:15, Ignas Anikevicius wrote:
> Sorry, but this breaks the magic that the screen_change function is doing.
> (Which I just noticed is already broken because it only handles "maximized" and
> "fullscreen", but doesn't handle the new "maximized_horizontal" and
> "maximized_vertical". Whoops.)

I can rewrite the maximization, so that "maximized" is used instead of
"maximized_horizontal" and "maximized_vertical". I have attempted to
write a fix. If it is not suitable/doesn't work, then let me know and
I'll try to fix it.

Cheers,
Ignas
Uli Schlachter | 2 Mar 17:47 2012
Picon

Re: keygrabber api

On 21.02.2012 16:47, Anurag Priyam wrote:
> On Mon, Feb 20, 2012 at 7:39 PM, Uli Schlachter <psychon <at> 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.

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...

Uli
--

-- 
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
 - Vincent Ebert

Anurag Priyam | 2 Mar 18:47 2012
Picon

Re: keygrabber api

On Fri, Mar 2, 2012 at 11:47 AM, Uli Schlachter <psychon <at> 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
(Continue reading)

Uli Schlachter | 2 Mar 19:20 2012
Picon

Re: keygrabber api

On 02.03.2012 18:47, Anurag Priyam wrote:
> On Fri, Mar 2, 2012 at 11:47 AM, Uli Schlachter <psychon <at> 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.

Yeah, I could see why that happens (I haven't actually tried it).
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.

> 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.

> 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:
(Continue reading)


Gmane