Greater OS X integration

[Haravikk]

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: Select all

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.

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

[Haravikk]

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.

[James McKenzie]

Haravikk wrote:

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

This already exists. It is called CrossOver4Mac. Until CodeWeavers
releases the custom code they use, it would be a futile effort to
duplicate it, as I suspect that they have a patent, a very powerful
legal tool that is theirs to use.

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.

The problem here is not that X11 does not support it, it is that
Apple/XQuartz implementation is broken. This is not something that Wine
can or should fix.

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.

The problem is that we really, really need a native interface, not the
broken X11 one. There was work started on this, on several occassions.
The difficulty with this is that Wine MUST build on all platforms
without errors in testing. I have suggested using the same method that
OpenOffice.org used to integrate the interface in OO.org 3.0 and up on
the Mac. I will advise that this took MAN-DECADES to get to the state
it is in. I know most of the players that did this and they are NOT
willing to do this for another project.


And yes, edits are disabled. The forums feed a mailing list and the
edits are not fed through.

James McKenzie

[James McKenzie]

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

[doh123]

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

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.

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.

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

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.

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

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.

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.

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]

On Apr 25, 2010, at 7:39 PM, James Mckenzie wrote:

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

This already exists. It is called CrossOver4Mac. Until CodeWeavers releases the custom code they use, it would be a futile effort to duplicate it, as I suspect that they have a patent, a very powerful legal tool that is theirs to use.

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

[doh123]

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

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

[Billy T]

I've also just been evaluating Wine on Mac OS X - and in fact last week downloaded the very nice WineSkin and WineBottler incarnations. No real complaints yet

Actually there is one thing I haven't got figured out yet - not sure if it is meant to work or still a bug on Mac. That is, I want to open URLs in the host browser (ie Safari on the Mac OS). I've tried a number of things but don't seem to be able to get it working.

Otherwise, good work on those two Mac 'packagers'! And of course CrossOver!