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

[John Ralls <jralls ceridwen us>]

On May 18, 2010, at 8:43 AM, Matthias Clasen wrote:

> On Tue, May 18, 2010 at 11:33 AM, John Ralls <jralls ceridwen us> wrote:
>> 
>> 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.
> 
> Its a little late for that, we need to land GApplication support very
> soon. Thats why I would love it you could look at the existing code.

OK.

It has some useful bits, and seems mostly harmless, but I don't think that it will get much use in its present form.

The action registry is a potentially useful piece of infrastructure, but it doesn't really go far enough to insulate the application developer from having to learn more than she wants to about each platform that she's targeting. She'll still have to have large sections of ifdef'd code catching the various signals from each operating system and invoking the actions, which will then emit signals that she'll have to connect to with her callbacks. She'd be ahead without it, because it's less work (and much faster) to just catch the OS signals and call the action function directly. I'd make the registry a separate class which GApplication could use to implement a common set of actions. Platform implementations would be required to provide the hookups for the standard signals, and could easily enough add platform-specific signals, as could application developers.

I don't think that there's much benefit to get_mainloop, run, and quit. If the event loop needs to be abstracted for a platform, that should be done in the platform's GMainLoop override. 

The multiple/single invocation feature is something OSX handles by setting a key in the app's Info.plist. I suppose on Linux you'd have to register a key with dbus to indicate that the app already had a running instance. Just quitting seems rude to the end user, though. On OSX, LaunchServices "activates" the running instance.

I haven't spent much time with gdbus (or dbus either, for that matter). Is there some magic that allows other compilation units to see the static functions in gunixapplication.c?

Regards,
John Ralls