Wine Start Menu in the Desktop Applications Menu
mike at navi.cx
Sun Mar 13 06:33:45 CST 2005
On Sat, 12 Mar 2005 18:09:52 -0800, Scott Ritchie wrote:
> We've talked about it on the Wine lists before, but there have been some
> difficulties. The first is that we don't yet understand how to read
> Windows shortcut files and interpret them: this can probably be overcome
> with some work.
Really? That's news to me. We can read .lnk files just fine and even
produce .desktop files for them, that's where the icons on the desktop
> Here, I propose a short plan of action for getting Wine applications
> into the Applications menu. Some of these need to be done at the
> distribution level and some need to be done within Wine. When we have
> it working nice and smoothly we can submit whatever changes we made to
> freedesktop.org as well if they need to become a cross-distribution
> Here's how I see we can do this in Ubuntu:
> 1) Create a new Menu entry in the .menu file
> at /usr/share/gnome-app-install/applications.menu This one will be
> named "Windows Applications" and will need to point to two locations
> for .desktop files: system-wide ones, and user-specific ones.
> Instructions for how to do this are here:
I don't think that's right, gnome-app-install is an Ubuntu thing.
What you mean is we can drop a .menu file into
~/.config/xdg/menus/applications-merged and it'll be automatically linked
in. We can do this in wineprefixcreate (or when the first menu entry is
> 2) Create some Wine .desktop files that can go
> in /usr/share/applications that will be readable by this menu entry.
> These will be for system-wide Wine apps that are common to all users.
> This will include Wine's own apps (like the configuration tool and the
> uninstaller) as well as packages which depend on Wine (such as
If we're going to create our own submenu to map the start menu we may as
well put stuff like winecfg and the control panel there. No need to merge
them into the main menu (where would they go, anyway?)
> 3.) The menu specification can also point to a new location in the local
> user's .wine directory, probably something like ~/.wine/menu.
The winemenubuilder program is a winelib app so it'd be better to have it
in, eg "~/.wine/drive_c/windows/start menu"
> Here we'll have the user-specific .desktop files that link to the
> Windows applications that user has installed. Once we figure out how to
> make Wine build a start menu and translate the shortcuts into .desktop
> files, they can be created there.
It already does/can do, see winemenubuilder. We basically need to ensure
it still works (probably hasn't actually worked properly for ages) and
then merge the start menu directory in using the <LegacyMenuDirs> element.
> These files can be kept up to date
> (such as when a user installs a new windows application) by the
> wineserver program. What will then tell Gnome to update the
> applications menu (since new .desktop files will have been created) I'm
> not sure yet.
Not quite. The wineserver is a low level thing. Menu entries are created
on the fly by the shell linker interface. GNOME monitors the menu
directories/files so when they change it can reload the definitions (in
theory, in practice this is broke on quite a few distros).
> 4.) Once we get all that working, then we can start playing around with
> icons. This should be fairly easy to translate across platforms. It
> would be nice to have icons that Windows apps install available
> centrally - this could perhaps be another dekstop integration task on
> the Wine todo list.
Already done. Again, observe that programs can place launchers onto the
desktop (which you can then drag to the panel etc).
More information about the wine-devel