GLib bindings: key names

[mpranj]

Is there any reason why the GLib bindings make you extract a Key name using properties?
Most other functions are simple getters/setters, so I don't fully understand this decision. Seems inconsistent with the rest of the interface.

libelektra/src/bindings/glib/gelektra-key.c

Lines 28 to 45 in bb87100

	static void gelektra_key_get_property (GObject * object, guint property_id, GValue * value, GParamSpec * pspec)
	{
	GElektraKey * self = GELEKTRA_KEY (object);
	switch (property_id)
	{
	case PROP_KEY_NAME:
	g_value_set_string (value, keyName (self->key));
	break;
	case PROP_KEY_BASENAME:
	g_value_set_string (value, keyBaseName (self->key));
	break;
	default:
	/* We don't have any other property... */
	G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
	break;
	}
	}

If there is no specific reason, may I at least add a getter for convenience?

[markus2330]

Thank you for the question!

Can you make a proposal how the API should look like?

If there is no specific reason

@manuelm can you maybe answer this?

[mpranj]

You should not have access to the underlying data directly

This contradicts the implementation of gelektra_key_getvalue:

libelektra/src/bindings/glib/gelektra-key.c

Lines 360 to 363 in bb87100

	const void * gelektra_key_getvalue (const GElektraKey * key)
	{
	return keyValue (key->key);
	}

I do not understand why there are three different ways to access the:

1. name,
2. string value and
3. binary value

of a key.

It is inconsistent in itself. I can add a convenience layer on my side where I use it, but copying the data out also comes at the cost of performance.

[manuelm]

It's inconsistent if you look at this as a glib binding. But it was solely written to make GI bindings work. Glib bindings alone had no value for me. So every line in this file was written so bindings generate nicely.

If you want to understand why things were written that way, move git history back, try changing a line/a return value and see if the GI lua + python bindings still generate.

That said. You are free to change whatever you like without asking me as I don't use it anymore.

PS: There were more properties back in the days: basename, dirname, fullname, etc.

[mpranj]

Thank you for the answers!

It's inconsistent if you look at this as a glib binding. But it was solely written to make GI bindings work.

Sorry, this was the crucial part I was missing. I only looked at it as glib bindings.

You are free to change whatever you like without asking me as I don't use it anymore.

I didn't want to change an API without understanding why it was designed as is.

Since the GI bindings were deprecated and removed, I will just add what I need to the API.
The goal is to make the GSettings bindings work, and it looks like they are actually the only remaining user of the GLib bindings.

[markus2330]

Since the GI bindings were deprecated and removed, I will just add what I need to the API.
The goal is to make the GSettings bindings work, and it looks like they are actually the only remaining user of the GLib bindings.

Exactly, feel free to do as you see fit. The SWIG bindings are superior to the GI bindings. So if GI bindings do not generate anymore, please remove them.

[mpranj]

@markus2330 you removed the GI bindings more than a year ago 039b55b.