On Fri, 27 Aug 2010 18:24:41 +0200, Kim Woelders <[email protected]> wrote:
> On Wed, 25 Aug 2010 03:16:46 +0200, James Bowlin <[email protected]> > wrote: > >> I think users could do some very interesting things with dynamics >> menus. What I mean by a "dynamic menu" is a script that is in >> the ~/.e16/menus directory. It can be linked to just like all >> the other menus but when it is selected, the program is run and >> the std output of the program forms the menu. This is a direct >> analogy to CGI scripts on the web. The current menus are like >> static pages and the dynamic menus would be like CGI scripts. >> >> This might be very easy to implement. It opens the door to users >> expanding e16 with scripts. For example, someone on the e16 >> discussion forum asked for a modified version of the Window List >> (that you get to by doing a middle click on the drag bar). >> Currently, adding this would require writing a lot of C code. But >> it would be trivial to write a menu script that implemented this >> feature. Users could then have whatever kind of window lists >> they wanted, sorted and grouped however they want. >> >> There are three refinements to this idea. Two of them are >> essential IMO and the other is a nicety. >> >> The first essential refinement is to have e16 pass the current >> window list to the scripts. Probably the output of "eesh wl >> prop" would be best. The reason I think this is essential is >> because I think e16 will lock up if one of the menu scripts tries >> to call eesh. If lockup is not an issues then there is no need >> for this feature. Probably the best way to pass this information >> to the scripts is via an environment variable in analogy to how >> information is passed to CGI scripts. If that is difficult to >> implement, I'm sure there are other ways. I *think* getting the >> windows list is the only eesh function the menu scripts need. >> The programs the menus call may need to call eesh to do other >> things but this works already. It is likely that other >> environment variables may need to be added. >> >> The second essential refinement would be the ability to pass >> parameters to the scripts as in: >> >> "List Windows by Desktop" NULL menu "window-list.pl by_desktop" >> >> In this example window-list.pl is sent the parameter "by_desktop". >> The simplest thing might be to pass the arguments as command line >> parameters, but if this is difficult, environment variables could be >> used. This mechanism would allow one menu script to pass >> information on to sub-menu scripts. For example, a sub-menu >> might let the user, do various things to a window, like move it, >> or close it, or bring it to the top or bottom of the stack, etc. >> >> The nicety would be to let menu items have a right click action >> as well as a left click action. This might be of some use in >> static menus as well. >> >> >> I realize this is kind of a crazy idea. I'm not holding my >> breath waiting for it to be implemented. I can understand >> why people dealing with the code base might prefer to keep >> this potential can of worms, unopened and locked away in a >> closet. >> > I'll play around with this when I get around to it. Have been somewhat > busy lately. > Come to think of it, this is already possible. You can make a script generating a menu file and then load that. Example - Put stuff below in a file (mark it executable) and bind it to some key or put it in a menu (exec type). ------------------------------ #!/usr/bin/perl $menufile = "/tmp/$ENV{'USER'}-tmp.menu"; open FM, "> $menufile"; # Title print FM "\"My menu\"\n"; # Trivial entries print FM "Eterm mon.png exec Eterm\n"; print FM "XTerm mon.png exec xterm\n"; print FM "urxvt mon.png exec urxvt\n"; print FM "\"Screen size 1366x768\" NULL exec \"xrandr -s 1366x768\"\n"; print FM "\"Screen size 1024x768\" NULL exec \"xrandr -s 1024x768\"\n"; print FM "\"Screen size 800x600\" NULL exec \"xrandr -s 800x600\"\n"; # Get window list @wl = `eesh wl a`; # Shade pagers foreach(@wl) { chomp; ($id, $geom, $dummy, $desk, $area, $name) = split ":"; next unless ($name =~ "Pager"); print FM "\"Shade $name\" NULL \"wop $name shade\"\n"; } # Show dialog with WM_CLASS property foreach(@wl) { chomp; ($id, $rest) = split; $info = `xprop -id $id WM_CLASS`; chomp $info; # print FM "\"$_\" NULL exec \"eesh dialog_ok \'$info\'\"\n"; print FM "\"$_\" NULL \"dialog_ok $info\"\n"; } close FM; system("eesh menus show $menufile"); -------------------------------------------- The only thing you can't do this way is to make the menu appear as a regular submenu. /Kim ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
