On Tue, Jul 14, 2009 at 4:17 PM, Juan Lang<juan.lang(a)gmail.com> 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. -- 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 Tue, Jul 14, 2009 at 10:04 PM, James McKenzie<jjmckenzie51(a)earthlink.net> wrote: Got a link/example? If it's that easy, please send a patch. -- -Austin

Le 14 juil. 09 à 22:28, Steven Edwards a écrit : That was the goal of Wine.bundle in Darwine. Emmanuel

Le 15 juil. 09 à 20:06, Steven Edwards a écrit : 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

On Fri, Jul 17, 2009 at 9:13 PM, James McKenzie<jjmckenzie51(a)earthlink.net> wrote: +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

On Fri, Jul 17, 2009 at 10:37 PM, James McKenzie<jjmckenzie51(a)earthlink.net> wrote: 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 -- 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 Sun, Jul 19, 2009 at 7:41 AM, Ken Thomases<ken(a)codeweavers.com> wrote: 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 ;) -- 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 Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillard<mahanuu(a)free.fr> wrote: 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? 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. 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 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

On Sun, Jul 19, 2009 at 12:23 PM, Emmanuel Maillard<mahanuu(a)free.fr> wrote: 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 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. 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. 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. 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. -- 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 Mon, Jul 20, 2009 at 2:48 PM, Emmanuel Maillard<mahanuu(a)free.fr> wrote: 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. I didn't think about this. Yes it would be possible to define the variable there. Heh yes perhaps their should be a variable to tell it to not generate a menu at all. -- 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

Juan Lang wrote: 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. 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

On Thu, Jul 16, 2009 at 11:25 AM, Juan Lang<juan.lang(a)gmail.com> wrote: 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. -- 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

Juan Lang wrote: 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. 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.