Please Review - Revised OS X Application Bundle patch

[Steven Edwards]

Hi Jörg,

Thanks for the questions. Hopefully I can provide good answers.

On Fri, Dec 4, 2009 at 10:33 AM,  <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> + * NOTES: An Application Bundle generally has the following layout
> + *
> + * foo.app/Contents
> + * foo.app/Contents/Info.plist
> + * foo.app/Contents/MacOS/foo (can be script or real binary)
> + * foo.app/Contents/Resources/appIcon.icns (Apple Icon format)
> + * foo.app/Contents/Resources/English.lproj/infoPlist.strings
> + * foo.app/Contents/Resources/English.lproj/MainMenu.nib (Menu Layout)
>
>
> Could you please comment on why you think that using a .app is the
> right approach? (please explain the goal: provide desktop icons?)
> What do you plan to put into that bundle?
> What would the menu be? (Is there one at all?)

The Application bundle provides a mostly 1 to 1 mapping for any *.lnk
that is generated and processed by Wine Menu Builder. In the case of
my test app I am using Microsoft PowerPoint Viewer 2003 and am able to
drag the resulting .app to the dock, desktop, or anywhere.

> As an alternative, I've been creating .command files, as explained
> in the FAQ http://wiki.winehq.org/MacOSX/FAQs
> They seem conceptually simpler yet provide what you'll find
> in the xyz.desktop file that Wine produces on Linux:

It is conceptually simpler but does not offer the rich features app
bundles gives you.

>  - Icon

I don't know how to make the .command file accept a generate icon in a
automagic fashion. I think there was some hfs meta data magic
involved. Not a big deal but just dumping the generated icon and
editing the plist is the standard way to go.

>  - Terminal window that shows Wine's log and I/O from application.
>   Where does such output go in the .app case?

It goes to the Console Messages viewable with the Console application.
You can run the bundled script directly as it's just a bash script if
you need to debug but the point is to hide the terminal IO from the
user.

>  - file name
>  - Change Directory to app's directory (or any other)
>   It does not depend on wine start /unix
>   Isn't that missing from your patch:
> +    fprintf(file, "#!/bin/sh\n");
> +    fprintf(file, "WINEPREFIX=\"%s\" wine \"%s\" %s\n\n",
> +            wine_get_config_dir(), path, args);
>   This information is present in the .desktop files
>  - Move the icon anywhere you like and click to start it.
>   There's no dependency on Applications/ or any other setting.
>  - Easily modified by the user to change WINEPREFIX, add WINEDEBUG
>   or whatever -- if needed at all.

This is the same way as the *.desktop files on Linux. No need for
start /unix. The idea is that users should NEVER need to mess with
WINEPREFIX or WINEDEBUG settings EVER. If they do then something is
wrong. It should be seemless.

> You'll remember that I presented my approach on 2009-09-14 in this list.

Yes. I disagree with the resource fork hackery you were doing. 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.

> I was wondering whether Wine should create such xyz.command files on MacOS
> instead of the xyz.desktop ones.  They are so close to each other.
>
> Perhaps it is precisely that additional Terminal.app window that
> you or other Mac users might dislike?
> (I've not investigated whether there are "hide" or "auto-close on exit"
> properties that could be set.)

Yes the Terminal window and the lack of ability to make a private Wine.

Let's say I write my own Win32 program called Doodles and its highly
tied to Windows and I don't want to deal with a source port. Using app
bundles I can take doodles.exe, a private install of Wine, the needed
Frameworks and icons, tie it all together in a Doodles.app and give
that to users.

Thanks
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo