I see the same issue here. Rather few Mac users are programming
themselves and not every Mac program is created using Obj-C.
Have a look at: http://osx.iusethis.com/
There're really plenty of Mac applications and plenty of Mac developers.
And all because of there're many great publications and tutorials on
Mac programming.
I can even right a thesis that there may be more Cocoa/Obj-C
programmers than pure X11 programmers around the world.
But in general you are right. For services, console tools you don't
need to even know that such thing as Obj-C exists.
But in case of GUI applications released nowadays for Mac, most of
them are Obj-C/Cocoa, rest are QT, wxWidgets, Java.
I don't think anybody now releases Carbon (OSX C API) based app.
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.
That's it. Mac minus GUI is regular Unix (full POSIX compatible)
system, that's why it can easily run all popular (in Linux)
WebServers, console tools, etc.
Again not every Linux/Unix programmer is X11 programmer and can fix &
dig inside Wine X11 video driver.
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.
Hmmm? Isn't it what winequartz.drv is about? (Which is a subject of
this discussion)
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.
How do you imagine anybody digging in some OS related code without
having no freaking idea about its API?
It would be better if Wine went into a direction of decoupling video,
font and audio drivers completely from its core. AFAIK winequartz
except the driver DLL itself has to do quite many modifications (apply
patches) in Wine core itself in order to run, which is pretty bad. And
requires updating anytime someone updates Wine sources.
I can imagine having X11, OSX or maybe even DirectFB drivers as
completely interchangeable backends for Wine that can live their life
inside official releases or outside. But right Wine doesn't provide
such interface since it is too much coupled with X11, FreeType, so
Emmanuel (or any future maintainer) has to update winequartz.drv all
the time to follow official modifications.
Regards,
--
Adam | nanoant.com
