gnc-gnome-utils C++ conversion

[Geert Janssens]

Would it be worth to consider introducing gtkmm (and by extension glibmm) as new 
dependency and then at the same time convert gui element per gui element to c++ ?

It might ease to full transition to c++, but it will introduces new build dependencies in our 
packages (windows, macos and flatpak) and our downstream distro packagers.

If we'd consider this, I think that work should move to a new development branch rather 
than stable though...

Regards,

Geert

Op zondag 19 april 2026 07:17:32 Midden-Europese zomertijd schreef Russ Gorby:
> Ahh thats good information john. Ive already done some work on this but i
> think it makes, better sense to pivot to the leaf code as you suggest. Ill
> clean up what i have and save it for later.
> Appreciate the guidance.
> 
> On Sat, Apr 18, 2026, 9:51 PM John Ralls <jralls at ceridwen.us> wrote:
> > On Apr 18, 2026, at 16:39, <russ.gorby at gmail.com> <russ.gorby at gmail.com>
> > wrote:
> > 
> > I was planning to convert this library next but I’m concerned about the
> > review burden. It has 77 C code files and about the same number of header
> > files.
> > Is there better approach than doing everything all at once?
> > I’m resistant to doing a subset of .c files because I want to identify .h
> > files in the target that can transition to .hpp files based on where they
> > are included from and doing subset chunks could reduce the set that can
> > transition during this effort.
> > All I can think of is do minimal conversion first and then the deeper
> > convert as phase 2.
> > Thank you for your opinions.
> > -russ
> > 
> > 
> > It actually has 71 C files, 74 C headers, 6 C++ files and 2 C++ headers.
> > 
> > Most of gnome-utils is used by gnome and register, so very few of the
> > header files will be convertible until those other directories are
> > converted too. Also nearly everything in there is derived from Gtk classes
> > so even once you have it all compiling in C++ you’re still stuck with the
> > GObject lifetime and memory models. So not only would converting all 71
> > files in a single PR be unpleasant to review, it’s going to take a lot
> > longer than a single PR should. You really need to chunk it. There are
> > some
> > logical chunks: All of the tree-models (8 C files) would be a good one,
> > and
> > the 7 tree-views a complementary second chunk. There are 13 dialog files
> > that could be jammed into a single PR but might be more comfortable in 2.
> > 
> > You might also consider going downstream instead: register is already
> > broken into 3 directories with 14-17 C files each and it’s nearly all leaf
> > code, meaning that very little depends on it so you’ll be able to convert
> > more headers and need to have C linkage on fewer functions. gnome is 40 C
> > files and again is more leaf code than is gnome-utils, but it still
> > interacts strongly with Gtk so there’s less opportunity for converting
> > headers or using C++ linkage.
> > 
> > Regards,
> > John Ralls


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20260419/5efb3659/attachment.htm>