Re: Catalog of GObject-specific design patterns?
- Date: Sun, 13 Aug 2017 13:20:14 +0200
- From: Joël Krähemann <jkraehemann@xxxxxxxxx>
- Subject: Re: Catalog of GObject-specific design patterns?
The AgsApplicationContext acts as a base entry point to your
application. It is an extensible singleton
where functions are added by interfaces.
In order to use libags-thread.so.0 you have to implement
AgsConcurrencyProvider provider in your application context.
Likewise for libags-audio.so.0 you have to implement
AgsConcurrencyProvider provider and AgsSoundProvider because
it depends on thread routines.
Both library use the very same base class but you can use
libags-thread.so.0 without ever knowing about audio. Here are
The advantage of having a application context is you can provide your
very own extensions and you just have to derivate
AgsApplicationContext and implement wished interfaces.
There is another interface in development AgsServiceProvider if you do
J2EE you might have seen such as using
AgsRecallFactory is an advanced factory pattern as you put in a string
you get a list of objects back. It does instantiate
AgsRecall sub-types you can view it as a kind of effect processor.
Managers are singletons, too. They usually keep track of objects. In
general you can add, remove and lookup objects of it.
It is really common to use hashmaps in its implementation.
On Sun, Aug 13, 2017 at 12:33 PM, Sébastien Wilmet <swilmet@xxxxxxxxx> wrote:
> On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote:
>> I use some patterns like:
>> Or having an application context:
> Can you describe a little those patterns? What are the intents?
>> But what GObject makes really special are it's properties and events.
> Yes for example the Observer design pattern is implemented in a simpler
> way with GObject signals. But the intent remains the same.
> gtk-devel-list mailing list
gtk-devel-list mailing list