continue conversion to dt_gui_box_add/_vbox/_hbox

[dterrahe]

Following up on #18273 and #19118

New work often gets copy/pasted from existing code so the longer the old pattern exists the more needs to be converted in the end.

This PR finishes all of iop and converts some libs. It does not attempt to convert all dialogs at this point, since some of those (modulegroups/print) are probably better served with a partial redesign/rewrite when porting to gtk4.

Some more of the libs panel code could be done now, if somebody wants to step up. Please coordinate here if you plan to help out, so we don't do double work and I can review and comment early.

As usual this is partly tedious application of similar patterns, so the mental energy left for testing was very limited. This especially applies to deprecated modules. A thorough review would be nice. And if someone went to hunt for newly introduced memory leaks, I'd be surprised if they didn't find any.

[TurboGit]

That's a huge amount of work ! I'm not yet over reading the code, but frankly it is hard to review. I'll start testing too.

[TurboGit]

Something is happening with the darkroom right panel. I cannot resize it completely, it remains large:

I cannot make it smaller than that:

Whereas on master I can have it as small as this:

[dterrahe]

Thanks for letting me know; I'll investigate.

BTW the last commit doesn't belong here; I'll move it to a separate PR.

[dterrahe]

Something is happening with the darkroom right panel. I cannot resize it completely, it remains large:

Fixed. I had to explicitly set hexpand for the sidepanels to false, otherwise the widgets in hboxes that had it set (to replace the TRUE, TRUE parameters to gtk_box_pack_start) would cause that value to get propagated up. One of the subtle differences between the old and new way of doing things. This may occur in other places as well (dialog boxes etc) so please continue to be on the lookout for this. Thanks!

[wpferguson]

@dterrahe does lua/widgets/box.c need work too?

[dterrahe]

Yes, eventually lua needs work too, but it is going to be more complex than simply replacing one pattern for another. gtkcontainer will completely disappear, so some of the central infrastructure will need to be rewritten. Not much point replacing "low hanging fruit" if that work eventually needs to be redone to a deeper level.

What I'm doing for now is convert simple standard functionality that is widely spread (in iop and lib modules), like compositions using boxes and scrolled windows and event/gesture handling, where an approach that is compatible with gtk4 can implemented and tested in place. This could put us in a position where we can then work on switching the core infrastructure and fairly quickly have something "working" that people can start experimenting with instead of ending up in a state where "everything" is fully borked for a prolonged period of time preventing people from getting involved (in testing). Anything that isn't "core" (i.e. would prevent starting), like dialogs and lua, can then be filled in from that state. Being able to immediately run and test something that is converted should dramatically increase productivity.

Just to manage expectations; there's no "grand plan" as yet, with work items, timelines and "resource" allocations. Just looking at different bits and pieces, feeling my way around, tackling subtasks that seem doable now and learning about what next steps would be involved. In the meantime any work is also intended to improve the quality of the current codebase (just in case a final gtk4 transition never materialises). Anybody who wants to do the same thing (learning about gtk4 and what conversion could involve) is encouraged to do so. I would also encourage coordination (with me... I do seem to be the "expert" for now) before going ahead and spending too much time on actual work/PRs.

[TurboGit]

Tested as much as I can... no other issues found. Thanks!