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