Please Review - Revised OS X Application Bundle patch

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

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