Getting GValue* from Glib::Value

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

Getting GValue* from Glib::Value

Gtkmm mailing list
Hi,

I have

Glib::Value<Foo> data;
data.init(Glib::Value<Foo>::value_type());

How can I get pure C GValue*? I need it to use with the C API.
data.gobj() returns C++ based type, which is not acceptable by C API. I
see protected gobject_ in the base class. Does it make sense to have an
API, e.g.  const GValue* Glib::ValueBase::get_gvalue() to fetch thepointer for underlying GValue?

Any other suggestion?
Thanks.

--
- Pavlo Solntsev
---------------------------------------------
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Sent from Evolution on GNU/Debian <www.debian.org>


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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list

What's wrong with Glib::ValueBase::gobj()? It returns a pointer to gobject_. What else do you want? How should your proposed Glib::ValueBase::get_gvalue() differ from Glib::ValueBase::gobj()?

On 2019-04-23 06:14, Pavlo Solntsev via gtkmm-list wrote:
Hi, 

I have 

Glib::Value<Foo> data;
data.init(Glib::Value<Foo>::value_type());

How can I get pure C GValue*? I need it to use with the C API.
data.gobj() returns C++ based type, which is not acceptable by C API. I
see protected gobject_ in the base class. Does it make sense to have an
API, e.g.  const GValue* Glib::ValueBase::get_gvalue() to fetch thepointer for underlying GValue? 

Any other suggestion? 
Thanks.


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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list
Thanks, Kjell. I missed that gobj() returns a pointer to gobject_.
However, the returned type is not a pure C gtype. Let me illustrate
this by example:

```
  Glib::Value<Glib::DateTime> data;

  data.init(data.value_type());

  const GValue *val = data.gobj();
  std::cout << "val type is " << G_VALUE_TYPE_NAME(val) << std::endl;

  GValue *val2 = g_new0(GValue, 1);
  g_value_init(val2, G_TYPE_DATE_TIME);
  std::cout << "val2 type is " << G_VALUE_TYPE_NAME(val2) << std::endl;

```
In stdout I see

```
val type is glibmm__CustomBoxed_N4Glib8DateTimeE
val2 type is GDateTime
```

I know that GDateTime is a boxed type and Glib::Value registers it own
type. If I use built-in type, e.g. int, I see the same type for C++ and
C parts. Basically, my question should be refined and tailed to the
conversion of C++ gtype (boxed equivalent) to the C-like gtype.

Thanks.


On Tue, 2019-04-23 at 10:46 +0200, Kjell Ahlstedt wrote:

> What's wrong with Glib::ValueBase::gobj()? It returns a pointer to
> gobject_. What else do you want? How should your proposed
> Glib::ValueBase::get_gvalue() differ from Glib::ValueBase::gobj()?
> On 2019-04-23 06:14, Pavlo Solntsev via gtkmm-list wrote:
> > Hi,
> >
> > I have
> >
> > Glib::Value<Foo> data;
> > data.init(Glib::Value<Foo>::value_type());
> >
> > How can I get pure C GValue*? I need it to use with the C API.
> > data.gobj() returns C++ based type, which is not acceptable by C
> > API. I
> > see protected gobject_ in the base class. Does it make sense to
> > have an
> > API, e.g.  const GValue* Glib::ValueBase::get_gvalue() to fetch
> > thepointer for underlying GValue?
> >
> > Any other suggestion?
> > Thanks.
> >

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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list

The description of Glib::ValueBase says

 * Glib::Value<> is specialized for almost any type used within the glibmm and gtkmm libraries.
 *
 * - Basic types like <tt>int</tt>, <tt>char</tt>, <tt>bool</tt>, etc., also <tt>void*</tt>.
 * - Glib::ustring and std::string.
 * - Pointers to classes derived from Glib::Object.
 * - Glib::RefPtr<> pointer types, which are assumed to be Glib::Object pointers.
 * - All flags and enum types used within the gtkmm libraries.
 *
 * If a type doesn't fit into any of these categories, then a generic
 * implementation for custom types will be used.

"Almost any type" does not include Glib::DateTime, unfortunately. And "All flags and enum types" is not quite right. There are some enum types, especailly in glibmm, without a Glib::Value specialization.

I think this Glib::Value<Glib::DateTime> specialization will work:

namespace Glib
{
template <>
class Value<Glib::DateTime> : public ValueBase_Boxed
{
public:
  using CppType = Glib::DateTime;
  using CType = GDateTime*;

