Sign up

Pango Font Descriptions, ListStores and Values

Today's problem that has me in a tizz…

I need to have a data model which I am storing in a subclass of gtk.ListStore with some string columns and a pango.PgFontDescription column. I have:

super([
   GType.STRING,
   GType.STRING,
   GType.STRING, 
   GType.STRING,
   PgFontDescription.getType,  // ColumnNumber.fontDescription
]);

This seems fine. I can even put a PgFontDescription object in with:

setValue(iter, ColumnNumber.fontDescription, fontDescription);

However I have no idea which version of ListStore.setValue is being used. In particular:

assert(Value.typeCompatible(PgFontDescription.getType, Value.getType));

always fails. The real problem I have is that:

auto object = model.getValue(iter, ColumnNumber.fontDescription);

returns but I have no idea how to get the actual PgFontDescription as:

assert(Value.typeCompatible(object.getType, PgFontDescription.getType));

fails. Clearly the setValue is not doing what I think it is doing,i.e. it is not creating a Value instance. Is it that fontDescription is actually being treated as an integer value?

Re: Pango Font Descriptions, ListStores and Values

On 9/7/18 8:19 PM, Russel Winder wrote:

This seems fine. I can even put a `PgFontDescription` object in with:

setValue(iter, ColumnNumber.fontDescription, fontDescription);

However I have no idea which version of `ListStore.setValue` is being used. In particular:

assert(Value.typeCompatible(PgFontDescription.getType, Value.getType));

always fails. The real problem I have is that:

auto object = model.getValue(iter, ColumnNumber.fontDescription);

returns but I have no idea how to get the actual `PgFontDescription` as:

assert(Value.typeCompatible(object.getType, PgFontDescription.getType));

fails. Clearly the `setValue` is not doing what I think it is doing,i.e. it is not creating a `Value` instance. Is it that `fontDescription` is actually being treated as an integer value?

Unfortunately there is currently no easy way to access the gType of the
thing contained in the Value as Value.getType or in this case
object.getType returns the GType of the Value its self.

The contained type is accessible in the C struct as a workaround:

object.getValueStruct().gType;

The actual setting of the value is handled by the gobject.Value
constructor:
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/gobject/Value.d#L86
So it's ultimately stored as a pointer.

We will need to ad a get template to Value to handle this properly,
but a pointer to the C version can be obtained with Value.getPointer.

Of course if you are using the FontDescription to change the font of a
row or cell you can use TreeViewCloumn.addAttribute to set the font
attribute of a CellRenderer.

column.addAttribute(aTextRenderer, "font-desc", 
ColumnNumber.fontDescription);

Re: Pango Font Descriptions, ListStores and Values

[…]
I shall delve into the suggestions, thanks for giving the pointers, most helpful.

Of course if you are using the FontDescription to change the font of a
row or cell you can use TreeViewCloumn.addAttribute to set the font
attribute of a CellRenderer.

column.addAttribute(aTextRenderer, "font-desc", 
ColumnNumber.fontDescription);

That is exactly what is happening in the code, well spotted. :-)

The problem is needing to change the FontDecription object to change the font size. In C++ it is easy to access things, gtkmm is hand constructed as a C++ API rather than being a GIR driven generated binding. With both Python and D, things are harder which seems to be a feature of the GIR-driven generated nature.

I have noticed though that my Python code is broken, I haven't got the D code working yet, but the C++ code doesn't amend the original FontDescription object as I thought, it makes a copy, amends, and then replaces the original.

Re: Pango Font Descriptions, ListStores and Values

On Fri, 7 Sep 2018 23:03:09 +0200, Mike Wey wrote:
[…]

Unfortunately there is currently no easy way to access the gType of the
thing contained in the Value as Value.getType or in this case
object.getType returns the GType of the Value its self.

The contained type is accessible in the C struct as a workaround:

object.getValueStruct().gType;

getValueStruct returns a GValue* which doesn't have a gType method or function. :-(

The actual setting of the value is handled by the gobject.Value
constructor:
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/gobject/Value.d#L86
So it's ultimately stored as a pointer.

We will need to ad a get template to Value to handle this properly,
but a pointer to the C version can be obtained with Value.getPointer.

[…]

I tried object.getPointer but get an exception that the contained value is not a pointer. So at the heart of my problem is what is being done with:

setValue(iter, ColumnNumber.fontDescription, fontDescription);

fontDescription is a variable of type PgFontDescription which is a class so fontDescription should be a reference to a heap allocated object. Is setValue definitely going to wrap that as a Value rather than an int? It certainly appears not to be wrapping an Object or a Pointer in the Value.

Apologies for seeming to drag this one out, I am not sure how to use the code to find out what is happening.

Re: Pango Font Descriptions, ListStores and Values

