winemenubuilder: Nothing useful is done on Mac OS X so just exit.

[Joerg-Cyril.Hoehle at t-systems.com]

François Gouget wrote:
> A real Mac OS X implementation would be nice but barring that it seems 
> better to do nothing than to create .desktop files and directories that 
> make no sense on Mac OS X.
Perhaps it's better to produce something than produce nothing.

Since I first used Wine, perhaps half a decade ago, I've always been
looking at the .desktop files to see what the installers declared as
 - command line arguments and
 - initial directory.
Simply starting an .exe in the file manager is not always enough.

That info is also available by tracing a particular channel, however
the .desktop is persistent, while I may have forgot to trace that
verbose WINEDEBUG channel during installation.

With that information, I created my own .desktop files on Linux
and .command files on MacOS.

I was also more pleased back when Wine wrote human readable .desktop
files into the various profile/ subdirectories instead of the current
.lnk binary files.  What tool can read those pesky .lnk files?

Since then I've been annoyed by Wine on Linux repeatedly rebuilding
Gnome menus, spitting errors about Wireshark that's not even a Wine
app, as well as Wine on MacOS flooding /tmp with .icons files as
mentioned in
http://www.winehq.org/pipermail/wine-devel/2011-December/093570.html
$HOME/.local/share/icons/ never contained a flood of icons, just one
per installed app and readme.

On both systems, I've repeatedly removed winemenubuilder from the
registry, only to find Wine's next update put it back.

Whatever you do, please make sure that users can obtain an installed
app's command line arguments and launch directory in a simple way.

While improving the Mac user experience, what about enhancement request 19028?

Thank you,
      Jörg Höhle