Please Review - Revised OS X Application Bundle patch

[Steven Edwards]

Hi,

On Fri, Dec 4, 2009 at 1:10 PM,  <Joerg-Cyril.Hoehle at 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
-- 
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