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 come from.
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 standard.
Here's how I see we can do this in Ubuntu:
- 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: http://standards.freedesktop.org/menu-spec/latest/index.html
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 created).
- 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 Winetools).
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).
thanks -mike
-
Mike Hearn