wxDataViewCustomRenderer size not applied on wxGTK in some cases.

[dsa-t]

See a minimal example:

minimal.cpp.txt

LIB_TREE_RENDERER returns height 30 in GetSize(), but cells are not sized to height 30 in Render().
Instead, they seem to use height 16 (font: Ubuntu 10).

If DPI is changed in system settings (Appearance - Fonts - DPI - Custom DPI setting in Mint), then cells are updated to height 30, but only the ones that are visible.

If you scroll down, you can see other cells still with height 16.

wx is built with DEBUG_RENDER_EXTENTS on screenshots.

Expected is for all cells to have height 30.

Initial state:

After changing DPI:

Scroll down:

Platform and version information

• wxWidgets version you use: 3.2; master
• wxWidgets port you use: wxGTK
• OS and its version: Linux Mint 21.1
  • GTK version: 3.24.33-1ubuntu2
  • Which GDK backend is used: X11
  • Desktop environment : XFCE
  • Current theme: Mint-Y-Aqua

[vadz]

Thanks, I can indeed see this, will check.

[vadz]

First observations are that neither using wxDV_VARIABLE_LINE_HEIGHT nor calling SetRowHeight(30) help.

And looking at GTK code here

https://github.com/GNOME/gtk/blob/3e6fd55ee00d4209ce2f2af292829e4d6f674adc/gtk/gtkcellrenderer.c#L1419-L1423

it seems that it always uses the minimum of the height we return and its pre-computed height. I don't see how can we avoid this...

[dsa-t]

Maybe it's possible to override get_aligned_area similar to gtk_cell_renderer_text_get_aligned_area (gtkcellrenderertext.c)?

[vadz]

Thanks for the idea, I didn't know about this virtual function. But quickly testing this I see that get_aligned_area already gets cell_area with height of 16 and aligned_area must be inside it (if it isn't, GTK just asserts and kills the program).

Looking at GTK code more carefully, I see that the original height, limiting everything which happens afterwards, comes from gtk_tree_view_get_row_height() which, in turn, uses gtk_tree_view_get_expander_size() to compute it. Which is crazy because this means that we can only increase the row height by changing the expander size and while this does work, i.e. try putting

* {
  -GtkTreeView-expander-size: 30;
}

in your ~/.config/gtk-3.0/gtk.css, it looks very bad because the expander now takes 30px horizontally too.

I have really no idea how is this supposed to work. Does anyone know of a GTK application using GtkTreeView with bigger than default row height?

[dsa-t]

btw, the effect can be seen in KiCad sometimes (https://forum.kicad.info/t/symbol-chooser-text-is-only-shown-half-line-height/49677)

Even if we call SetRowHeight (https://gitlab.com/kicad/code/kicad/-/commit/c3af434741b9e7ca1bca440b466f1a8328d8283e)

[vadz]

Sorry, I still have no idea what to do about it. I'm starting to seriously consider stopping using the native control under GTK and using the generic version by default instead, notably because there is still no way to use the native one with many items and apparently never going to be.

It's still possible that I'm missing something because it seems incredible for such an important control to be so broken, but I have no idea what.

@paulcor What do you think of using the generic control in wxGTK by default?

[paulcor]

For our own application, we went to using the generic wxDataViewCtrl for all platforms. I don't remember all the issues, but for wxGTK, #17909 is a deal killer, and I believe there were several problems with the native wxOSX control as well.

this means that we can only increase the row height by changing the expander size

I don't know much about wxDataViewCtrl, but it seems like the renderer size does affect the row height, as can be seen with this change to the dataview sample:

diff --git a/samples/dataview/dataview.cpp b/samples/dataview/dataview.cpp
index c15f2b3ad4..0683fdb209 100644
--- a/samples/dataview/dataview.cpp
+++ b/samples/dataview/dataview.cpp
@@ -271,7 +271,7 @@ public:
 
     virtual wxSize GetSize() const override
     {
-        return GetView()->FromDIP(wxSize(60, 20));
+        return GetView()->FromDIP(wxSize(60, 60));
     }
 
     virtual bool SetValue( const wxVariant &value ) override

[vadz]

For me the deal breaker is #16680, this control simply can't be used with mailboxes containing 100,000 messages — when wxListCtrl or the generic version have no trouble whatsoever with it. I still have no idea how do other programs using GTK deal with showing big/"infinite" number of items in this control and I think that if we can't make this work, we should stop using it.

But, to return to this issue, you're right, changing the height does work. And now I'm extremely confused because I remember it not working for me, but not only it does in the sample now, but it also does in the provided example.

I'm testing with the latest master but there haven't been any changes affecting this since a very long time and yet I don't see the problem any more, neither with Wayland nor X11.

@dsa-t Do you still see it?

[dsa-t]

In 3.2.5, the provided minimal.cpp.txt still behaves the same for me.

With this in MyCustomRenderer in dataview, row heights are inconsistent:

    virtual wxSize GetSize() const wxOVERRIDE
    {
        return GetView()->FromDIP(wxSize(60, 30));
    }

Initial state:

After DPI change:

[dsa-t]

master branch behaves the same for me.