Bug 10755

Created attachment 4266 [details]
Patch for X-start-menu-icons.in

Updated X-start-menu-icons.in, adding some fixes and enhancements:

* Read per-package icon files from /etc/X11/X-star-menu-icons.d/*
* Add the abilility to specfiy icons which are in separate files (not in
run.exe or the target executable)
* Remove additions of /usr/X11R6/bin to path
* Use a login shell to start executables
* Delete and recreate links on each run, so stale links are removed

Created attachment 4267 [details]
Generated X-start-menu-icons.sh for testing purposes

Attached X-start-menu-icons.sh for testing purposes.

Note there's some autoconf bogosity so just ./configure doesn't substitute
${prefix} in the output, you have to explicity specify the prefixes substituted
e.g. ./configure --exec-prefix=/usr --sysconfdir=/etc

Created attachment 4268 [details]
Setup.exe patch

X-start-menu-icons.sh should be run after every package install/uninstall which
is pointed to by a shortcut to add/remove shortcuts as needed.

Example patch for setup implementing a mechanism for a package postinstall
script to run after every install/uninstall (by avoiding renaming it to .done
if it starts __)

This mechanism wouldn't be neccessary if we move *all* the links in
/etc/X11/X-start-menu-icons-list into files owned by the package which owns the
executable they point to, and arrange for them to have postinstall/preremove
triggers which run X-start-menu-icons.sh

Created attachment 4269 [details]
Sample start menu link description file for emacs

Additional issues noticed:
* X-start-menu-icons.sh can only make links named after the executable they
point to. You can't supply arguments to the executable.  You can't have multiple
links to the same executable with different names and arguments.
* 'text app' links (which are run in an xterm) are assumed to take the -display
argument.  This fails for e.g. fc-list
* Hardcodes 127.0.0.1:0.0, which is perhaps bad
* Links fail silently if X server isn't running.  Need a wrapper which
checks/starts it with --silent-dup-error?

See http://sourceware.org/ml/cygwin-apps/2009-09/msg00020.html for a suggestion
to dynamically generate the Xwin traymenu from .desktop files, which seems a
better way of doing this

Created attachment 4576 [details]
Add INCLUDE directive for Xwinrc

As an small step in this direction, here is a patch which adds support for an
'include' directive to XWinrc processing, which can read from a file or the
output of a command.  As an example, this can be used to read the output of the
xwinmenu.sh script in the linked email, to dynamically populate the menu with
commands with .desktop files.

xwinmenu.sh was never meant to be the implementation of an FD.o menu.  It's way 
too slow to use on XWin startup, for one.

The solution would be to add a new token to XWinrc, which triggers code that 
readdir()s $XDG_DATA_DIRS/applications:$XDG_DATA_HOME/applications, open()s each 
.desktop file, fscanf()s it according to the FD.o Desktop Entry Spec, and 
creates a menu from that data.  But that will have to be another day.

OTOH I like the INCLUDE token for *files*.  I'll try to rebase this patch for 
files only in the next few days.

(In reply to Jon TURNEY from comment #6)
> See http://sourceware.org/ml/cygwin-apps/2009-09/msg00020.html for a
> suggestion
> to dynamically generate the Xwin traymenu from .desktop files, which seems a
> better way of doing this

We now have that with xwin-xdg-menu, which has obsoleted X-start-menu-icons.