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 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
