gnc-gnome-utils C++ conversion

[John Ralls]

Geert,

It’s not just glibmm, there’s a whole stack for Gtkmm: cairomm, pangomm, libsignal++, and atkmm as well as glibmm. Each of them depends on the underlying C library. It’s pretty widely supported, but it has already been dropped for mingw32 so we need to solve the WebKitGtk 64-bit Javascript crash and move to ucrt64 before we can use it there.

We won’t know if it makes converting to C++ easier until we try. I do agree that that would be a big enough change to warrant a major version bump and that it’s a one file at a time project.

Regards,
John Ralls

> On Apr 19, 2026, at 05:55, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> 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
> 
>