suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch

[Emmanuel Maillard]

Le 20 juil. 09 à 15:34, Steven Edwards a écrit :

> On Sun, Jul 19, 2009 at 12:23 PM, Emmanuel Maillard<mahanuu at free.fr>  
> wrote:
>> But it's an external appplication, your desktop environment, that  
>> handle
>> *.desktop file; wine just generate them...
>
> As per the private email I sent. I could see that working if we can
> convince Alexandre of the need of an external helper application for
> OS X. Keeping the existing winemenubuilder code mostly as is and
> having it write xdg menus and associations would be pretty simple. We
> could just change a few lines to have it write xdg in
> ~/Library/Application Support/Wine/WineMenuBuilder

As answered in private email (sorry, just for an short anwser for list)
If we plan to bring freedesktop to Mac OS X, yes we need an external  
application
that doesn't have to go to winehq, winehq doesn't have application for  
Linux
distribution that doesn't be xdg-compliant (if any) ...

>> So don't choose ~/Applications but : /Applications/Wine or
>> let's the user to choose if want an Applications folder in is  
>> Homedir.
>
> The reason for using ~/Applications as opposed to /Applications is
> that Wine has no knowledge or real support for multi-user prefixes.
> Each .wine being local to the user that creates it will have their own
> applications, etc. If we write the menus to /Applications and another
> user logs in then they won't be able to run those applications.
>
>> 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 ...
>
> If the associations for Wine and the given type are set right (*.exe,
> *.msi, *.lnk, *.whatever) then I could see this working at least for a
> default WINEPREFIX. All of that assumes the executable and or links
> are easy to find and we have the virtual start menu. Again the problem
> I see is if your setting associations for installed applications it
> makes supporting a given prefix not really possible.

In case of generated *plist just add you WINEPREFIX in your file.
In case of WineHelper you can define WINEPREFIX in applications  
Preferences.
(just need to be review to be more flexible)

>> 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 don't really know what I want besides a simple way to access
> installed applications. Bundles give me that, though I can see how a
> helper might have some advantages. Honestly though, I don't have the
> free cycles to write one. I've spent over a month or two just
> researching Bundles vs Finder Aliases and HFS resource forks trying to
> come up with a seemless solution and you see how little I've written.
>
>> So please just use /Applications or ask the user if he want an a new
>> directory
>> in his Homedir.
>
> If its truly a single user system then prompting one time for a
> location, either /Applications or ~/Applications seems like the right
> method to me.

Or /dev/null for command line wine users ...

>
> For me though it all comes back down to supporting future design like
> better prefix support while making it work today. I'm going to revise
> my patch to support direct execution of shell scripts and clean it up
> so that its not such a hack with the existing xdg code an resubmit.
> Assuming Alexandre accepts that, there is nothing stopping us from
> developing something better down the road but for now, users will have
> a Wine they can actually use once they have apps installed.
>
> -- 
> 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

Cheers
Emmanuel