[openbox] Adding finalactions to showmenu

[Dana Jansens]

On Mon, Nov 14, 2011 at 7:13 AM, richo <richo at psych0tik.net> wrote:
> On 13/11/11 08:29 -0800, Dana Jansens wrote:
>>
>> On Fri, Nov 11, 2011 at 10:41 PM, richo <richo at psych0tik.net> wrote:
>>>
>>> Hi List,
>>>
>>> I'm in the process of trying to add a finalactions stanza to showmenu so
>>> that
>>> you can configure some actions to fire when the menu is complete.
>>
>> I;m having trouble understanding why you would want/need this at all.
>> You can just add actions after the showmenu action.
>>
>
> I added a new action to warp the cursor to the currently focused window (I
> realise it should probably be centered on the visible space, I will do that
> next), but unless I did something stupid, merely adding <action
> name="Warp"/>
> to the showmenu item didn't cause that action to happen after making a
> selection from the menu.

I think I get it.  You would need to attach those final actions to the
menu(s) that open somehow.  But what if you do final actions on menu
with programs to run in it?  You won't be able to warp to new windows
this way.

I have a git branch for making hooks:
http://git.openbox.org/?p=dana/openbox.git;a=shortlog;h=refs/heads/wip/hooks

One possible way to do this would be to use a hook for "focused" and
stick the warp action in there, as it gets all the cases.  But the
hooks code is not on the main dev tree because it was really easy to
make hooks that looped infinitely (e.g. when maximzed state changes,
run ToggleMaximize).  I think the right way to address this is to just
limit the amount of recursion an action can do.  This is something you
could tackle if you're interested.

Otherwise I think it would need to be yet another "focus" option, to
catch things like new windows.

> This also begs the behaviour question about how it would be possible to not
> move the mouse unless you've specifically chosen a window, which is easier
> from client_list than others I guess.
>
>>> I am using cyclewindows as a reference implementation, but struggling to
>>> find
>>> documentation.
>>>
>>> If I declare setup_func as
>>>
>>> static gpointer setup_func(xmlnodeptr node,
>>>        obactionsiprefunc *pre,
>>>        obactionsiinputfunc *input,
>>>        obactionsicancelfunc *cancel,
>>>        obactionsipostfunc *post)
>>
>> This is for parsing the action's options. All the ObActionsI*
>> functions are for interactive actions, which showmenu is not.
>>
>
> Now that you've said that, the source makes a lot more sense. Thankyou.
>
>>> I believe that I then point pre, input, cancel and post to functions to
>>> be
>>> executed in those conditions. My questions are:
>>
>> You would only need to change the parsing inside the setup function to
>> read the final actions there and save them in the Options struct.
>>
>
> I had done this (Again, using cyclewindows as a reference implementation)
> and
> stored the actions inside the Options struct, but I presumed that I'd need a
> similar post action to actually call the actions, or is there magic to
> arrange that?
>
>>> Do I need to write a noop function to set the ones I'm not using to?
>>>
>>> And how safe is it to stuff the ObClient that I'm dealing with into the
>>> Options struct for later retrieval in my post function?
>>
>> The ObClient comes from Openbox when the action is executed, and is
>> passed to the action's execute function.  Whereas, the Options struct
>> is created when the config file is read.
>>
>
> I see that now, thankyou again.
> --
> richo || Today's excuse:
>
> The co-locator cannot verify the frame-relay gateway to the ISDN server.
> http://blog.psych0tik.net
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>
>