set minimum content height for history selective copy dialog

[zisoft]

I think @dterrahe has accidantally deleted the line for setting the minimum content height
in #19118. This leaves the selective copy history dialog in an unusable state.

fixes #19303

[dterrahe]

OK. Long story. I tried to find a better solution than gtk_scrolled_window_set_min_content_height and then forgot I already had removed it to experiment.

What I tried to do is size the dialog correctly by default so that it would show all the rows (but no empty space). That is hard to do if you use a hardcoded number that doesn't depend on display resolution or font size/style.

Ideally, gtk_scrolled_window_set_propagate_natural_height should take care of this. "Natural height" is what I widget would want to get to fully show its content, but it can make do with less, for example by ellipsizing or scrolling. A "size request" on the other hand is a hard requirement and the widget won't take less. Which means that if you make the dialog smaller (or if the screen isn't large enough) there's no space to show the buttons underneath the scrollable window and the scrollbar won't appear.

Unfortunately, the "natural height" for a treeview with scrollbar is always reported as just the height of its header, when propagating to the scrollable window, so that doesn't work. You could ask the size of the treeview explicitly and then gtk_scrolled_window_set_min_content_height. The problem with mincontentheight is that it acts like a "size request". So it would be better to set the size of the dialog and then have the scrollable window automatically calculated from that.

But to get the actual sizes, depending on (font)style etc, the dialog actually needs to be shown first. Which means that now it is too late for gtk_window_set_default_size; you'd have to use gtk_window_resize. And that doesn't work well with wayland.

So after much playing around, I haven't found anything better than a hardcoded number. But I'd still set it using gtk_window_set_default_size rather than gtk_scrolled_window_set_min_content_height. So it needs to be a slightly larger number to include the buttons.

BTW same thing needs to be done in styles_dialog.c.

If you want to play with "correctsizing" the dialog; the best I could come up with is

  gint h1 = 0, h2 = 0, h3 = 0;
  gtk_widget_get_preferred_height(GTK_WIDGET(d->items), NULL, &h1);
  gtk_widget_get_preferred_height(GTK_WIDGET(dialog), NULL, &h2);
  gtk_widget_get_preferred_height(GTK_WIDGET(scroll), NULL, &h3);
  gtk_window_resize(GTK_WINDOW(dialog), 1, h1 + h2 - h3);

[TurboGit]

IIRC we do save the size of other dialogs and set the size to the saved one when restarting darktable. Maybe we should do the same here?

[TurboGit]

My recollection was correct, see use of ui_last/import_dialog_height for the import dialog in src/libs/import.c.

[dterrahe]

Sure, if we can't find out a way to size windows correctly, we can dump the responsibility on the user and save between dialog invocations. There are a few other dialogs that maybe then should be persistently placed. Shall I refactor restoring from darktablerc and setting up the "check-resize" signal handler to store latest?

The "ui_last/module_dialog_height" etc category isn't the most appropriate if it is to be used for a bunch of libs as well as the main ui, but I guess we'll stick with it?

So a call to dt_gui_restore_dialog_size("import"), for example, will restore the size and install the handler, immediately after gtk_dialog_new?

[zisoft]

So if you continue your work on this, can we close this PR?

[TurboGit]

Shall I refactor restoring from darktablerc and setting up the "check-resize" signal handler to store latest?

Yes please!

[dterrahe]

Added to #19319