winequartz.drv Mac OS X UI discontinued?

[Rolf Kalbermatter]

Chris Robinson [mailto:chris.kcat at gmail.com] 
> On Tuesday 14 July 2009 7:26:39 am Adam Strzelecki wrote:
>> Look, anyway Obj-C is supposed to be used in Wine only for Mac 
>> support, and not for anything else. Any developer that knows how
>> to program Mac knows Obj-C so there's nothing wrong with 
>> constraint that only developers that know Obj-C can work on it,
>> because those are guys that know how to program Mac.
> 
> Except you don't *need* Obj-C to code on Mac. The regular C 
> code for X11 works, too. Granted, using Apple's X 
> implementation isn't very optimal, but it does work. Sticking 
> with C allows all those developers to code "for Mac" as well, 
> with no Obj-C knowledge needed.

I see the same issue here. Rather few Mac users are programming
themselves and not every Mac program is created using Obj-C. So
the already small coder base is divided up even more in Obj-C and
non Obj-C programmers. This means there will be even much less
developers interested to work on Wine Obj-C code.
And while an Obj-C programmer can understand and fix standard C
code this same thing can not be said about the reverse. From what
I have seen about Obj-C code I saw little resemblence with C and
it could for my feeling have been Lisp, Smalltalk or any other
programming language I have no clue about.

I've been programming a little for Macs in the past. Nothing serious
but simply porting some existing (standard C) library code and the
bindings to a platform independent programming language we use here.
It was all standard C and it worked but it was not doing GUI (the
platform independent programming language is used for all GUI related
things). So I can't say if doing GUI on OSX without Obj-C is feasable.
(I do think that the programming environment we use does use little if
any Obj-C itself since its origins are from pre OS-X days and I doubt
they changed the entire graphic interface code completely when
introducing the OS-X support. They do however use an internal architecture
where they have so called interface code that is platform dependant to
provide an internal common API and the entire rest of the system is
programmed almost completely platform independent in C and in more
recent years mostly C++.)

I do know that the Mac API is certainly a very different API to deal
with compared to Windows. There are all kinds of remainders from the
old Classic Mac OS showing through and with every new version some of
those APIs get depreciated but sometimes there is no obvious or even
non-obvious way to do non-standard things without using those APIs.

So I do see a good reason to request Wine code being standard C (Yes,
I haven't gotten befriended with C++ either so far eventhough I attended
some courses and can understand it to some degree.)

Those pushing for a better integration with Wine on OS-X should maybe
first come up with a good design that limits the Obj-C code to an absolute
minimum and create a working proof of concept outside of the project.
And going that route may even show that the actual C to Obj-C bindings
are really the smallest part of the work and that writing a good graphics
driver is actually hard to do both in C and Obj-C. But when done in C many
more people in the Wine project can participate even if they do not know
much about the Mac API.

Rolf Kalbermatter