Re: Ige-mac-integration: New version with Cocoa interface available.

[John Ralls <jralls ceridwen us>]

On May 18, 2010, at 7:34 AM, Nicolas Dufresne wrote:

> Le mardi 18 mai 2010 à 09:26 -0400, Matthias Clasen a écrit :
>> 
>> Not really. Its up to you and us working together on making this
>> happen... therefore, I'd love to hear some comments from you or other
>> OS X developers on the GApplication branch:
> Maybe a first step would be to make the GApplication an extension point. This way you could abstract the system application machinery. Not only OSX but also Hildon and any custom application manager that may be required on specialized devices like phone, setup-box, refrigerator, etc.

We really need a mapping of what each platform uses its application object for (on those platforms that have one) so that we can abstract the common uses into a derivable object. We could of course start by just having a stub class with no attributes or methods and each platform can derive from that a class that does what that platform needs. After a few months (maybe as long as a year or more, depending on how quickly the subclasses get written) we can look at them and work out a common interface to pull back into the superclass. Unfortunately that will lead to some of the subclasses having to change their APIs, which will be annoying to anyone who's been actually using those classes in application ports.

Perhaps a better approach is to start a GApplication page on GnomeLive and catalog what each platform's application class does and work out an interface from the common elements we find there.

I also think it's worthwhile to maintain the separation between GLib and Gtk with respect to graphical elements like menus. In the case of the features in GtkOSXApplication, the menu and dock manipulations belong in a GtkApplication-derived class, while bundle functions, notifications (sort of an IPC gsignal), and events (another sort of IPC gsignal) belong in a GApplication-derived class. 

Regards,
John Ralls