On 9/8/18 2:15 PM, Russel Winder wrote:

getValueStruct returns a GValue* which doesn't have a gType method or function. :-(

It does have a field named gType, witch is the one you want to use.

I tried object.getPointer but get an exception that the contained value is not a pointer. So at the heart of my problem is what is being done with:

setValue(iter, ColumnNumber.fontDescription, fontDescription);

fontDescription is a variable of type PgFontDescription which is a class so fontDescription should be a reference to a heap allocated object. Is setValue definitely going to wrap that as a Value rather than an int? It certainly appears not to be wrapping an Object or a Pointer in the Value.

Apologies for seeming to drag this one out, I am not sure how to use the code to find out what is happening.

It seems that the PgFontDescription is ultimately stored as a boxed type
since:

Type.isA(PgFontDescription.getType(), GType.BOXED)

returns true.

So for now you can use:

auto font = new 
PgFontDescription(cast(PangoFontDescription*)object.getBoxed());

to retrieve the Font description, and hopefully some time soon you can
use object.get!PgFontDescription().

Re: Pango Font Descriptions, ListStores and Values

On Sat, 8 Sep 2018 16:13:00 +0200, Mike Wey wrote:

On 9/8/18 2:15 PM, Russel Winder wrote:

getValueStruct returns a GValue* which doesn't have a gType method or function. :-(

It does have a field named gType, witch is the one you want to use.

I thought I had used .gType rather than .gType() on the "don't use () with nullary functions" style but maybe I didn't.

[…]

It seems that the PgFontDescription is ultimately stored as a boxed type
since:

Type.isA(PgFontDescription.getType(), GType.BOXED)

returns true.

So for now you can use:

auto font = new 
PgFontDescription(cast(PangoFontDescription*)object.getBoxed());

to retrieve the Font description, and hopefully some time soon you can
use object.get!PgFontDescription().

I didn't think of trying Boxed I should have done.

I think I feel ambivalent about the get template idea, it moves things from being GIR driven to being manual binding. Unless I am missing something.

Re: Pango Font Descriptions, ListStores and Values

auto object = model.getValue(iter, ColumnNumber.fontDescription).getBoxed(); // void*
assert(object !is null);
auto fontDescription = cast(PgFontDescription*)object;
assert(fontDescription !is null);
fontDescription.setSize(to!int(newSize * PANGO_SCALE));

Now results in a SIGSEGV on the last line. :-(

Re: Pango Font Descriptions, ListStores and Values

Wetware error again, it cannot spell.

Re: Pango Font Descriptions, ListStores and Values

On 9/11/18 9:47 AM, Russel Winder wrote:

I think I feel ambivalent about the get template idea, it moves things from being GIR driven to being manual binding. Unless I am missing something.

There is a trade off between minimizing manually added code and usability.

In this case first we the user no longer needs to know if the class they
want to use is stored as a object, a boxed type or a pointer.

And for boxed and pointer options the getBoxed and getPointer functions
return a pointer to the C struct and not the D class. Where you need to
instantiate the D class from the C pointer.

Luckily the getObject function already returns a ObjectG so the
boilerplate to handle the reference count correctly isn't needed.

Re: Pango Font Descriptions, ListStores and Values

[…]

There is a trade off between minimizing manually added code and usability.

Usability by programmers should clearly be the driving force. For me gtkmm doesn't really work despite being very C++. Python use of GTK+ is great since it presents as naturally Python. GtkD is part way between, far better than gtkmm, but not quite as intuitive as the Python binding.

The single biggest problem for GtkD use is that the API documentation is D signatures with C comments. I have no solution to suggest, only that this is the single biggest problem I have. The GtkD demos are useful for what they do but I am finding I am going beyond what they show and am therefore a bit "on my own" using guesswork. Your replies on this forum (even though I hate forums) keeps me sane, on the right track, and inching towards a D port of GFontBrowser that is far nicer to work with that the gtkmm one, and works better than the Python port. I will be retiring the C++ and Python versions, now leaving the D ones as the mainline.

In this case first we the user no longer needs to know if the class they
want to use is stored as a object, a boxed type or a pointer.

And for boxed and pointer options the getBoxed and getPointer functions
return a pointer to the C struct and not the D class. Where you need to
instantiate the D class from the C pointer.

Now that I have working code, this all makes sense. Sadly it took me a while to get there, mostly because I misread your code fragment above – totally my fault. If I had read it correctly in the first place, success would have been swifter.

I would though still have to admit to a slight confusion between 'Boxed' and 'Pointer' in this context.

Luckily the getObject function already returns a ObjectG so the
boilerplate to handle the reference count correctly isn't needed.

GTK+ doesn't seem to handle 'Object', 'Boxed', and 'Pointer' in a way that is intuitive.