Re: Catalog of GObject-specific design patterns?

2017-08-13 Thread Sébastien Wilmet
On Sun, Aug 13, 2017 at 01:20:14PM +0200, Joël Krähemann wrote:
> 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
> some implementations:
> 
> * AgsXorgApplicationContext
> * AgsAudioApplicationContext
> * AgsServerApplicationContext
> 
> 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
> Spring.
> 
> 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.

Now I better understand, thanks for the explanations.

--
Sébastien

> On Sun, Aug 13, 2017 at 12:33 PM, Sébastien Wilmet  wrote:
> > On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote:
> >> I use some patterns like:
> >>
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_recall_factory.h
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/plugin/ags_lv2_manager.h
> >> ...
> >>
> >> Or having an application context:
> >>
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/ags_xorg_application_context.h
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags_concurrency_provider.h
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_sound_provider.h
> >
> > Can you describe a little those patterns? What are the intents?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Catalog of GObject-specific design patterns?

2017-08-13 Thread Joël Krähemann
Hi,

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
some implementations:

* AgsXorgApplicationContext
* AgsAudioApplicationContext
* AgsServerApplicationContext

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
Spring.

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.

Bests,
Joël

On Sun, Aug 13, 2017 at 12:33 PM, Sébastien Wilmet  wrote:
> On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote:
>> I use some patterns like:
>>
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_recall_factory.h
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/plugin/ags_lv2_manager.h
>> ...
>>
>> Or having an application context:
>>
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/ags_xorg_application_context.h
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags_concurrency_provider.h
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_sound_provider.h
>
> 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.
>
> --
> Sébastien
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Catalog of GObject-specific design patterns?

2017-08-13 Thread Sébastien Wilmet
On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote:
> I use some patterns like:
> 
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_recall_factory.h
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/plugin/ags_lv2_manager.h
> ...
> 
> Or having an application context:
> 
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/ags_xorg_application_context.h
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags_concurrency_provider.h
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_sound_provider.h

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.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Catalog of GObject-specific design patterns?

2017-08-11 Thread Sébastien Wilmet
On Fri, Aug 11, 2017 at 09:16:32AM +0700, Arnaud wrote:
> As for using the `g_object_set_data()` like you do, it's something I
> always tried to stay away from, because it seems to me that everything
> becomes possible with that, and there's probably plenty of mistakes to
> be made ;) On the other hand, there must be some situations where it's
> the only solution. I'd be curious to know what the old-timers think
> about it, when to use it and when to avoid it.

A bad example in Devhelp:
https://git.gnome.org/browse/devhelp/tree/src/dh-window.c?h=3.25.2#n1357

The function creates a new tab and appends it to the GtkNotebook. vbox
is the content of the tab, which contains web_view and info_bar. In
other DhWindow functions, we have access to the GtkNotebook, but from
the GtkNotebook we have access only to the vbox. So with the vbox we can
call g_object_get_data() to get the web_view and info_bar.

This is a typical example where it is better to create a new class:
called for example DhTab, a subclass of GtkBox or GtkGrid. The web_view
and info_bar are simply stored as instance variables in DhTab. This
would also have the nice benefit to have less code in DhWindow, because
DhWindow would delegate some of its work to DhTab.

For other use-cases, creating a subclass is a too heavy solution, or
sometimes creating a subclass is even not possible/desirable as I
explained in my blog post.

An example where creating a subclass would be a too heavy solution: to
implement a context/right-click menu, attaching some information to menu
items, so when the ::activate signal is called we have the required info
to implement the action. For instance for spell-checking: the context
menu to choose another word:
https://git.gnome.org/browse/gspell/tree/gspell/gspell-context-menu.c?h=1.5.3#n258

> At last, I take this opportunity to share my bookmark post on GObject. I
> collected all the interesting bits I found on the Net while learning
> from zero, plus added some personal thoughts, and in the end it's just a
> mess, but learners might find interesting bits there, who knows.
> 
> https://github.com/elboulangero/goodvibes/wiki/GObject-Introduction

I've written also a small intro to GObject here:
https://people.gnome.org/~swilmet/glib-gtk-book/

But not how to subclass GObject, just how to *use* an existing GObject
class.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Catalog of GObject-specific design patterns?

2017-08-10 Thread LRN
On 8/11/2017 5:16 AM, Arnaud wrote:
> Hi Sébastien,
> 
> thx for this post ! I'm a newby with GObject, and I'm always happy to
> learn bits here and there.
> 
> As for using the `g_object_set_data()` like you do, it's something I
> always tried to stay away from, because it seems to me that everything
> becomes possible with that, and there's probably plenty of mistakes to
> be made ;) On the other hand, there must be some situations where it's
> the only solution. I'd be curious to know what the old-timers think
> about it, when to use it and when to avoid it.
> 


GTK+ uses g_object_set_data() (though usually in its g_object_set_data_full()
form) internally, a lot.


-- 
O< ascii ribbon - stop html email! - http://arc.pasp.de/


0x8DADE9276759BA74.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Catalog of GObject-specific design patterns?

2017-08-10 Thread Arnaud
Hi Sébastien,

thx for this post ! I'm a newby with GObject, and I'm always happy to
learn bits here and there.

As for using the `g_object_set_data()` like you do, it's something I
always tried to stay away from, because it seems to me that everything
becomes possible with that, and there's probably plenty of mistakes to
be made ;) On the other hand, there must be some situations where it's
the only solution. I'd be curious to know what the old-timers think
about it, when to use it and when to avoid it.

At last, I take this opportunity to share my bookmark post on GObject. I
collected all the interesting bits I found on the Net while learning
from zero, plus added some personal thoughts, and in the end it's just a
mess, but learners might find interesting bits there, who knows.

https://github.com/elboulangero/goodvibes/wiki/GObject-Introduction

Cheers,
Arnaud

On 08/10/2017 07:23 PM, Sébastien Wilmet wrote:
> Hi,
>
> I've documented my first GObject design pattern:
> https://blogs.gnome.org/swilmet/2017/08/09/gobject-design-pattern-attached-class-extension/
>
> Question to the old-timers: do you know any other GObject-specific
> design pattern? Not applying the classic design patterns with GObject,
> I'm talking here about new design patterns that use GObject features
> that are not necessarily present in other object systems.
>
> Or am I the first to write about a GObject-specific design pattern?
>
> Thanks,
> Sébastien
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Catalog of GObject-specific design patterns?

2017-08-10 Thread Joël Krähemann
Hi Sébastien,

I use some patterns like:

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_recall_factory.h
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/plugin/ags_lv2_manager.h
...

Or having an application context:

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/ags_xorg_application_context.h
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags_concurrency_provider.h
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_sound_provider.h

But what GObject makes really special are it's properties and events.


Bests,
Joël


On Thu, Aug 10, 2017 at 2:23 PM, Sébastien Wilmet  wrote:
> Hi,
>
> I've documented my first GObject design pattern:
> https://blogs.gnome.org/swilmet/2017/08/09/gobject-design-pattern-attached-class-extension/
>
> Question to the old-timers: do you know any other GObject-specific
> design pattern? Not applying the classic design patterns with GObject,
> I'm talking here about new design patterns that use GObject features
> that are not necessarily present in other object systems.
>
> Or am I the first to write about a GObject-specific design pattern?
>
> Thanks,
> Sébastien
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list