  static GType value_type() { return G_TYPE_DATE_TIME; }

  void set(const CppType& data) { set_boxed(data.gobj()); }
  CppType get() const { return CppType(static_cast<CType>(get_boxed()), true); }
};
} // namespace Glib


On 2019-04-23 15:01, [hidden email] wrote:
Thanks, Kjell. I missed that gobj() returns a pointer to gobject_.
However, the returned type is not a pure C gtype. Let me illustrate
this by example:

```
  Glib::Value<Glib::DateTime> data;

  data.init(data.value_type());

  const GValue *val = data.gobj();
  std::cout << "val type is " << G_VALUE_TYPE_NAME(val) << std::endl;

  GValue *val2 = g_new0(GValue, 1);
  g_value_init(val2, G_TYPE_DATE_TIME);
  std::cout << "val2 type is " << G_VALUE_TYPE_NAME(val2) << std::endl;

```
In stdout I see

```
val type is glibmm__CustomBoxed_N4Glib8DateTimeE
val2 type is GDateTime
```

I know that GDateTime is a boxed type and Glib::Value registers it own
type. If I use built-in type, e.g. int, I see the same type for C++ and
C parts. Basically, my question should be refined and tailed to the
conversion of C++ gtype (boxed equivalent) to the C-like gtype. 

Thanks.

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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list
Thank you Kjell.

It works. Basically, the code you provided should be added to the
header (glibmm/value.h). Currently, GDateTime is not GObject-based. If
we switch GDateTime to GObject the situation will be simpler for mm.
For my problem, I will use code in my app. Does it make sense to add it
to the master (glibmm)? Or it is better change GDateTime
implementation.

Thanks.


On Wed, 2019-04-24 at 14:45 +0200, Kjell Ahlstedt wrote:

> The description of Glib::ValueBase says
>  * Glib::Value<> is specialized for almost any type used within the
> glibmm and gtkmm libraries.
>  *
>  * - Basic types like <tt>int</tt>, <tt>char</tt>, <tt>bool</tt>,
> etc., also <tt>void*</tt>.
>  * - Glib::ustring and std::string.
>  * - Pointers to classes derived from Glib::Object.
>  * - Glib::RefPtr<> pointer types, which are assumed to be
> Glib::Object pointers.
>  * - All flags and enum types used within the gtkmm libraries.
>  *
>  * If a type doesn't fit into any of these categories, then a generic
>  * implementation for custom types will be used.
> "Almost any type" does not include Glib::DateTime, unfortunately. And
> "All flags and enum types" is not quite right. There are some enum
> types, especailly in glibmm, without a Glib::Value specialization.
> I think this Glib::Value<Glib::DateTime> specialization will work:
> namespace Glib
> {
> template <>
> class Value<Glib::DateTime> : public ValueBase_Boxed
> {
> public:
>   using CppType = Glib::DateTime;
>   using CType = GDateTime*;
>
>   static GType value_type() { return G_TYPE_DATE_TIME; }
>
>   void set(const CppType& data) { set_boxed(data.gobj()); }
>   CppType get() const { return
> CppType(static_cast<CType>(get_boxed()), true); }
> };
> } // namespace Glib
>
> On 2019-04-23 15:01, [hidden email] wrote:
> > Thanks, Kjell. I missed that gobj() returns a pointer to gobject_.
> > However, the returned type is not a pure C gtype. Let me illustrate
> > this by example:
> >
> > ```
> >   Glib::Value<Glib::DateTime> data;
> >
> >   data.init(data.value_type());
> >
> >   const GValue *val = data.gobj();
> >   std::cout << "val type is " << G_VALUE_TYPE_NAME(val) <<
> > std::endl;
> >
> >   GValue *val2 = g_new0(GValue, 1);
> >   g_value_init(val2, G_TYPE_DATE_TIME);
> >   std::cout << "val2 type is " << G_VALUE_TYPE_NAME(val2) <<
> > std::endl;
> >
> > ```
> > In stdout I see
> >
> > ```
> > val type is glibmm__CustomBoxed_N4Glib8DateTimeE
> > val2 type is GDateTime
> > ```
> >
> > I know that GDateTime is a boxed type and Glib::Value registers it
> > own
> > type. If I use built-in type, e.g. int, I see the same type for C++
> > and
> > C parts. Basically, my question should be refined and tailed to the
> > conversion of C++ gtype (boxed equivalent) to the C-like gtype.
> >
> > Thanks.

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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list

