Okay, I'd like to start first by saying, awesome work on this project!
It's been a few years since I last tracked the progress of WINE on OS X, and
it's come on leaps and bounds as I can run most everything I've thrown
at it so far, with only minor issues here and there, which is a damned sight
better than VMWare Fusion or Parallels which have compatibility issues
everywhere, despite what they would have you believe!
Now, for OS X there isn't currently even a binary, but I've been
thinking about how much (or actually how little) would be required to have WINE
integrate that little bit more natively into OS X, and I've come up with a
few main points which might be nice if anyone is currently looking at building a
package, or would like to (I might give it a go myself if I find the time):
Default folder location
While I've coped with ~/.wine/ just fine so far, it's not that easily
accessible. I've ended up migrating the C: drive into a folder under
~/Documents/Virtual Machines where it's that bit easier to work with.
It's also not the most user-friendly place to dig around if you want to
recover files using Time Machine.
WINE as an App
While WINE obviously isn't really a .app friendly program, nor does it need
to be, it would be nice if it was. The compiled binaries should theoretically be
package-able as a .app with a minimum of fuss, such that a user could
double-click it to get a simple "hub" screen for configuring WINE, or
getting to recently used applications a little bit more quickly.
.exe files targeting WINE
With WINE as a .app, it would be possible to have .exe files double-clickable as
though they themselves were regular applications. This is currently possible
using a dummy-app; the way I've found to be simplest is a shell-script in an
automator .app, just open automator, create a new application workflow, and
throw the following into a shell task:
Code:
source ~/.profile
if test $# = 0
then
winefile C:
exit
fi
for f in "$@"
do
d=`dirname "$f"`
f=`basename "$f"`
cd "$d"
wine "$f" &
done
Not desperately elegant, but it does the job to a degree. A proper app would
certainly be nice for a more integrated feel, but at least the above serves as a
decent stop-gap. If you'd like to download such a dummy app (I made some
basic icons using the WINE glass icon) then you can grab mine here
(http://depositfiles.com/files/60qz7nsrp).
"Mount" the C: drive
This one I'm not sure on, but I'd like to be able to see my C:
"drive" appear in the devices list like an actual hard-drive. I've
no idea how to actually do this, so for the moment I'm just making do with a
symbolic link in the sidebar that points to my C: drive folder, and have given
it a suitable icon.
Start-menu
This could possibly be achieved as another feature of a wine .app; quite simply
a WINE .app package could add the ability for a start-menu style list on
right-click. This would likely require .lnk support, but the files don't
seem too complex.
Thoughts
It seems to me that the above major points may not actually be that complex, as
the main hurdles would be building WINE with a suitable .app "wrapper"
that can add the extra features ("hub" screen to avoid command-line,
file associations, start-menu-esque jumping off point). I may give this a go
myself, but I'm curious to know if anyone else has had a look at anything
like this, or if someone with a bit more experience at packaging unix/linux
programs into OS X .apps might be interested in having a go?
Hmm, is the ability to edit a post disabled? Anyway, I realised I missed one item off the list: Custom X11 Build Not exactly a big deal, but the main issue with WINE in OS X's X11 implementation at the moment is that X11 seems to force even full-screen applications to have a title-bar, which means you can never have a truly full-screen application. This produces various issues, such as requiring games to be played a resolution that accounts for the lost vertical space (otherwise it will extend off the bottom of the screen). The "full-screen mode" for X11 is also fairly lame even ignoring that issue, as all it does is trades the OS X menu-bar's screen real estate for only being able to use X11 or OS X, as it seizes both screens and blanks them out. It also seems to have a weird issue if you try to drag a window such that it fills up as much of the screen as possible, in that the window will end up snapping to about half-way down the screen. I'm really not sure what the options are when it comes to tweaking this however, it hopefully only requires a few patches to X11 (which I think is open source?), or changes in how WINE communicates with it, but it could require a lot more work. Fixing it up would certainly make for a far more seamless experience, but might be way more work than it's worth.
Haravikk wrote:> Okay, I'd like to start first by saying, awesome work on this project! It's been a few years since I last tracked the progress of WINE on OS X, and it's come on leaps and bounds as I can run most everything I've thrown at it so far, with only minor issues here and there, which is a damned sight better than VMWare Fusion or Parallels which have compatibility issues everywhere, despite what they would have you believe! > > Now, for OS X there isn't currently even a binary, but I've been thinking about how much (or actually how little) would be required to have WINE integrate that little bit more natively into OS X, and I've come up with a few main points which might be nice if anyone is currently looking at building a package, or would like to (I might give it a go myself if I find the time): > > Default folder location > While I've coped with ~/.wine/ just fine so far, it's not that easily accessible. I've ended up migrating the C: drive into a folder under ~/Documents/Virtual Machines where it's that bit easier to work with. It's also not the most user-friendly place to dig around if you want to recover files using Time Machine. > > WINE as an App >This is in progress with Mike Kronenberg's Wine Bottler and doh123's WineSkin. Neither of these will be accepted into the main Wine trunk because they both must use ObjC code.> .exe files targeting WINE >Actually, what you want is linkage between the Wine.app file and any PE exe on the system. The Wine.app's plist file should take care of this. WineHelper, a project from the defunct Darwine project did this.> Not desperately elegant, but it does the job to a degree. A proper app would certainly be nice for a more integrated feel, but at least the above serves as a decent stop-gap. If you'd like to download such a dummy app (I made some basic icons using the WINE glass icon) then you can grab mine here (http://depositfiles.com/files/60qz7nsrp). >There are ways on the Mac to do this more efficiently. See my comment above.> "Mount" the C: drive > This one I'm not sure on, but I'd like to be able to see my C: "drive" appear in the devices list like an actual hard-drive. I've no idea how to actually do this, so for the moment I'm just making do with a symbolic link in the sidebar that points to my C: drive folder, and have given it a suitable icon. >Why? Wine's files are kept in a 'hidden' directory and you can have more than one Wine Bottle (that is the technical term for the entire user directory structure.) Again, the two products mentioned above are trying to handle this in a user friendly way.> Start-menu > This could possibly be achieved as another feature of a wine .app; quite simply a WINE .app package could add the ability for a start-menu style list on right-click. This would likely require .lnk support, but the files don't seem too complex. > >This is entirely foreign to the Mac Aqua interface. What WineSkin does is way more Aqua friendly.> Thoughts > >Interesting. However, both Mac Users and Apple have become used to a specific way of doing things. Most of this is not "Mac Friendly" but more UNIXy than they like. James McKenzie> > > > >
Haravikk wrote:> > Now, for OS X there isn't currently even a binary, but I've been thinking about how much (or actually how little) would be required to have WINE integrate that little bit more natively into OS X, and I've come up with a few main points which might be nice if anyone is currently looking at building a package, or would like to (I might give it a go myself if I find the time): >well I make this easy in Wineskin (http://wineskin.doh123.com/). Wineskin has "Engines" which is a package of Xquartz and Wine and other needed things all bundled up... with easy mpkg installers to install. The problems come around with changing Xquartz versions and having to rebuild Wine versions to match up 100%. Technically I could edit the compiled dylds and change where they are looking for some things, but I like keeping things "clean" I tried making mpkg installers one time for OSX 10.5 and 10.6 to install Wine, and it worked sort of, but was still all command line wine usage. Its easier and better to just install Xcode and Macports if you want command line Wine. Haravikk wrote:> > Default folder location > While I've coped with ~/.wine/ just fine so far, it's not that easily accessible. I've ended up migrating the C: drive into a folder under ~/Documents/Virtual Machines where it's that bit easier to work with. It's also not the most user-friendly place to dig around if you want to recover files using Time Machine. >put the wineprefix anywhere you want... its all command line sure, but you can have as many as you want, anywhere you want. In Wineskin I have things installed in wrappers, which include the whole wineprefix inside. I think WineBottler does something similar. Haravikk wrote:> > WINE as an App > While WINE obviously isn't really a .app friendly program, nor does it need to be, it would be nice if it was. The compiled binaries should theoretically be package-able as a .app with a minimum of fuss, such that a user could double-click it to get a simple "hub" screen for configuring WINE, or getting to recently used applications a little bit more quickly. >not sure that sounds like a good idea. If anything make it more like it works on Linux. When you install something, it makes shortcut links for you in /Applications you can double click to run.... it would just have to package them up as a .app, which is very simple. Haravikk wrote:> > .exe files targeting WINE > With WINE as a .app, it would be possible to have .exe files double-clickable as though they themselves were regular applications. This is currently possible using a dummy-app; the way I've found to be simplest is a shell-script in an automator .app, just open automator, create a new application workflow, and throw the following into a shell task: > > Not desperately elegant, but it does the job to a degree. A proper app would certainly be nice for a more integrated feel, but at least the above serves as a decent stop-gap. If you'd like to download such a dummy app (I made some basic icons using the WINE glass icon) then you can grab mine here (http://depositfiles.com/files/60qz7nsrp). >Thats is very un-mac like. Most Mac users want a mac like experience. Everything should be stores inside of a .app and hidden from normal view. no folders and just double clicking a .exe like Windows. Haravikk wrote:> > "Mount" the C: drive > This one I'm not sure on, but I'd like to be able to see my C: "drive" appear in the devices list like an actual hard-drive. I've no idea how to actually do this, so for the moment I'm just making do with a symbolic link in the sidebar that points to my C: drive folder, and have given it a suitable icon. >The C drive is just a folder... you don't need to mount it as a drive... its not a drive. If you use many Wineprefixes they all have their own C drives.... it could get confusing. Haravikk wrote:> > Start-menu > This could possibly be achieved as another feature of a wine .app; quite simply a WINE .app package could add the ability for a start-menu style list on right-click. This would likely require .lnk support, but the files don't seem too complex. >not very Mac like again. Better to make a Wine folder of shortcut .app launchers in a folder and have that folder stuck on the dock so it can pop up and give the list.... it would mesh with the OS better.... and you could add some to the main Dock as single apps too. Haravikk wrote:> Custom X11 Build > Not exactly a big deal, but the main issue with WINE in OS X's X11 implementation at the moment is that X11 seems to force even full-screen applications to have a title-bar, which means you can never have a truly full-screen application. This produces various issues, such as requiring games to be played a resolution that accounts for the lost vertical space (otherwise it will extend off the bottom of the screen). >Xquartz is missing features. The main problem is that is has no RANDR extension... we need to get somebody to write one and submit it for approval and get it in Xquartz. its been on the request list at Xquartz for over 2.5 years. Xquartz did add a fullscreen option. It basically blanks out the screen covering up the top bar and dock. This is sort of nice, but without RANDR, Wine things will still error trying to change resolutions. Wine works great for programs that run in windows, but for fullscreen use, you are stuck with using a virtual desktop. I have some work arounds to this in Wineskin. It has a mostly usable fullscreen mode for gaming... and even handles changing resolutions to a degree. Without RANDR though it'll never be super. Haravikk wrote:> > I'm really not sure what the options are when it comes to tweaking this however, it hopefully only requires a few patches to X11 (which I think is open source?), or changes in how WINE communicates with it, but it could require a lot more work. Fixing it up would certainly make for a far more seamless experience, but might be way more work than it's worth.Xquartz is open source... http://xquartz.macosforge.org. If you know anyone that can add really good RANDR support into it, that would be fantastic. If you know anyone that can get it just rigged to handle RANDR in the way Wine needs it, but not good enough for a full release... let me know, I'd love that source for Wineskin. We could also throw together a WineX11.app built with a xterm thats only good for Wine usage.
Ken Thomases wrote:> On Apr 25, 2010, at 7:39 PM, James Mckenzie wrote: > Whoa! No, no patent. I'm quite dubious that proper full-screen support in X11 would be patentable even if we were so inclined. > > Other than copyright on our actual implementation, there's no legal impediment to somebody else implementing the same capability. I've even cooperated some with the maintainer of Apple's X11 and XQuartz to share our implementation. The problem is that our approach is applicable to our use case, but not to a general-purpose X server. > > Also, our product is called CrossOver Mac, or just CrossOver. There's no "4" in there. ;) Aside from that, thanks for the plug! > > Cheers, > KenI'd love the source to your X server.... I only use X for Wine anyways :-) I'd be drooling over that for a long time...