GObject Introspection support for GSList or other types without a GLib type

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

GObject Introspection support for GSList or other types without a GLib type

Daniel Espinosa Ortiz
How to handle data types without a GLib GType defined.

On libgda, it define a GType for GError and a GSList becouse these doesn't exist on GLib and it uses them as parameters when creating properties and events.

For now may be the library (as Anjuta does) must create its own GType definition but with the following rule: the name of the type must be defined as "GError" and "GSList", in order to allow g-ri-scanner to detects the currect types GError and GSList as the example.

In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with "GdaError" and "GdaSList", then the scanner tries to find a definition to GdaError and GdaSList but they don't exist, when changed this types' names as avobe the correct type is detected.


Filed with the Bug #585707



Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)

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

Re: GObject Introspection support for GSList or other types without a GLib type

Tim-Philipp Müller
On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:

> On libgda, it define a GType for GError and a GSList becouse these
> doesn't exist on GLib and it uses them as parameters when creating
> properties and events.

Great, another library that registers its own GError boxed type. I think
I've lost count now. Any chance we could get a boxed type for GError in
GLib after all? (see bugs #300610 and #337092)

 Cheers
  -Tim


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

Re: GObject Introspection support for GSList or other types without a GLib type

Owen Taylor
In reply to this post by Daniel Espinosa Ortiz
On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:

> How to handle data types without a GLib GType defined.
>
> On libgda, it define a GType for GError and a GSList becouse these
> doesn't exist on GLib and it uses them as parameters when creating
> properties and events.
>
> For now may be the library (as Anjuta does) must create its own GType
> definition but with the following rule: the name of the type must be
> defined as "GError" and "GSList", in order to allow g-ri-scanner to
> detects the currect types GError and GSList as the example.
>
> In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with "GdaError" and
> "GdaSList", then the scanner tries to find a definition to GdaError
> and GdaSList but they don't exist, when changed this types' names as
> avobe the correct type is detected.

To point out what may be obvious - there is zero advantage of a
<X>_TYPE_SLIST over G_TYPE_POINTER.

This is true in general, and true for gobject-introspection - if
gobject-introspection finds a property by introspection and deduces a
type of GSList for it, it still doesn't have the element-type.

- Owen


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

Re: GObject Introspection support for GSList or other types without a GLib type

Daniel Espinosa Ortiz
That's true, but is there any data type check when g_object_set/get function is called?

If GLib plans to use G_TYPE_POINTER for GSList, GError, gshort, and any other data type without G_TYPE* macro defined, then just tell it on the documentation: "if you (programer) want to use a not defined type use G_TYPE_POINTER on properties declaration".

If documented or the better practice is stablished, some projects like Anjuta doesn't need to define a G_TYPE_ERROR from him self.

2009/6/17 Owen Taylor <[hidden email]>
On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:
> How to handle data types without a GLib GType defined.
>
> On libgda, it define a GType for GError and a GSList becouse these
> doesn't exist on GLib and it uses them as parameters when creating
> properties and events.
>
> For now may be the library (as Anjuta does) must create its own GType
> definition but with the following rule: the name of the type must be
> defined as "GError" and "GSList", in order to allow g-ri-scanner to
> detects the currect types GError and GSList as the example.
>
> In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with "GdaError" and
> "GdaSList", then the scanner tries to find a definition to GdaError
> and GdaSList but they don't exist, when changed this types' names as
> avobe the correct type is detected.

To point out what may be obvious - there is zero advantage of a
<X>_TYPE_SLIST over G_TYPE_POINTER.

This is true in general, and true for gobject-introspection - if
gobject-introspection finds a property by introspection and deduces a
type of GSList for it, it still doesn't have the element-type.

- Owen





--
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)

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

Re: GObject Introspection support for GSList or other types without a GLib type

Owen Taylor
On Sun, 2009-06-21 at 19:33 -0500, Daniel Espinosa wrote:

> That's true, but is there any data type check when g_object_set/get
> function is called?
>
> If GLib plans to use G_TYPE_POINTER for GSList, GError, gshort, and
> any other data type without G_TYPE* macro defined, then just tell it
> on the documentation: "if you (programer) want to use a not defined
> type use G_TYPE_POINTER on properties declaration".
>
> If documented or the better practice is stablished, some projects like
> Anjuta doesn't need to define a G_TYPE_ERROR from him self.

You are misunderstanding my comment.

I'm talking in *particular* about GSList. Well and GList, GHashTable and
other container types.

Without parameterized types (a list of what?) G_TYPE_SLIST is useless.

- Owen

> 2009/6/17 Owen Taylor <[hidden email]>
>         On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:
>         > How to handle data types without a GLib GType defined.
>         >
>         > On libgda, it define a GType for GError and a GSList becouse
>         these
>         > doesn't exist on GLib and it uses them as parameters when
>         creating
>         > properties and events.
>         >
>         > For now may be the library (as Anjuta does) must create its
>         own GType
>         > definition but with the following rule: the name of the type
>         must be
>         > defined as "GError" and "GSList", in order to allow
>         g-ri-scanner to
>         > detects the currect types GError and GSList as the example.
>         >
>         > In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with
>         "GdaError" and
>         > "GdaSList", then the scanner tries to find a definition to
>         GdaError
>         > and GdaSList but they don't exist, when changed this types'
>         names as
>         > avobe the correct type is detected.
>        
>        
>         To point out what may be obvious - there is zero advantage of
>         a
>         <X>_TYPE_SLIST over G_TYPE_POINTER.
>        
>         This is true in general, and true for gobject-introspection -
>         if
>         gobject-introspection finds a property by introspection and
>         deduces a
>         type of GSList for it, it still doesn't have the element-type.
>        
>         - Owen
>        
>        
>
>
>
> --
> Trabajar, la mejor arma para tu superación
> "de grano en grano, se hace la arena" (R) (en trámite, pero para los
> cuates: LIBRE)

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