Don't change GDateTime in glib because of Glib::Value<>.

Many boxed types get Glib::Value specializations almost automatically. Those that are wrapped as _CLASS_OPAQUE_COPYABLE don't. GDateTime is one of them. I'll either add the Glib::Value specialization manually to glibmm/datetime.h or make a more general fix in the _CLASS_OPAQUE_COPYABLE m4 macro.

For the time being I can fix something in the master branch. A fix in the glibmm-2.4 ABI series has to wait until glibmm 2.62.0. However I fix it, the fix will include added API and/or ABI.

On 2019-04-24 18:06, Pavlo Solntsev via gtkmm-list wrote:

Thank you Kjell.

It works. Basically, the code you provided should be added to the
header (glibmm/value.h). Currently, GDateTime is not GObject-based. If
we switch GDateTime to GObject the situation will be simpler for mm.
For my problem, I will use code in my app. Does it make sense to add it
to the master (glibmm)? Or it is better change GDateTime
implementation. 

Thanks.


On Wed, 2019-04-24 at 14:45 +0200, Kjell Ahlstedt wrote:
The description of Glib::ValueBase says
 * Glib::Value<> is specialized for almost any type used within the
glibmm and gtkmm libraries.
 *
 * - Basic types like <tt>int</tt>, <tt>char</tt>, <tt>bool</tt>,
etc., also <tt>void*</tt>.
 * - Glib::ustring and std::string.
 * - Pointers to classes derived from Glib::Object.
 * - Glib::RefPtr<> pointer types, which are assumed to be
Glib::Object pointers.
 * - All flags and enum types used within the gtkmm libraries.
 *
 * If a type doesn't fit into any of these categories, then a generic
 * implementation for custom types will be used. 
"Almost any type" does not include Glib::DateTime, unfortunately. And
"All flags and enum types" is not quite right. There are some enum
types, especailly in glibmm, without a Glib::Value specialization.
I think this Glib::Value<Glib::DateTime> specialization will work:
namespace Glib
{
template <>
class Value<Glib::DateTime> : public ValueBase_Boxed
{
public:
  using CppType = Glib::DateTime;
  using CType = GDateTime*;

  static GType value_type() { return G_TYPE_DATE_TIME; }

  void set(const CppType& data) { set_boxed(data.gobj()); }
  CppType get() const { return
CppType(static_cast<CType>(get_boxed()), true); }
};
} // namespace Glib


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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list
Glib maintainer also wants no change in the implementation of
GDateTime. I like your strategy. Thanks.


On Thu, 2019-04-25 at 13:55 +0200, Kjell Ahlstedt wrote:

> Don't change GDateTime in glib because of Glib::Value<>.
> Many boxed types get Glib::Value specializations almost
> automatically. Those that are wrapped as _CLASS_OPAQUE_COPYABLE
> don't. GDateTime is one of them. I'll either add the Glib::Value
> specialization manually to glibmm/datetime.h or make a more general
> fix in the _CLASS_OPAQUE_COPYABLE m4 macro.
> For the time being I can fix something in the master branch. A fix in
> the glibmm-2.4 ABI series has to wait until glibmm 2.62.0. However I
> fix it, the fix will include added API and/or ABI.
> On 2019-04-24 18:06, Pavlo Solntsev via gtkmm-list wrote:
> > Thank you Kjell.
> >
> > It works. Basically, the code you provided should be added to the
> > header (glibmm/value.h). Currently, GDateTime is not GObject-based.
> > If
> > we switch GDateTime to GObject the situation will be simpler for
> > mm.
> > For my problem, I will use code in my app. Does it make sense to
> > add it
> > to the master (glibmm)? Or it is better change GDateTime
> > implementation.
> >
> > Thanks.
> >
> >
> > On Wed, 2019-04-24 at 14:45 +0200, Kjell Ahlstedt wrote:
> > > The description of Glib::ValueBase says
> > >  * Glib::Value<> is specialized for almost any type used within
> > > the
> > > glibmm and gtkmm libraries.
> > >  *
> > >  * - Basic types like <tt>int</tt>, <tt>char</tt>, <tt>bool</tt>,
> > > etc., also <tt>void*</tt>.
> > >  * - Glib::ustring and std::string.
> > >  * - Pointers to classes derived from Glib::Object.
> > >  * - Glib::RefPtr<> pointer types, which are assumed to be
> > > Glib::Object pointers.
> > >  * - All flags and enum types used within the gtkmm libraries.
> > >  *
> > >  * If a type doesn't fit into any of these categories, then a
> > > generic
> > >  * implementation for custom types will be used.
> > > "Almost any type" does not include Glib::DateTime, unfortunately.
> > > And
> > > "All flags and enum types" is not quite right. There are some
> > > enum
> > > types, especailly in glibmm, without a Glib::Value
> > > specialization.
> > > I think this Glib::Value<Glib::DateTime> specialization will
> > > work:
> > > namespace Glib
> > > {
> > > template <>
> > > class Value<Glib::DateTime> : public ValueBase_Boxed
> > > {
> > > public:
> > >   using CppType = Glib::DateTime;
> > >   using CType = GDateTime*;
> > >
> > >   static GType value_type() { return G_TYPE_DATE_TIME; }
> > >
> > >   void set(const CppType& data) { set_boxed(data.gobj()); }
> > >   CppType get() const { return
> > > CppType(static_cast<CType>(get_boxed()), true); }
> > > };
> > > } // namespace Glib
> > >

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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list

