matthiasm wrote:
> 
> On 14.10.2008, at 04:28, Michael Sweet wrote:
> 
>> matthiasm wrote:
>>>
>>> On 07.10.2008, at 10:13, Bill Spitzak wrote:
>>>
>>>> The fltk2 OSX version has had major rewrites to use Carbon correctly 
>>>> and
>>>> to stop using QuickDraw. You probably want to copy most/all of it if
>>>> possible.
>>>
>>>
>>> The urrent FLTK port for OS X should use Quartz and Cocoa exclusively
>>> and abandon QuickDraw and Carbon. But that is quite a challange and will
>>> require some time. In the mean time, I would like to abandon everything
>>> inside #ifdef __APPLE_QD__ ...
>>
>> Keep in mind that Carbon will still be required for processing events;
>> we can't use Cocoa because that is the Objective C API; short of
>> writing a custom subclass of NSView/NSWindow to manage all windows,
>> I'm not sure how we'd use Cocoa with FLTK...
> 
> 
> Yes, the Carbon code is divided in three sections: __APPLE__, 
> __APPLE_QD__, and __APPLE_QUARTZ__. The event handling and window 
> management is done in Carbon __APPLE__ segments. Removing what's inside 
> __APLE_QD__ will only remove QuickDraw drawing, not event handling.
> 
> Oh wait, the code is gone already ;-)
> 
> I do not know much about Cocoa, but what you write is exactly how  would 
> eventually do this - probably the only way. None of the Objective C has 
> to shine through to the FLTK API, right?

Right, although we'd need to expose the corresponding CoreGraphics
types.  In any case, I don't think using Cocoa will be required as
the C APIs for event handling, drawing, and window management are
all supported for 32- and 64-bit apps.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to