Steven,
- Change Directory to app's directory (or any other)
This is the same way as the *.desktop files on Linux. No need for start /unix.
You did not respond to the specific directory issue. The Linux desktop takes care of using the Path=/foo/bar if it exists. Wine sets it. I saw nothing about it in your patch. You may not notice immediately when it is missing, because some apps start nevertheless, but fail mysteriously later. Other apps work just fine when started from any directory.
Yes. I disagree with the resource fork hackery you were doing.
It was just to automate it in a few lines of script. C code would access the API. Using the GUI, you put the Icon in place by drag&drop in the Information view.
It's not that way any other application vendor bundles an app on OS X. Using an application bundle, it would be possible for a third party vendor to take a full install of Wine, the vendor application and a custom prefix and tie the entire thing together in one bundle as a winelib application. *.command files don't allow that.
Agreed, but how will the user take the 3 .app that result from a typicall install of application XY (namely "Play XY", "Help on XY.app", "Deinstall XY.app") and merge that with a 4th app, namely Wine.app?
You did not explain the "grand scheme of things" that ties it all together. Or I did not understand it.
The Application bundle provides a mostly 1 to 1 mapping for any *.lnk that is generated and processed by Wine Menu Builder.
What is this "Wine Menu Builder"?
IMHO the Mac's ".app is one icon" does not match the typical installation on MS-Windows with 3-4 icons (the 3 above plus "About XY.url"). What do you plan to do about these 4 vs. 1 icons? How can the "Deinstall XY" bundle be related to the "Play XY" bundle?
What I visually "see" is what existed in MS-Win3.x: Program manager windows that grouped together all the related icons. They still exist: just visit C:\users\me\startmenu\x\y\z with the file manager. These days you typically access the icons only via the "Start" menu.
Kronenberg's distribution presents itself like win3.x: 3 icons in a window: one starts Wine, an other is the help file. But this window comes from a .dmg, while a .app presents one single icon.
The idea is that users should NEVER need to mess with WINEPREFIX or WINEDEBUG settings EVER.
Agreed for WINEDEBUG. I disagree for WINEPREFIX. Otherwise you could just hard code it to "$HOME/.wine". For a WINEPREFIX != "~/.wine" to come into existance at all, the user MUST have set it to something else. It does not appear out of the blue.
There is a need for different WINEPREFIX and your (or any) solution must provide a way to access it. E.g. several Wiki pages recommend installing DirectX9 into a distinct WINEPREFIX, for good reason. Apps that depend on native DX9 should run in this WINEPREFIX.
Regards, Jörg Höhle