suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch

[Emmanuel Maillard]

Le 19 juil. 09 à 17:03, Steven Edwards a écrit :

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

http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPropertyLists/CFPropertyLists.html

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

But it's an external appplication, your desktop environment, that  
handle *.desktop file; wine just generate them...

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

So don't choose ~/Applications but : /Applications/Wine or
let's the user to choose if want an Applications folder in is Homedir.

> 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

False with WineHelper :
User opens HomeDirectory or Finder
User goes to desired path and selects Winword.exe (.msi, .lnk)
(Helper start if needed) Winwords start
as intuitive as your Case 2 ...

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

WineHelper is Open Source so you can add any features you want, fork it,
ask write access to Darwine CVS, send me patches (i must still have  
write access)

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

So please just use /Applications or ask the user if he want an a new  
directory
in his Homedir.

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

Emmanuel