CogLauncher should probably not be a GApplication

[elima]

Right now, CogLauncher inherits from GApplication, which is convenient for Cog because it moves all the useful logic into libcogcore, simplifying the actual program and make it play well on Freedesktop.org systems.

However, in platforms where the features brought in by GApplication are not needed, this inheritance becomes a problem, making libcogcore less flexible to systems outside Freedesktop.org.

The solution would be making CogLauncher not inherit from GApplication, and implement the GApplication logic in cog.c instead.

[aperezdc]

This idea has been in my head as well, because it forces uses of libcogcore to have a GApplication even if a particular application does not want one or cannot use one for some reason. What I would do is:

• Split the functionality that is independent from GApplication out of CogLauncher into a new class, let's say CogView (if somebody can think of a better name, I'm all ears).
• Move plug-in handling into the new CogView class. This way code that uses libcogcore does not need to duplicate code that now lives in cog.c.
• Keep the CogLauncher class around, but make it use the new CogView class.

I like the idea of keeping a basic GApplication subclass around, because for cases where using it can be used it will avoid third party developers having to write a good chunk of non-trivial code. One of my mental goals in this regard is that writing a very basic launcher using libcogcore should be possible in under <500 LOC (currently cog.c is 368 LOC).