winequartz.drv Mac OS X UI discontinued?

[Mike Kronenberg]

On 06.07.2009, at 06:13, James McKenzie wrote:

> Adam Strzelecki wrote:
>>> I googled a bit more.  There are at least two ways of achieving this
>>> mentioned in the docs of libFoundation: by using XML-RPC call and by
>>> wrapping classes in ANSI-C APIs. [4]
>>>
>>
>> Well actually you can easily access all Obj-C features trough the
>> following pure C API:
>> http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html
>>
>>
> Adam:
>
> Is this still true?  I would like to convert what work we do have  
> into c
> level code so that it will pass AJs 'c' scan and to avoid using ObjC  
> code.
>
> In addition, if an exported Carbon/Cocoa library exists, this would  
> help
> move the project along.
>
> James McKenzie

Hi James,

I think You don't need any ObjC at all to replace X11. Apples modern  
CoreGraphics API is mostly C. And OpenGL can be accessed in C anyway.  
There is also a C API for the window manager. I do a lot of CG  
programming, if you have a task for me, just drop a line ;)

There is a drawback with CG or OpenGL with Apples current APIs:  
Manipulating individual pixels live in the screenbuffer. This was fast  
& possible with the old (now depreciated & partly defunct) QuickDraw  
API.
With Apple window server, based fully on Quartz, this API is of no use  
now, as the underlaying system is already fully OpenGL. The once  
direct access to the fb is now just as you would manipulate a texture  
and flush it to the viewport in OpenGL. We did a lot of testing on  
this topic when we changed the qemu vga output from QuickDraw to  
OpenGL/Quartz on OS X. We finally changed the whole output to OpenGL,  
as it was the fastest and most compatible with the future freely  
scaleable UI ideas of Apple (and others ;).

This way, all 2d pixelmanipulation is taking place in a texture and if  
it comes to 3d, half of the environment is already set.

Mike