Re: Function completion for GVariant maybe types?

[Tristan Van Berkom <tvb gnome org>]

On Thu, Feb 21, 2013 at 7:05 PM, Markus Elfring <Markus Elfring web de> wrote:
> > Until a couple of days ago I'd never even encountered GVariant so forgive me
> > if I've misunderstood the concept - but from what you've written, it seems
> > like you want to be able to map a nullable object to the state of a checkbox
> > for some reason.
>
> Yes, that is right.
>
> I give a bit more background information so that you can better understand the
> "history" for this issue.
>
>
> 1. I started to adjust the application "GParted" a while ago.
>
> 2. I added a Gtk::TreeModelColumn attribute.
>
> 3. I noticed that such model classes could not be marked to contain "nothing".
> How should "unknown" or "indeterminate" items be represented then?

Perhaps here (at step 3) is where you should pursue a different method,
since the immutable GVariant all by itself is clearly not suitable for your
purpose (and convincing glib maintainers to make it mutable is not going
to work, as it opens up a whole new problem space for glib which is
most likely unneeded, remember that adding features costs maintenance
in the long term, and a smaller API suited for specific purposes can be
more maintainable without being less powerful - less is more).

In other words, perhaps you should simply create your own GObject
type in the GParted code, which would in turn own a nullable but
immutable GVariant type property.

This will allow you to use your own GType as a GtkTreeModel column type,
at the same time allowing you to modify the actual GVariant that your
type owns (by replacing it with another GVariant, if need be).

Cheers,
            -Tristan

> 4. I moved from the abstraction level "C++ glibmm" to "C glib" to add the
> missing feature.
>
> 5. I wrote the prototype function "g_variant_new_nothing_from_type" according to
> my imaginations.
>
> 6. I do not like its implementation detail to call the function
> "g_variant_get_child_value" if I would only like to extract/inspect a data type
> and not to copy a complete value.
>
> 7. I try to improve this situation.
>
>
> > So GVariant doesn't seem to be a suitable type for mapping the state of
> > something whose state can change.
>
> Your conclusion is wrong. - I suggest to read a bit more about the concept of
> "immutable objects".
> http://en.wikipedia.org/wiki/Immutable_object
>
> A new object can always be created from a previous one which represents a
> read-only status.
>
>
> > Could that be why there's so much reluctance to implement what you want?
>
> No. - I see various factors like the following that result in usual challenges
> for my feature request.
>
> - I dare to fiddle with nullable data types and their mappings in different
> programming interfaces.
>
> - I try to gather attention from potentially interested parties like software
> developers.
>
> - I need to convince corresponding library maintainers to get the desired
> functionality added.
>
>
> Would you like to contribute any more suggestions to improve the involved
> communication?
>
> Regards,
> Markus
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list