[UPDATED] HowTo: Run WINE programs with GNOME Do

Since I got a new color PDA recently I’ve been throwing a lot more pictures on it. The new PDA, like my old black & white one, is a Sony Clié and comes with Sony’s PictureGear Lite app for putting pictures and movies on my PDA, and since I finally have a color PDA I’m more interested in putting pictures on it to share with friends that I run into. But to move pictures (and movies) onto my PDA requires running PictureGear, a Windows program that runs on Linux under WINE, and I couldn’t find a good way to run WINE apps via GNOME Do. Until I was dealing with my Do/Synaptic issue that I posted about earlier this morning.

I already had a Nautilus window opened to my /usr/share/applications directory with admin rights (via sudo nautilus), so I opened a regular Nautilus window to /home/peng/.local/share/applications/wine/Programs and went into the directory that held the launcher for PictureGear Lite. I dragged the launcher for PictureGear to the sudo nautilus window with /usr/share/applications open, while holding down the Ctrl key to do a drag and copy, and placed a copy of the PictureGear launcher into /usr/share/applications.

The new launcher didn’t have an icon, but I simply went into the launcher’s Properties window clicked the icon button and selected the appropriate icon from /home/peng/.local/share/icons, which is the directory that WINE stores icons for Windows programs that have been installed. Once I had the correct icon selected I simply closed the Properties window.

After I fix the icon for my new launcher I closed GNOME Do and reopened it, to force Do to grab the new launcher, and then started typing PictureGear. Lo and behold, I was able to launch PictureGear Lite from within GNOME Do!

I’ll need to go back into the launcher’s properties screen to add a description, but I’m able to start a Windows app that I use almost daily without having to reach for the menus.

Updated 24 May 2009: If you want to do this procedure for applications that were installed with CrossOver Linux rather than WINE the path you want to find the launchers to copy from will be ~/home/.cxoffice/[bottle_name]/desktopdata/cxmenu/xdg-applications. From there simply drill down through the folder hierarchy and drag the appropriate .desktop file. When I did that I didn’t need to manually set the icon, which is a step that you may not have to perform.

Is GNOME Do launching Synaptic without admin rights?

Last week I took some updates that left me unable to use GNOME Do to launch Synaptic. After a bit of hunting I eventually posted a question on the GNOME Do Google Group asking about it.

Igor asked me if I run KDE, but before I could see the query I saw a post from Alex Launi that included a link to Bug #242992 – Do 0.5 open synaptic in non root mode. It turns out I’m definitely not the only one experiencing the issue. A Launchpad member with the amusing nick of Darwin Award Winner identified the cause of the problem and posted a workaround until the bug can be resolved properly.

I think I found the problem:

$ locate synaptic | grep desk
…
/usr/share/applications/synaptic-kde.desktop
/usr/share/applications/synaptic.desktop
…

$ cat /usr/share/applications/synaptic-kde.desktop
Name=Synaptic Package Manager
…
Exec=synaptic
…
X-KDE-SubstituteUID=true
…

synaptic-kde.desktop has the same “Name” field as the regular synaptic.desktop, so I guess it clobbers it in the serach results. KDE has a different “su” mechanism that doesn’t involve the Exec field, so any non-KDE-aware application that simply reads the “Exec” line will not know to run the program as root.

Here’s the basis for a cheap workaround: whichever of the two desktop entries sorts lexicographically higher takes precedence. As it is, a dash sorts higher than a period, so synaptic-kde.desktop beats synaptic.desktop. Simply change the dash to an underscore, and synaptic.desktop beats synaptic_kde.desktop, and balance and order will be restored to the universe (at least until the next update of the synaptic package clobbers the change).

$ mv /usr/share/applications/synaptic-kde.desktop /usr/share/applications/synaptic_kde.desktop

I suppose the real fix would be to support the “X-KDE-SubstituteUID” field, though I’m not sure how to do that.

I tried looking for the appropriate file in Nautilus, but I wasn’t sure I could handle the renaming with 100% certainty in Nautilus (I’m still working on my first cup of coffee) so I definitely recommend doing it from the command line.

There’s a question as to why we’d even have a /usr/share/applications/synaptic-kde.desktop in the first place if we’re running a primarily GNOME box, but I don’t have an answer for that. The good news is that you can simply delete /usr/share/applications/synaptic-kde.desktop if you’re running a primarily GNOME system. Darwin Award Winner also suggests a way to make it permanent on Debian-based systems.

I should note, if you want to make my workaround permanent (i.e. survive package updates) on a Debian-based system (e.g. Ubuntu), try this command, which should tell the package manager to divert the file to its new location:

sudo dpkg-divert –divert /usr/share/applications/synaptic_kde.desktop –local /usr/share/applications/synaptic-kde.desktop

I haven’t tried that yet but if you were to run it you wouldn’t have to worry about an update overriding your using the first workaround. Kudos to Alex Launi and Darwin Award Winner for helping me resolve the issue. I owe both of them a beer.