Re: Function completion for GVariant maybe types?

[Markus Elfring <Markus Elfring web de>]

> 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?

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