Hi,
+ * 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?)
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: - Icon - Terminal window that shows Wine's log and I/O from application. Where does such output go in the .app case? - 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. You'll remember that I presented my approach on 2009-09-14 in this list.
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.)
Regards, Jörg Höhle
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
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
Hi,
On Fri, Dec 4, 2009 at 1:10 PM, Joerg-Cyril.Hoehle@t-systems.com wrote:
- 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.
I still am not sure I understand the problem. Using start /unix should not be required in any case as far as conversion from the Shellink info. As far as I understand it, start /unix is really only required to emulate the environment you get when doing associations but I could be mistaken. I don't really see why or what would be broken on OS X to require it but xdg-desktop entries on Linux to not need it.
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.
Can you provide me with an example app so I can check out the behaviour?
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.
Sorry if it sounded offensive. It's creative hackery but still does not seem right to go messing with the resource forks and doing things in the method that you were doing to trick it to get icons there.
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?
For a private winelib.app Wine itself could either live in the Contents folder of the bundle or be a Framework that's part of the bundle. It does not really matter. If it's a Framework then you would have a *.pkg installer that would install it and then install the required *.app bundles that would have each Win32 application inside of them.
You did not explain the "grand scheme of things" that ties it all together. Or I did not understand it.
Well, winemenubuilder generating app bundles is just a small part of the overall stuff we need to fix to make Wine suck less on OS X. Here is a more concise list of things we need to fix
- Dependant Runtime Libraries We either need to bundle up all of the deps in to a Wine support Framework or work with the third party libraries to make them more OS X friendly. From discussions I've had with Alexandre in the past, he does not object to us tieing everything up in to a framework that gets installed as part of the Wine bundle.
- Association support
- Proper Dock integration I believe we can teach the wine process to be a bit smarter using something like _NET_WM_PID and then be able to send messages to X11.app to do things like Min, Max, Resize, etc of a Wine process in a X11 session. Of course a proper quartz driver would make this unneeded.
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"?
wine/programs/winemenubuilder
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?
I am not sure I am following you. I've not coded the icon support yet as the backend code on the Linux side needs and overhaul anyway but what it currently does is lookup the hicon or hbitmap reference in the executable rsrc and matches the proper one to what the *.lnk requests. I planned on just reusing that same logic. I can get at the data TODAY and make icons, it's just I don't know if they will work everywhere.
PNG could be made to work TODAY in some cases but not others and OS X prefers *.icns. I could just take the resulting png use the tiff and icns conversion tools to convert it however the existing backend is still wrong. winemenubuilder calls libpng directly to do its conversion of the HBITMAP data. This is really wrong and should be fixed first before we worry about the icons. winemenubuilder needs to be refactored to use windowscodecs.dll or a higher level library that can parse png natively however our current windowscodecs.dll lacks 32bit w/Alpha channel support so it would be a step back for me to go ahead and just plug in WIC support. The underlying dll must be fixed first.
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.
I am not sure I follow, I've not looked at his distribution lately but it seems wrong. Wine should be transparent to the user with the exception of the documentation.
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.
Well maybe I should have been more clear. They should NEVER need to mess with WINEDEBUG unless there is a problem. My code takes in to account a different WINEPREFIX. That variable gets set if they install using a different prefix other than ~/.wine. winemenubuilder, *.desktop files and my app bundle patch look for that variable and set it accordingly. It's up to the user to figure out how to install using another WINEPREFIX until we have a better solution in place.
Thanks
Hi,
I still am not sure I understand the problem. Using start /unix should not be required
I'm sorry for the confusion. Forget everything about start /unix. I don't use it and mentioned it because there are some posts in the forum where somebody is fighting with it and the app's current directory on MacOS. What I meant is that my script does cd /to/the/dir found in a .desktop's Path= line (then uses wine app.exe like you). I found nothing like this in your patch.
Can you provide me with an example app so I can check out the behaviour?
IIRC The Alien Nations behaves differently whether you start in the apps root directory or from within the bin/ subdir where the .exe lies. IIRC some movies would not play, or load/save not work.
Sorry if it sounded offensive. It's creative hackery
Here's the 100% no-hackery version: a) Run sips -i img.extension on whatever image you want (.png or not). b) Create the .command shell script with an editor. c) Using Cmd-I (Information), make it executable and copy&paste an icon image onto the tiny icon in the top left. Caveat, the icon may not be updated immediately in the Finder's view.
PNG could be made to work TODAY in some cases but not others and OS X prefers *.icns.
.png are created today in ~/.local/share/icons/ by Wine on Mac and Linux. (It used to be .xpm in the past and configure must detect libpng). Note that .png is mere *output* from Wine because that's what FreeDesktop wants as input (and .xpm). Judging from the .icns size, this looks like a non-compressed format. There should be enough code in Wine or MacOS to turn the installer submitted raw icon data into whatever Mac's icon resource fork requires. windowscodecs need not be beinvolved IMHO (I mean it should need nothing that was not already present in 0.9.x).
Regards, Jörg Höhle
On 07.12.2009, at 18:08, Joerg-Cyril.Hoehle@t-systems.com Joerg-Cyril.Hoehle@t-systems.com wrote:
.png are created today in ~/.local/share/icons/ by Wine on Mac and Linux. (It used to be .xpm in the past and configure must detect libpng). Note that .png is mere *output* from Wine because that's what FreeDesktop wants as input (and .xpm). Judging from the .icns size, this looks like a non-compressed format. There should be enough code in Wine or MacOS to turn the installer submitted raw icon data into whatever Mac's icon resource fork requires. windowscodecs need not be beinvolved IMHO (I mean it should need nothing that was not already present in 0.9.x).
This can be easily done, I've integrated lately similar functionality in WineBottler. If You already have the png only the sipping part of this little script is needed.
createIconsFromExe.sh
#!/usr/bin/env bash PATH_TO_EXECUTABLE=$(echo "$PATH_TO_EXECUTABLE" | sed s'/\///g') MAINICON=$(echo $(wrestool -l --type=group_icon "$PATH_TO_EXECUTABLE") | awk '{print $2}' | sed 's/--name=//') MAINICON=$(echo $MAINICON | sed s/'//g) rm /tmp/MAINICON.ico &> /dev/null wrestool -x --type=group_icon --output=/tmp/MAINICON.ico --name=$MAINICON "$PATH_TO_EXECUTABLE" &> /dev/null sips -s format icns /tmp/MAINICON.ico --out "$PATH_TO_ICON" &> /dev/null rm /tmp/MAINICON.ico &> /dev/null
Mike
On Mon, Dec 7, 2009 at 12:46 PM, Mike Kronenberg mike.kronenberg@kronenberg.org wrote:
This can be easily done, I've integrated lately similar functionality in WineBottler. If You already have the png only the sipping part of this little script is needed.
createIconsFromExe.sh
Oh sure, we can do it now, but like I just said to Joerg, just because we can do it now does not mean that Alexandre will let us do it now. Winemenubuilder really needs to be cleaned up and abstracted as we go along in this process.
1. Generic App Bundle Support (my patch does this) 2. Pretty Icon support (next on the list) 3. Associations
At each step along the way, Alexandre is going to want it to at least be cleanly separated so it can be re-factored. Just look at how I had to hook in to the main winemenubuilder file and bail out on unsupported features. It's intimately tied to xdg which is good for the Linux side but sucks for us, and what if tomorrow someone invents something better on Linux for menus or associations? It really needs to be abstracted the right way.
On 04.12.2009, at 19:10, Joerg-Cyril.Hoehle@t-systems.com Joerg-Cyril.Hoehle@t-systems.com wrote:
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.
Just have throw in me 2 cents here... ...I think we follow two totally different approaches.
Standard Wine is going the "ideal" path, where wine is just another abstraction layer like rosetta on OS X. It gracefully handles exes, installs files transparently to the OS X FS, mostly direct into the correct paths... we already have links into the home folder of the user, maybe there could be another one for the "Program Files" folder, so users find their stuff where they expect it. In this way of thinking, having simple startup scripts to maybe fix the wineprefix is enough . In an ideal world, there is only one prefix. Using the resource fork for the custom file-image is the standard OS X way of applying icons to non bundle files. There are simple carbon or cocoa calls to do that.
But there is no ideal world, when it comes to run windows apps on an OS that shares about nothing with Windows, speaking in terms of architecture, security concerns and human user interface guidelines. It might be technically correct (in the eyes of windows) to have a gazillion icons on my desktop, after installing a windows app. But this is not the OS X way. On OS X, the help has its help menu entry, the link to the program homepage goes probably into the about dialog and there is no uninstaller, as everything *should* be contained inside the app bundle. Further, the contents of the bundle should have probably the correct chmod settings and should work without admin privileges (the run wine as root thread comes to my mind). They should not be able to alter other applications. Further there is the "I can haz virus, too" thematics and the sand-boxing postings of Dan Kegel, which brings the direct linking of all native host directories into another light. This all together just gives me the Heebie-jeebies on OS X. And this is why I go the "one prefix per app" way. I try to shoehorn everything into an as hermetic capsulated packages as possible :).
If I want windows behavior, I run Windows. But I just want one or two windows apps running on OS X, and they should behave like citizens of OS X.
But doing this for every OS Wine runs on, will just blow the boundaries of this project. This is why I suggest to continue the "ideal" path. The rest can be done by "platform natives" like it's done on loads of OSprojects.
This brings me to some other things I wanted to post about earlier. The more I try to isolate wine, the more lose endings I need to grab.
With the link to the host OS user folders, wine is spamming the host OS on all channels. Starting with little things like ~/Desktop/*.lnk. .thumbs and all other win system files will follow, I'm sure.
Then there are the other "hardcoded" wine folders .wine (no problem with that) ~/Desktop/*.desktop (ok, I can disable this one with the menu hack)
But what about these: ~/.local/share/applications ~/.local/share/desktop-directories ~/.local/share/icons ~/.lcoal/share/mime Can I somehow disable them or move them inside the prefix? I know the concept of "share", but since I started with answering mails about how to completely remove wine the list of files and folders to search and clean is growing constantly.
Mike
Hi Mike,
On Sat, Dec 5, 2009 at 2:43 PM, Mike Kronenberg mike.kronenberg@kronenberg.org wrote:
I cut out the rest of the discussion for the moment as I am short on time and it's clear we all have a different philosphical POV on how Wine should behave. I'll leave it up to Alexandre to decide as far as my patch goes for app bundles. I think Wine users on OS X will attribute the bad behavior you describe to being part of the pain of dealing with Windows apps. At least when I was supporting CrossOver on OS X, most of the apple users I spoke with were more accepting of the glitches and limitations as opposed to how they would expect normal Mac software to behave. Maybe times I heard something along the lines of "it's ok, this is a windows app I am dealing with".
But what about these: ~/.local/share/applications ~/.local/share/desktop-directories ~/.local/share/icons ~/.lcoal/share/mime Can I somehow disable them or move them inside the prefix? I know the concept of "share", but since I started with answering mails about how to completely remove wine the list of files and folders to search and clean is growing constantly.
This is xdg-associations winemenubuilder is trying to handle. My patch disables this behavior on OS X until we properly fix associations.
Thanks
On 05.12.2009, at 23:45, Steven Edwards wrote:
Hi Mike,
On Sat, Dec 5, 2009 at 2:43 PM, Mike Kronenberg mike.kronenberg@kronenberg.org wrote:
I cut out the rest of the discussion for the moment as I am short on time and it's clear we all have a different philosphical POV on how Wine should behave. I'll leave it up to Alexandre to decide as far as my patch goes for app bundles. I think Wine users on OS X will attribute the bad behavior you describe to being part of the pain of dealing with Windows apps. At least when I was supporting CrossOver on OS X, most of the apple users I spoke with were more accepting of the glitches and limitations as opposed to how they would expect normal Mac software to behave. Maybe times I heard something along the lines of "it's ok, this is a windows app I am dealing with".
But what about these: ~/.local/share/applications ~/.local/share/desktop-directories ~/.local/share/icons ~/.lcoal/share/mime Can I somehow disable them or move them inside the prefix? I know the concept of "share", but since I started with answering mails about how to completely remove wine the list of files and folders to search and clean is growing constantly.
This is xdg-associations winemenubuilder is trying to handle. My patch disables this behavior on OS X until we properly fix associations.
Great! +1
-
Joerg-Cyril.Hoehle＠t-systems.com -
Mike Kronenberg -
Steven Edwards