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@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