Quartz support is ofcourse great but without a patch it isn't very usefull ;)
Roderick Colenbrander
This patch includes a partially graphics driver for OS X. Everything except the basic window management functions of the user driver are stubs. The patch depends on Pierre d'Herbemont's "Support for disabling symbols import in WineBuild based on a prefix."
Changelog: Rib Rdb ribrdb@gmail.com Add preliminary support for native graphics on Mac OS X.
Roderick Colenbrander wrote:
Quartz support is ofcourse great but without a patch it isn't very usefull ;)
Is it? Given the complexity and amount of work done on the x11drv it seems silly to duplicate all that effort. The x11drv is worked on by the entire Wine development team right now, so any quartzdrv would always be playing catchup. Well, if they want to spend their time doing that, fine by me ...
Is it? Given the complexity and amount of work done on the x11drv it seems silly to duplicate all that effort. The x11drv is worked on by the entire Wine development team right now, so any quartzdrv would always be playing catchup. Well, if they want to spend their time doing that, fine by me ...
Well, by 'the entire Wine development team' you mean Alexandre :-) ?
I, for one, am happy that people are using our driver model to write new drivers as it could serve as a proof of concept that our driver model is sound (think about GL / Cairo / 'DBI engine' kind of drivers).... Heck, if we only wanted to support one driver, why do all the job of doing a clean separation and not include X11 in Wine's GDI directly ?
Lionel
Well, by 'the entire Wine development team' you mean Alexandre :-) ?
Not so, quite a few people work on the x11drv. For instance Alexs winedesktop work, various NETWM interop patches from me, fullscreening windows (not applied yet, but ...), system tray integration and so on. Plus all the work to make OpenGL/DirectX go of course! :)
I, for one, am happy that people are using our driver model to write new drivers as it could serve as a proof of concept that our driver model is sound (think about GL / Cairo / 'DBI engine' kind of drivers).... Heck, if we only wanted to support one driver, why do all the job of doing a clean separation and not include X11 in Wine's GDI directly ?
Well the driver model is lifted from Windows so I think it is sound. And as for why we use separate drivers, well, when the DLL separation is complete it means we can make a real Windows box display via X11 which is Just Plain Cool :)
It also allows for portability to operating systems that don't have X11. MacOS X *does* have X, in fact it's a modified XFree but with some proprietary bits added. So I'm thinking the added effort is not worth the gain. I'm not a Mac user though so who knows, maybe the extra native-ness is worth all the pain ....