One of the most commonly requested features for Wine is for Wine to be
aware of applications that put themselves into the Windows Start menu.
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.
However, there are some other barriers to entry that are now turning
around thanks to the Freedesktop.org specs.
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:
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:
http://standards.freedesktop.org/menu-spec/latest/index.html
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
Winetools).
1 and 2 will get us some nice launch icons for the important pieces of
Wine that most users aren't yet aware of (such as the new uninstaller
and winecfg tools). Combined with Wine's ability to make desktop
launcher icons when a program says to install an icon on the desktop,
this should be a fairly good start at making Wine console-free.
3.) The menu specification can also point to a new location in the local
user's .wine directory, probably something like ~/.wine/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. 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.
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.
5.) Different architecture issues. One of these days a working amd64
version of the Wine packages will be available (perhaps whenever I
manage to afford a new amd64 computer). It's entirely doable to make it
work transparently, once the upstream quirks in compiling Wine on 64 bit
get worked out. We can also install 32 bit libraries (so we can run 32
bit windows programs) in a way similar to what we do with Open Office.
The PowerPC version of the packages, however, is another issue.
Obviously, we can't make Wine work with i386-compiled apps on PPC,
however we can make it work with Winelib ones. If I ever finish
packaging up eMule after getting it to compile in Winelib, a PPC Wine
package version could put the .desktop files into the same place as
Winetools goes, and then put eMule right there alongside it on PPC.
Alternatively, on PPC we could just not use the new Windows Applications
submenu altogether, and instead put Winelib apps like eMule in a normal
place like Applications->Internet.
I still have no idea exactly who is going to do which part of this work,
or when, but it all seems like the right way forward to me. Comment is
very appreciated.
Thanks,
Scott Ritchie