[wmii] Re: wmiibar2 ready

Hi Sander,

dunno if you already tried hg tip (the wm is floating only atm),
but I changed/simplified wmiikeys yesterday pretty drastically,
because we want all components to be concise in their interface
(there has been a discussion in IRC yesterday about it).

The current mechanism for wmiikeys (and which comes into my mind
for wmiimenu as well) is as follows:

writes to /grab (/show) provide a list of shortcuts (menu entries)
without any command, just the shortcut (or the menu item).
In wmiikeys this shortcut will be grabbed, and if it is pressed,
the shortcut is written to all /event consumers. Those consumers
decide what todo with the event (this is somewhat like plumbing
in Plan 9 world).

To make those things to work, we decided to write a control
script for each component. This means that the wmii script is
aimed to setup the wmiifs, the wm script will setup the wm, the
keys script as mentioned will setup the shortcut tool, the bar
script will control the bar (inclusive writing status stuff).
This also results that wmiirc will be deprecated, but all those
control scripts will behave like wmiiirc for their component,
with some exceptions:

Those scripts start the component, restart it if executed again,
and contain the /event consuming loop. This mimizes hardcoded
defaults to a minimum. If no consumer of events exists, nothing
happens. ;)

Assumed we have such /event interface wmiimenu as well, a
shortcut press (ie Control-Alt-p) would start wmiimenu,
fill its entries through a fresh creation of the requested list
(this is very fast because you can write directly to /show
without needing the wmiifs redirection at all, because this
script decides for the socket file). Thus throughouts of 5MB/s
shouldn't be hard, if so much info is presented in the menu.

After the menu is setup, it'll report once the content is
entered/choosed to /event, whereas the consumer loop in the menu
script can decide what todo, execute, send the command as input
to somewhere else or whatever one can think of.
This would also allow to safe the content somewhere into a file
and on next menu run, just write the history of such file to
/history for faster access of such commands.

Hope this was somewhat enlightening.
In my opinion a file representation of the menu entries or the
history is not necessary, just allow writes to /show and /history.
(Though, a file representation of items and history is a cheap
operation in xread ;)

On Thu, Feb 09, 2006 at 11:23:11AM +0100, Sander van Dijk wrote:
> I'm working on wmiimenu at the moment, I'm combining the wmiimenu
> specific functions with the ixp2 functions of wmiikeys and adapting
> them to each other. I'm almost at a point where it compiles now, but
> when changing the add_history function I started wondering about some
> things: if we're going to use /reset to change the menu's contents,
> what are we going to do with /history/*?

With above assumption, this can be decided by the controller
script.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361