Re: Start menu shortcuts
On 2013-07-29 08:22, Jon TURNEY wrote: Since this has reared it's ugly head again [1], rather than perpetuate X-start-menu-icons into x86_64, I'll suggest the following plan: 1) Obsolete X-start-menu-icons on x86 and replace it with a dummy empty package +1 2) Recognize that most of the links created by X-start-menu-icons are worthless and drop them. I'd suggest that links for the following applications are worthwhile, and should be installed by the application package itself: There already exists a menu system for X11 programs, namely the XDG Desktop Menu Spec, and these programs already provide the necessary entries (/usr/share/applications/*.desktop). Personally, when in multiwindow mode, I run fbpanel (from Ports) which gives me both an XDG menu and a system tray (notification area). Links should be made using scripts something like the following: postinstall.sh: /usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X" /usr/bin/mkshortcut $CYGWINFORALL -P -i /path/to/foo.exe-or-.ico -n "Cygwin-X/AppName" -a "/usr/bin/bash.exe -l -c '/usr/bin/foo.exe -display :0.0'" /usr/bin/run.exe There are a few problems with this: 1) this assumes DISPLAY=:0.0, which may not always be the case. 2) many programs require --display= instead of -display, and others don't accept either. 3) most programs nowadays require a D-Bus session. Starting programs like this, however, will cause each to autostart their own session, unaware of (and unable to interact with) others. Previously, we discussed (off-list?) having the XWin tray include an XDG menu. Not only would we have to write this from scratch (as implementations I have seen are (L)GPL, or depend on a library so licensed), that would not resolve #3, as a dbus-session is launched only after starting the X server. What we may need to do instead is create a "multiwindow session", where startxwin launches not only the X server, but also the following: * a D-Bus session bus * a (specially configured) fbpanel instance * non-desktop-specific, or XWin-specific, XDG autostart entries. The fbpanel would be in one corner, just big enough for an X icon (the desktop menu button), and expand/contract as needed for system tray icons. 3) Look forward to a glorious future where cygport can generate those link installation scripts automatically from *.desktop files :D That may be possible: parsing .desktop files isn't that hard, but dealing with icons may be, but the aformentioned issues would need to be resolved first. Yaakov
Re: Start menu shortcuts
On 02/09/2009 20:59, Charles Wilson wrote: > Jon TURNEY wrote: >> I'm not sure what to do about X-start-menu-icons. >> >> I think Yaakov has some ideas about how to approach this, but I don't >> know what they are. >> >> Anyhow, this is something I am willing to spend a bit of time on, if >> there was some vague consensus as to the direction we should be heading in. > > IMO, each (X) package should, in its own postinstall script, create the > start menu shortcut it needs, using mkshortcut from cygutils. That > postinstall script should also invoke whatever tool is necessary and > supported to add its opendesktop menu items to the cygwin area, so that > cygwin/gnome and/or cygwin/kde window managers are happy -- at the > package maintainer's discretion. I believe Yaakov's ideas revolve > around automating this with certain primitives to be invoked within > .cygport packaging scripts. > > How to manange the transition, from the monolithic X-start-menu-icons > package and script, to this distributed approach -- no idea. Since this has reared it's ugly head again [1], rather than perpetuate X-start-menu-icons into x86_64, I'll suggest the following plan: 1) Obsolete X-start-menu-icons on x86 and replace it with a dummy empty package 2) Recognize that most of the links created by X-start-menu-icons are worthless and drop them. I'd suggest that links for the following applications are worthwhile, and should be installed by the application package itself: emacs (Ken Brown) xemacs (Dr. Volker Zell) gvim(Yaakov S) rxvt(Charles Wilson) (perhaps better if only urxvt did this as we don't want to encourage people to use rxvt) xterm (Yaakov S) idle(Jason Tishler) Links should be made using scripts something like the following: postinstall.sh: /usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X" /usr/bin/mkshortcut $CYGWINFORALL -P -i /path/to/foo.exe-or-.ico -n "Cygwin-X/AppName" -a "/usr/bin/bash.exe -l -c '/usr/bin/foo.exe -display :0.0'" /usr/bin/run.exe preremove.sh: rm -f "$(cygpath $CYGWINFORALL -P)/Cygwin-X/AppName.lnk" rmdir --ignore-fail-on-non-empty "$(cygpath $CYGWINFORALL -P)/Cygwin-X" 3) Look forward to a glorious future where cygport can generate those link installation scripts automatically from *.desktop files :D [1] http://cygwin.com/ml/cygwin-xfree/2013-07/msg00019.html
Re: Start menu shortcuts
On 02/09/2009 20:59, Charles Wilson wrote: Jon TURNEY wrote: I'm not sure what to do about X-start-menu-icons. I think Yaakov has some ideas about how to approach this, but I don't know what they are. Anyhow, this is something I am willing to spend a bit of time on, if there was some vague consensus as to the direction we should be heading in. IMO, each (X) package should, in its own postinstall script, create the start menu shortcut it needs, using mkshortcut from cygutils. That postinstall script should also invoke whatever tool is necessary and supported to add its opendesktop menu items to the cygwin area, so that cygwin/gnome and/or cygwin/kde window managers are happy -- at the package maintainer's discretion. I believe Yaakov's ideas revolve around automating this with certain primitives to be invoked within .cygport packaging scripts. There are some details in how mkshortcut is called which can be usefully abstracted, I think. Anyhow, I've done at bit of work to fix some of the immediate problems at http://sourceware.org/bugzilla/show_bug.cgi?id=10755 On 06/09/2009 08:42, Yaakov (Cygwin/X) wrote: > That was my original train of thought. But as there already exists a > cross-desktop menu system in the X11 world, I would rather find a way to > use that instead, rather than maintaining a second menu system just for > Cygwin. [...] > OTOH, someone would have to write this parser -- we probably can't use > any of the existing ones, since most of them have dependencies beyond > those of XWin, and are under licenses which are more restrictive than > MIT/X11. And as a Windows app, XWin knows only about .ICO icons, so > supporting the PNG/SVG icons typically used in FD.o menus would be more > work. Perhaps this doesn't really need to be built into XWin? There's no reason why some kind of (xdg menu-spec/desktop-entry spec) launcher tool couldn't be started from the Xwin traymenu (which might be turned off) or a start menu link (which, for better or worse, might well be where people look for programs to run :-) Of course, you are quite right and plenty of these already exist. It would just need to work in a slightly different way to the traditional pop-up menu launcher. > The attached script provides an example of what such a menu would look > like in XWin if done manually. I just put this together, so it's a bit > rough, but it should give you an idea of the result (but obviously not > the implementation). Clever. If we had some form of 'include' directive in Xwinrc (I though there was one already, but apparently not), that could be used to suck in the output of a script like that...
Re: Start menu shortcuts
On 02/09/2009 14:59, Charles Wilson wrote:
IMO, each (X) package should, in its own postinstall script, create the
start menu shortcut it needs, using mkshortcut from cygutils.
Well, perhaps GUI X packages. A lot of the X.Org apps are diagnostical
in nature and hence are designed to be run from the command line. There
are a few which provide real functionality (nothing that isn't available
elsewhere with a modern GUI), and even those don't show up in the
standard X11 desktop menus.
That postinstall script should also invoke whatever tool is necessary and
supported to add its opendesktop menu items to the cygwin area, so that
cygwin/gnome and/or cygwin/kde window managers are happy -- at the
package maintainer's discretion.
If you are referring to /usr/share/applications/*.desktop used by
GNOME/KDE/Xfce/LXDE, those files are shipped by each package and are
part of the tarball, not created by postinstall. For those GUI packages
which don't ship a .desktop menu, one can be created by calling
make_desktop_entry() in src_install().
I believe Yaakov's ideas revolve around automating this with certain
primitives to be invoked within .cygport packaging scripts.
That was my original train of thought. But as there already exists a
cross-desktop menu system in the X11 world, I would rather find a way to
use that instead, rather than maintaining a second menu system just for
Cygwin.
My grand idea would be for XWin itself to implement the desktop menu,
parsing /usr/share/applications/ on startup, and generating a menu
structure that could be used in .XWinrc as so:
menu root {
"Reload .XWinrc" RELOAD
"Applications" LAUNCHER
SEPARATOR
}
ROOTMENU root
The attached script provides an example of what such a menu would look
like in XWin if done manually. I just put this together, so it's a bit
rough, but it should give you an idea of the result (but obviously not
the implementation).
OTOH, someone would have to write this parser -- we probably can't use
any of the existing ones, since most of them have dependencies beyond
those of XWin, and are under licenses which are more restrictive than
MIT/X11. And as a Windows app, XWin knows only about .ICO icons, so
supporting the PNG/SVG icons typically used in FD.o menus would be more
work.
If that is not plausible, then I suppose the fallback would be to have
cygport handle this by parsing the .desktop file, generating a
postinstall mkshortcut command, and creating an .ICO from the
corresponding PNG/SVG with ImageMagick/GraphicsMagick/Netpbm/etc. The
major drawback of this approach is in the case of split-packages, as
this would require some special handling of the postinstall, as well as
changes to each subpackage's .list file or _CONTENTS variable.
How to manange the transition, from the monolithic X-start-menu-icons
package and script, to this distributed approach -- no idea.
Either way, the transition means obsoleting X-start-menu-icons by
causing it to be uninstalled through "upgrading" it to an empty tarball.
Yaakov
Cygwin/X
#! /bin/sh
# See http://standards.freedesktop.org/menu-spec/latest/
# Main Categories:
cats="AudioVideo Development Education Game Graphics Network Office Settings
System Utility"
# The following line must be added manually to the designated ROOTMENU
# "Applications" MENU fdoapps
echo "MENU fdoapps {"
for cat in ${cats}
do
echo -e '\t'${cat} MENU ${cat}
done
echo "}"
# FIXME: fallback for (faulty) menus which specify none of the Main Categories
for cat in ${cats}
do
echo "MENU ${cat} {"
for app in $(find /usr/share/applications -name '*.desktop' | xargs
grep -l "Categories=.*${cat};")
do
# not intended for
grep -q '^NoDisplay=true' $app && continue
grep -q '^OnlyShowIn=' $app && continue
eval $(grep '^Exec=' $app | sed -e 's|=\(.*\)|="\1"|g')
eval $(grep '^Name=' $app | sed -e 's|=\(.*\)|="\1"|g')
echo -e '\t'\"${Name}\" EXEC \"${Exec%% *}\"
done | sort -f
echo "}"
done
Re: Start menu shortcuts
Jon TURNEY wrote: > I'm not sure what to do about X-start-menu-icons. > > I think Yaakov has some ideas about how to approach this, but I don't > know what they are. > > Anyhow, this is something I am willing to spend a bit of time on, if > there was some vague consensus as to the direction we should be heading in. IMO, each (X) package should, in its own postinstall script, create the start menu shortcut it needs, using mkshortcut from cygutils. That postinstall script should also invoke whatever tool is necessary and supported to add its opendesktop menu items to the cygwin area, so that cygwin/gnome and/or cygwin/kde window managers are happy -- at the package maintainer's discretion. I believe Yaakov's ideas revolve around automating this with certain primitives to be invoked within .cygport packaging scripts. How to manange the transition, from the monolithic X-start-menu-icons package and script, to this distributed approach -- no idea. -- Chuck
Re: Start menu shortcuts
On 19/08/2009 01:05, Ken Brown wrote: On 8/18/2009 10:46 AM, Ken Brown wrote: Is there a policy about which packages are allowed to create start menu shortcuts? Recent discussion about run.exe on the main cygwin list makes me think it would be useful for the emacs-X11 package to create a shortcut for starting emacs under X. I would do this by putting the following in the postinstall script: /usr/bin/mkdir -p "$(/usr/bin/cygpath -AP)/Cygwin-X" /usr/bin/mkshortcut -AP \ -n Cygwin-X/emacs \ -w /usr/bin \ -i /usr/share/emacs/23.1/etc/emacs.ico \ -a '-p /usr/bin bash -l -c "emacs --display=127.0.0.1:0"' \ /usr/bin/run.exe Is this appropriate or does it violate some guidelines? I just realized that the X-start-menu-icons package already provides an emacs shortcut, so my question is irrelevant. But emacs started by the shortcut in that package doesn't work right because the PATH isn't set up correctly. (For example, if you try to list the current directory with C-x d, you get an error "ls not found".) So it should either be fixed as above or removed from X-start-menu-icons, in which case I'll add it to emacs-X11. I'm not sure what to do about X-start-menu-icons. On the one hand, it is a bit silly now that we have individual packages for each executable rather than everything in xorg-x11-bin, and perhaps it would make much more sense for the individual packages to maintain their own start menu shortcuts. On the other hand, it makes sense for those applications which want to have a start menu icon to be using some kind of standard tool to maintain that start menu shortcut, and X-start-menu-icons.sh is probably that tool :-) On the gripping hand, as it stands, it's a bit broken: - X-start-menu-icons.sh only gets automatically run by the X-start-menu-icons package's postinstall script. It really needs to get run after every setup run to check if it needs to create shortcuts for any newly installed applications. - It only knows how to add shortcuts for applications, and to remove all the shortcuts it's made (on it's own uninstallation). It doesn't know how to delete the shortcuts for applications which are owned by uninstalled packages, leading to stale shortcuts for removed applications. - it can't make shortcuts with external icons, like the example above - as you point out, it doesn't make a correctly working shortcuts for emacs (everything should probably be invoked via bash -l -c so a useful environment exists) - /etc/X11/X-start-menu-icons-list contains the hardcoded list of applications which get start menu shortcuts. This data clearly ought to be in individual packages. (So this perhaps this should be replaced by a directory with files owned by the individual packages?) - if you have parallel 1.5 and 1.7 installations, they will fight over the shortcuts, as they want to create shortcuts with the same name, but have differing ideas of where they should point to... I think Yaakov has some ideas about how to approach this, but I don't know what they are. Anyhow, this is something I am willing to spend a bit of time on, if there was some vague consensus as to the direction we should be heading in.
Re: Start menu shortcuts
On 8/18/2009 10:46 AM, Ken Brown wrote: Is there a policy about which packages are allowed to create start menu shortcuts? Recent discussion about run.exe on the main cygwin list makes me think it would be useful for the emacs-X11 package to create a shortcut for starting emacs under X. I would do this by putting the following in the postinstall script: /usr/bin/mkdir -p "$(/usr/bin/cygpath -AP)/Cygwin-X" /usr/bin/mkshortcut -AP \ -n Cygwin-X/emacs \ -w /usr/bin \ -i /usr/share/emacs/23.1/etc/emacs.ico \ -a '-p /usr/bin bash -l -c "emacs --display=127.0.0.1:0"' \ /usr/bin/run.exe Is this appropriate or does it violate some guidelines? I just realized that the X-start-menu-icons package already provides an emacs shortcut, so my question is irrelevant. But emacs started by the shortcut in that package doesn't work right because the PATH isn't set up correctly. (For example, if you try to list the current directory with C-x d, you get an error "ls not found".) So it should either be fixed as above or removed from X-start-menu-icons, in which case I'll add it to emacs-X11. Ken
