suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch

Steven Edwards winehacker at gmail.com
Sun Jul 19 10:03:49 CDT 2009


On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillard<mahanuu at free.fr> wrote:
> Just few remarks about your patch :
> - why you didn't use CoreFoundation API (plain C and already used in Wine)
> insteed of fprintf to generate Info.plist ?

I didn't see which functionality to call to generate the plist's in C.
Could you point me to the api's that are of use?

> - you don't really need a Carbon launcher. Just a plain shell script in
> MacOS for executable et voila ...
> (sample joined, just edit MacOS/Notepad to set correct path)

Very Nice! I must have overlooked this when I was exploring other
problems like getting the xattr stuff right in the plists. I'll change
my patch to reflect this for the first iteration. I still believe a
future version is going to need some sort of helper application if we
ever want to actually interact with a running instance for example,
sending a quit message or cycling through active windows, etc.

> IMHO In a more general way, it's not a good thing to touch user directory
> without letting him decide.
> For application generated file you should used ~/Library/Application
> Support/Wine
> (see :
> http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI)

I see that but that implies a separate application to manage installed
Wine programs like you state below, like WineHelper. This is going to
be very hard to get in to stock Wine given our limitations on not
using Cocoa

> And at last, an NSStatusItem seem's a better choice to me for a wine
> application starter, instead of fake app bundles.
> Just generated description plist (dictionnary with app name, full path,
> arguments, and icon path ... and what ever you want) in
> ~/Library/Application Support/Wine/WineMenuBuilder
> and lets Helper application (your Bordeau's helper, WineHelper, or Mike
> Kronenberg one's) deal with theese files as they want.

Perhaps but I don't think so. Allow me to present things from the user
perspective. I think writing to ~/Applications/Wine is OK and does not
violate HIG as installing an application under Wine (to me at least)
is analogous to running a mpkg that does not prompt where to install.
The user clearly wants to install the application if it gets to the
point of generating the shortcuts and bundling it up. Having some sort
of helper application application that manages it own internal list of
menus seems to imply multiple operations and steps that don't seem
correct at least to me. Here is the work flow I see

Case 1. With WineApp Helper
User opens HomeDirectory or Finder
User goes to /Applications or ~/Applications and starts the Wine helper
User then selects Winword from the list of known installed Applications
Winword Starts

or

Case 2. With wine app bundles
User opens HomeDirectory or Finder
User goes to /Applications or ~/Applications and selects Winword Bundle
Winword Starts

The second case seems simpler and more intuitive. Now I could see a
third case that would kind of give you the best of both worlds.
Assuming your helper application was part of the Dock, you could have
it act as a special launcher that expands like the way the Documents
and Downloads menu's do and the user could select a given Windows
application from there. Assuming that's the way it behaved we could
have something like the following:

Case 3.
User navigates to Dock and icon for Wine Applications (or whatever its called)
List of Installed Windows Applications is expanded vertically
User Selects Winword from the list
Winword loads

I'm not really opposed to such a design, I think its more friendly
than browsing around in the Applications folders but this all implies
having a helper app that we can get in to Winehq. I know I can't write
it, I don't know anyone can do it and make Alexandre happy. It is
imperative to me to make stock Winehq be functional for the end user
and that includes make some way for the user to have easy access to
the applications they install under Wine. Given that, I will refocus
on sticking the bash script directly in the bundle for now (thanks
again for the tip) as I don't think Alexandre will reject that and we
can go from there. If someone wants to change it to something else
later and can get it in to Winehq, by all means.

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



More information about the wine-devel mailing list