Catalog of GObject-specific design patterns?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Catalog of GObject-specific design patterns?

Sébastien Wilmet-2
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Catalog of GObject-specific design patterns?

Joël Krähemann-3
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 <[hidden email]> 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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Catalog of GObject-specific design patterns?

Arnaud
In reply to this post by Sébastien Wilmet-2
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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
LRN
Reply | Threaded
Open this post in threaded view
|

Re: Catalog of GObject-specific design patterns?

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/

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

0x8DADE9276759BA74.asc (3K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Catalog of GObject-specific design patterns?

Sébastien Wilmet-2
In reply to this post by Arnaud
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Catalog of GObject-specific design patterns?

Sébastien Wilmet-2
In reply to this post by Joël Krähemann-3
On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote:
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Catalog of GObject-specific design patterns?

Joël Krähemann-3
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 <[hidden email]> 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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Catalog of GObject-specific design patterns?

Sébastien Wilmet-2
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 <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list