Re: application class thoughts



On Mon, Apr 5, 2010 at 3:08 PM, Cody Russell <bratsche gnome org> wrote:
> On Mon, 2010-04-05 at 11:24 -0700, John Ralls wrote:
>> > But Carbon is deprecated anyway, right?  So if one were to try to
>> design
>> > support for all this into gtk 3.0, would it hurt to just ignore
>> Carbon
>> > and design for Cocoa?
>> >
>>
>> You're correct. A Cocoa-based mac integration library will be
>> available soon, and the older Carbon-based ige-mac-integration will be
>> deprecated in Gtk-OSX. I hope large chunks of the new integration code
>> will be able to migrate into Gtk+ 3.
>

> Do you have the new Cocoa-based code laying around somewhere I could see
> yet?

John may take some inspiration from my own version of this:

http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ext/gtkapplication_quartz.mm

related: the header for gtkapplication.h:

http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ext/gtkmm2ext/gtkapplication.h

(needless to say the X11 version is all just empty stubs)

the C++ wrapper:

http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ext/gtkmm2ext/application.h

(the signals there are what relay the backend events (e.g. apple
events like "Quit") up to my gtkmm application. the long term goal was
to actually implement these with gsignal within gtkapplication itself
and then have gtkmm wrap those signals in the same way that it
normally does)

--p


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]