On Wed, 19 Oct 2005 09:34:14 -0700 Blake Barnett <[EMAIL PROTECTED]> wrote:
> Ok, let me enlighten myself. I read the IRC log that brought about the > idea for emu. I see now how they are completely different since Evoak > would never allow manipulation of E's internals the way a module can. > (Like the dynamic menu system Surtsey proposed) So anyway.... nothing > to see here, I hope they both get done. :) Just to help clear up any remaining confusion, and before I commit any code, this is how the brain dead, evil first hack at it, version will work. Keep in mind that this first version is a "throw your first one away" quick'n'dirty hack. emu, when first started, through some as yet to be determined magic, finds itself with a command to run. For the sake of this example, lets call it "emu_client". Since emu is designed to be language agnostic, the command could just as easily be "/home/onefang/emu_client.sh", "emu_client.pl", "java net.matrix_rad.emu.EmuClient", "emu_client.py", or anything really. As I stated previously, multiple emu modules with different client programs are a good idea. The above mentioned "yet to be determined magic" must cater for that. emu runs emu_client, and sets up stdin/stdout pipes to it as the IPC method. emu_clients first job is to output a menu command, something like this - menu Item0|action0 Item1 Item1 Sub0|action1 Item1 Sub1|action2 Item2 Item2 Sub0|action3 Item2 Sub1 Item2 Sub1 Sub0|action4 Item2 Sub1 Sub1|action5 unem emu catches this output into an array, then when the array is a valid menu command, creates the matching "left click on the module" menu - Item0 Item1 Item1 Sub0 Item1 Sub1 Item2 Item2 Sub0 Item2 Sub1 Item2 Sub1 Sub0 Item2 Sub1 Sub1 When the user left clicks on the emu module, the menu pops up, and the user can select something. If the user selects a menu item with an attached action, say "Item1 Sub0" for example, then emu sends "action1" for example to emu_client's stdin. emu_client reads "action1" from it's stdin, and does whatever "action1" means. It is entirely up to emu_client to supply emu with action text that is meaningful to the client, and react appropriately when it gets these action texts returned to it. Emu just treats them as opaque blobs of text. In the future, a binary protocol may be used if needed. At any time, emu_client can send a new menu command through it's stdout, and emu will rebuild the menu once a valid menu command has been received. Later versions of emu can add some sort of icon command to do the same sort of thing - add icon to module, gimme this text when it's clicked on. This will need some sort of graphics information exchange, either through the stdin/stdout pipe, or out of band. Some sort of theme hooks may be in order to. Then I can push the basic idea as far as is possible, and slightly beyond. This is not ever likely to be a wrapper around everything a module can do, I seriously doubt if this sort of architecture can do what the dropshadow module can do. But it will be quite happy doing the sort of things that the start, weather, and maybe ibar modules can do. If the graphics exchange protocol is efficient enough, it could do what the monitor module can do. No, I am NOT proposing a rewrite of the above modules to use emu, that would be silly. emu lets people make certain types of modules using some random language. If they want the full power of modules, they can use C like the rest of us.
pgp7wfRRpSLAQ.pgp
Description: PGP signature