I have fixed Glib::Checksum, DateTime and TimeZone in the master branch. These classes are now wrapped as _CLASS_BOXEDTYPE, which means they get Glib::Value specializations. I've also added TODO comments in the glibmm-2-60 branch. Hopefully, I remember to fix it there when glibmm 2.62.0 is released. That fix will not be identical to the one in the master branch. The master branch fix contains a (very small) change in the API (a changed default value in a method that very few users of glibmm will call directly from their own code).

On 2019-04-25 14:24, Pavlo Solntsev via gtkmm-list wrote:
Glib maintainer also wants no change in the implementation of
GDateTime. I like your strategy. Thanks.


On Thu, 2019-04-25 at 13:55 +0200, Kjell Ahlstedt wrote:
Don't change GDateTime in glib because of Glib::Value<>.
Many boxed types get Glib::Value specializations almost
automatically. Those that are wrapped as _CLASS_OPAQUE_COPYABLE
don't. GDateTime is one of them. I'll either add the Glib::Value
specialization manually to glibmm/datetime.h or make a more general
fix in the _CLASS_OPAQUE_COPYABLE m4 macro.
For the time being I can fix something in the master branch. A fix in
the glibmm-2.4 ABI series has to wait until glibmm 2.62.0. However I
fix it, the fix will include added API and/or ABI.
On 2019-04-24 18:06, Pavlo Solntsev via gtkmm-list wrote:


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

Re: Getting GValue* from Glib::Value

Gtkmm mailing list
Thanks for the update.

On Sat, 2019-04-27 at 09:35 +0200, Kjell Ahlstedt wrote:

> I have fixed Glib::Checksum, DateTime and TimeZone in the master
> branch. These classes are now wrapped as _CLASS_BOXEDTYPE, which
> means they get Glib::Value specializations. I've also added TODO
> comments in the glibmm-2-60 branch. Hopefully, I remember to fix it
> there when glibmm 2.62.0 is released. That fix will not be identical
> to the one in the master branch. The master branch fix contains a
> (very small) change in the API (a changed default value in a method
> that very few users of glibmm will call directly from their own
> code).
> On 2019-04-25 14:24, Pavlo Solntsev via gtkmm-list wrote:
> > Glib maintainer also wants no change in the implementation of
> > GDateTime. I like your strategy. Thanks.
> >
> >
> > On Thu, 2019-04-25 at 13:55 +0200, Kjell Ahlstedt wrote:
> > > Don't change GDateTime in glib because of Glib::Value<>.
> > > Many boxed types get Glib::Value specializations almost
> > > automatically. Those that are wrapped as _CLASS_OPAQUE_COPYABLE
> > > don't. GDateTime is one of them. I'll either add the Glib::Value
> > > specialization manually to glibmm/datetime.h or make a more
> > > general
> > > fix in the _CLASS_OPAQUE_COPYABLE m4 macro.
> > > For the time being I can fix something in the master branch. A
> > > fix in
> > > the glibmm-2.4 ABI series has to wait until glibmm 2.62.0.
> > > However I
> > > fix it, the fix will include added API and/or ABI.
> > > On 2019-04-24 18:06, Pavlo Solntsev via gtkmm-list wrote:
> >  

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