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.
