Dear Mac developers,
please make suggestions about the xyz_LIBRARY_PATH MacOS issue that allows libpng.so and libfreetype.so to be found at run-time in /usr/X11/lib (bug 17674).
A patch appending /usr/X11/lib to DYLD_FALLBACK_LIBRARY_PATH, much like Mike Kronenberg and MacPorts do, was rejected. http://www.winehq.org/pipermail/wine-patches/2009-July/075290.html
Alexandre Julliard explained to me that he feels the xyz_LIBRARY_PATH feels bad being specific to Wine. He believes that all X11 apps should be affected and this issue be solved at "system level".
Why aren't X11 apps affected on my machine? From the manpages, I believe the issue is specific to dlopen(), not regular shared libraries. Few apps use dlopen(). Configure detects these libraries precisely because it does not use dlopen().
So either we can convince AJ that is issue is specific to Wine, or the best that can be done on MacOS, or file a bug with Apple, or we need another solution.
- Emmanuel Maillard had a patch specific to libfreetype in wineQuartz for 0.9.58, prepending the output of get_runtime_libdir() prior to calling wine_dlopen(). I object that this would have to be repeated for every other particular .so that Wine happens to use, e.g. libpng -- not very nice. (I also don't understand why get_runtime_libdir() would have helped, /usr/X11/lib is needed for these two libraries).
- Other suggestions?
Thanks for your help, Jörg Höhle.
Hi Joerg,
please make suggestions about the xyz_LIBRARY_PATH MacOS issue that allows libpng.so and libfreetype.so to be found at run-time in /usr/X11/lib (bug 17674).
I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that.
Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine. --Juan
On Tue, Jul 14, 2009 at 4:17 PM, Juan Langjuan.lang@gmail.com wrote:
I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that.
Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine.
Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc? If we want to provide a Winehq support Wine package for OS X we have to decide on a configuration that will work and be the least invasive to the users when they go to install.
Steven Edwards wrote:
On Tue, Jul 14, 2009 at 4:17 PM, Juan Langjuan.lang@gmail.com wrote:
I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that.
Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine.
Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc?
Neither. We need to provide an Applescript starter that sets several variables. This is what the OpenOffice.org project decided to do. This would only exist on the MacOSX version of Wine, not Linux. It is not 'rocket science' to makd this happen.
James McKenzie
On Tue, Jul 14, 2009 at 10:04 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Neither. We need to provide an Applescript starter that sets several variables. This is what the OpenOffice.org project decided to do. This would only exist on the MacOSX version of Wine, not Linux. It is not 'rocket science' to makd this happen.
Got a link/example?
If it's that easy, please send a patch.
Le 15 juil. 09 à 05:04, James McKenzie a écrit :
Steven Edwards wrote:
On Tue, Jul 14, 2009 at 4:17 PM, Juan Langjuan.lang@gmail.com wrote:
I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that.
Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine.
Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc?
Neither. We need to provide an Applescript starter that sets several variables. This is what the OpenOffice.org project decided to do. This would only exist on the MacOSX version of Wine, not Linux. It is not 'rocket science' to makd this happen.
James McKenzie
WineHelper start wine with specific environment variables, you need. Just need to add what you want.
Emmanuel
Le 14 juil. 09 à 22:28, Steven Edwards a écrit :
On Tue, Jul 14, 2009 at 4:17 PM, Juan Langjuan.lang@gmail.com wrote:
I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that.
Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine.
Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc? If we want to provide a Winehq support Wine package for OS X we have to decide on a configuration that will work and be the least invasive to the users when they go to install.
That was the goal of Wine.bundle in Darwine.
Emmanuel
-- 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
On Wed, Jul 15, 2009 at 11:11 AM, Emmanuel Maillardmahanuu@free.fr wrote:
Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc? If we want to provide a Winehq support Wine package for OS X we have to decide on a configuration that will work and be the least invasive to the users when they go to install.
That was the goal of Wine.bundle in Darwine.
Austin has updated the dependency build script and we've been using it on my box to build the required libraries but they are not together in a bundle, hence the need for the LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH changes. What do you think is the best way to resolve this issue? My interest is that I'd like to provide binary packages of Winehq releases however this issue is a real pain. I suppose we could also provide a support package that is separate from the stock Wine package which would supply the missing libraries or whatnot.
Thanks
Le 15 juil. 09 à 20:06, Steven Edwards a écrit :
On Wed, Jul 15, 2009 at 11:11 AM, Emmanuel Maillardmahanuu@free.fr wrote:
Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc? If we want to provide a Winehq support Wine package for OS X we have to decide on a configuration that will work and be the least invasive to the users when they go to install.
That was the goal of Wine.bundle in Darwine.
Austin has updated the dependency build script and we've been using it on my box to build the required libraries but they are not together in a bundle, hence the need for the LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH changes. What do you think is the best way to resolve this issue? My interest is that I'd like to provide binary packages of Winehq releases however this issue is a real pain. I suppose we could also provide a support package that is separate from the stock Wine package which would supply the missing libraries or whatnot.
If you build your package in standard path (/usr/local for example) you may not need DYLD_FALLBACK_LIBRARY_PATH (see man dyld for default path).
If you make a complete bundle for Wine, you'll need it, but it may be set dynamically, while initializing wine lib, see get_runtime_libdir.
Now using a bundle or an installer for packing Wine ? IMHO bundles are more friendly to end users.
Emmanuel
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
Emmanuel Maillard wrote:
If you build your package in standard path (/usr/local for example) you may not need DYLD_FALLBACK_LIBRARY_PATH (see man dyld for default path).
This is good, but we should be using the packages in /usr/X11/lib first. Let me check if this is set on my system. I thought and confirmed it is not. This would need to be set in the session(s) that Wine would be running in.
If you make a complete bundle for Wine, you'll need it, but it may be set dynamically, while initializing wine lib, see get_runtime_libdir.
That is one solution.
Now using a bundle or an installer for packing Wine ? IMHO bundles are more friendly to end users.
Bundles are WAY more friendly than using the installer. Installer programs are meant to remain on the system.
James McKenzie
On Fri, Jul 17, 2009 at 9:13 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Bundles are WAY more friendly than using the installer. Installer programs are meant to remain on the system.
+1
Also speaking of bundles I'm going to hijack the thread for a bit, I've got a rough patch going that enables winemenubuilder to be able to spit out bundles when shelllinks are installed. Its still very rough and needs to be redesigned a bit (and Alexandre is not totally sold on parts of the design) but at least its all C. Take a look at the attached patch and give me some feedback if your interested in helping.
Thanks
Steven Edwards wrote:
On Fri, Jul 17, 2009 at 9:13 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Bundles are WAY more friendly than using the installer. Installer programs are meant to remain on the system.
+1
Also speaking of bundles I'm going to hijack the thread for a bit, I've got a rough patch going that enables winemenubuilder to be able to spit out bundles when shelllinks are installed. Its still very rough and needs to be redesigned a bit (and Alexandre is not totally sold on parts of the design) but at least its all C. Take a look at the attached patch and give me some feedback if your interested in helping.
Thanks
Steve:
Look at the includes, you included several header files twice.
This is UGLY, but it is a good start.
James McKenzie
On Fri, Jul 17, 2009 at 10:37 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Steve:
Look at the includes, you included several header files twice.
This is UGLY, but it is a good start.
heh yeah thats why its not gone to wine-patch yet, I've just been hacking and slashing, ignore the mess of headers and C++ style comments.
Its the design I am still working on. I'm curious if everyone thinks this is the right route to go down.
As you can see I've created the helper to invoke generated bash scripts that are stored in the bundle to take care of the environment and the like. I tried looking in to generating of AppleScript app bundles however there seems to be no documented way to do it other than to use the Apple Script tool so no automatted method. At a low level and it embeds its own helper 'applet' program in bundle.app/Contents/MacOS/applet to invoke the embedded AppleScript in bundle.app/Contents/Resources. The carbon C file I included will serve the same purpose for invoking bash and loading our target binary. Later on we will need to teach our bundle helper how to identify Wine windows and cycle through them. Currently all my bundle does is give you the ablity to start a Wine app and have a Dock icon. It's not even a proper parent....such as if you kill the app in the Dock the Wine child keeps running. As I said it still needs a lot of love but I don't see much other way to do it...
Thanks
On Jul 17, 2009, at 10:02 PM, Steven Edwards wrote:
I tried looking in to generating of AppleScript app bundles however there seems to be no documented way to do it other than to use the Apple Script tool so no automatted method.
Are you familiar with the osacompile command?
-Ken
On Sun, Jul 19, 2009 at 7:41 AM, Ken Thomasesken@codeweavers.com wrote:
On Jul 17, 2009, at 10:02 PM, Steven Edwards wrote:
I tried looking in to generating of AppleScript app bundles however there seems to be no documented way to do it other than to use the Apple Script tool so no automatted method.
Are you familiar with the osacompile command?
I must have missed that before but I am afraid I don't see what it buys us other than saving hassle building the directory structure by hand. I don't think we want to use AppleScript rather than bash directly as Emmanuel suggested. Take for instance starting a new application, we will need something like
do shell script "WINEPREIFX=foo path/to/wine bar.exe"
Unless you know of some way to set the environment for only the parent and child applications for a given AppleScript. I found directions on how to do it globally but any shortcuts/scripts/bundles/whatever must honor the WINEPREFIX variable for each application.
http://developer.apple.com/qa/qa2001/qa1067.html
I am very open to being proved wrong though ;)
Le 18 juil. 09 à 04:06, Steven Edwards a écrit :
On Fri, Jul 17, 2009 at 9:13 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Bundles are WAY more friendly than using the installer. Installer programs are meant to remain on the system.
+1
Also speaking of bundles I'm going to hijack the thread for a bit, I've got a rough patch going that enables winemenubuilder to be able to spit out bundles when shelllinks are installed. Its still very rough and needs to be redesigned a bit (and Alexandre is not totally sold on parts of the design) but at least its all C. Take a look at the attached patch and give me some feedback if your interested in helping.
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 <update-bundler.diff>
Hi,
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 ? - 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)
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/Arti... /apple_ref/doc/uid/20002282-BAJHCHJI)
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.
Emmanuel
On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillardmahanuu@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/Arti...)
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.
Le 19 juil. 09 à 17:03, Steven Edwards a écrit :
On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillardmahanuu@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/CFPropert...
- 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/Arti... /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
On Sun, Jul 19, 2009 at 12:23 PM, Emmanuel Maillardmahanuu@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
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.
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.
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.
Le 20 juil. 09 à 15:34, Steven Edwards a écrit :
On Sun, Jul 19, 2009 at 12:23 PM, Emmanuel Maillardmahanuu@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
On Mon, Jul 20, 2009 at 2:48 PM, Emmanuel Maillardmahanuu@free.fr wrote:
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) ...
Yes it pretty much depends on the portland tools to already be ported. I agree and don't think its worth our effort to try and support our own helper to parse or convert xdg when the bundle format is so simple. We can reuse a lot of the internals of xdg support in the menubuilder to convert icons and spew out data the plist's need without having to try to teach OS X to support a non-native format.
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)
I didn't think about this. Yes it would be possible to define the variable there.
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 ...
Heh yes perhaps their should be a variable to tell it to not generate a menu at all.
Juan Lang wrote:
Hi Joerg,
please make suggestions about the xyz_LIBRARY_PATH MacOS issue that allows libpng.so and libfreetype.so to be found at run-time in /usr/X11/lib (bug 17674).
I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that.
No, I won't and I can't. So there. Wine will need a startup script to fix this problem. That is what Zach Drayer and Mike Kronenberg do. This is what OpenOffice.org does.
Fink and MacPorts both build their own LD_LIBRARY_PATH and permenantly alter it.
James McKenzie
Juan Lang wrote:
Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine.
There's confusion here: The problem here is not with MacPorts or Fink. I have neither of them on my system. Just MacOS, some developer packages from Mac's install DVD, X11User.pkg from this DVD, XQuartz and Wine compiled myself (+ SuspiciousPackage.pkg, admitedly). That's all it takes to run into trouble.
Kronenberg and MacPorts set DYLD_FALLBACK_*, Fink sets LD_LIBRARY_PATH to work around the issue.
it's just an error in your configuration.
I strongly disagree. Points can be made that it's either an error A) in Wine or B) at the system level. But it's never C) the user's.
Here are the arguments:
A) An application whose ./configure manages to detect and use X/FreeType/png, should ensure that those detected paths also work at run-time. Maybe autoconf needs a patch? Maybe there's a need for a winewrapper.in to get filled with the X_LIBS path?
B) The Mac must ensure that all X apps work fine at "system level" - for all users. Not including /usr/X11/lib into the default path looks like a major goof from Apple. Or they should provide means to remember default path (e.g. on Solaris, -Lpath for shared libraries is not only a link-time indication, it's remembered for run-time).
I'll look into B) should this issue persist after I'll be back from vacation.
Regards, Jörg Höhle
There's confusion here: The problem here is not with MacPorts or Fink. I have neither of them on my system. Just MacOS, some developer packages from Mac's install DVD, X11User.pkg from this DVD, XQuartz and Wine compiled myself (+ SuspiciousPackage.pkg, admitedly). That's all it takes to run into trouble.
Then the issue is that these packages are installed in an appropriate location, one that is not searched when attempting to dynamically load them. This configuration error is not Wine's fault, and even if we worked around it other apps that attempted to load them dynamically would have the same problem.
Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike--but it's too different from mainline to be considered stock Wine. A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want. --Juan
On Thu, Jul 16, 2009 at 11:25 AM, Juan Langjuan.lang@gmail.com wrote:
Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike--but it's too different from mainline to be considered stock Wine. A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want.
If this would really be accepted by Winehq then we have that solution. The build script Austin has been developing on my box provides the missing libraries. If we can do releases with it and bundle the missing libraries in our package that will solve a lot of problems.
On Thu, Jul 16, 2009 at 10:52 AM, Steven Edwardswinehacker@gmail.com wrote:
On Thu, Jul 16, 2009 at 11:25 AM, Juan Langjuan.lang@gmail.com wrote:
Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike--but it's too different from mainline to be considered stock Wine. A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want.
If this would really be accepted by Winehq then we have that solution. The build script Austin has been developing on my box provides the missing libraries. If we can do releases with it and bundle the missing libraries in our package that will solve a lot of problems.
Yes, bundling those packages should be pretty easy. Joerg pointed out to me privately that libpng and a few others should now fall back to OS X's preinstalled versions, so the script may need updating..I'm not sure what else OS X provides off hand.
Of course, those dependencies may conflict with installed software, but without a mac, I can't tell for sure.
Juan Lang wrote:
Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike--
Note that Mike does it exactly by wrapping the winewrapper in yet another shell script wrapper. My patch aimed at eliminating that wrapper, in order to reduce the diffs between Mike, MacPorts, Fink and stock Git.
A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want.
Emmanuel's post shows that indeed, a solution exist as far as GUI-invocation goes, using this bundle concept.
But from what I understand, you'll again run into trouble as soon as you want to use wine the UNIX way: from the command line (e.g. when running automated tests) -- unless one invokes that wrapper, which then calls the "official WineHQ" winewrapper.
Well enough said, I'll study manpages once more after my vacation, and see if there's some system level solution.
Regards, Jörg Höhle.
On Jul 16, 2009 12:55 PM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Juan Lang wrote: >Another way of looking at the error is that MacPorts (and fink, I >presume) instal... There's confusion here: The problem here is not with MacPorts or Fink. I have neither of them on my system. Just MacOS, some developer packages from Mac's install DVD, X11User.pkg from this DVD, XQuartz and Wine compiled myself (+ SuspiciousPackage.pkg, admitedly). That's all it takes to run into trouble.
Kronenberg and MacPorts set DYLD_FALLBACK_*, Fink sets LD_LIBRARY_PATH to work around the issue.
it's just an error in your configuration.
I strongly disagree. Points can be made that it's either an error A) in Wine or B) at the system level. But it's never C) the user's.
Here are the arguments:
A) An application whose ./configure manages to detect and use X/FreeType/png, should ensure that those detected paths also work at run-time. Maybe autoconf needs a patch? Maybe there's a need for a winewrapper.in to get filled with the X_LIBS path?
B) The Mac must ensure that all X apps work fine at "system level" - for all users. Not including /usr/X11/lib into the default path looks like a major goof from Apple. Or they should provide means to remember default path (e.g. on Solaris, -Lpath for shared libraries is not only a link-time indication, it's remembered for run-time).
I'll look into B) should this issue persist after I'll be back from vacation.
Regards, Jörg Höhle
-
Austin English -
Emmanuel Maillard -
James McKenzie -
Jeremy Nowka -
Joerg-Cyril.Hoehle＠t-systems.com -
Juan Lang -
Ken Thomases -
Steven Edwards