[RFC] GTK+ 3 Migration - Alpha-grade Patchset

[Geert Janssens]

On Monday 22 February 2016 18:56:24 Tobias Markus wrote:
> On So, 2016-02-21 at 13:22 -0800, John Ralls wrote:
> > > On Feb 21, 2016, at 11:12 AM, Tobias Markus <tobias at miglix.eu>
> > > wrote:
> > > 
> > 
> > Dear Tobias,
> > 
> > That's a huge amount of work, but it's a bit too far-reaching to be
> > considered a patch set and it doesn't really look like something we
> > can merge.
> 
> Greetings John,
> 
> first of all, thanks for your comments. No Sweat - I'm not asking for
> a merge right now, this is really just a fundamental set of patches
> to get GnuCash running under GTK+ 3 and obviously needs more work.
> > It's also quite possible that we won't ever move GnuCash to Gtk+-3.
> > We haven't decided on a future UI toolkit and if you'd looked at
> > http://wiki.gnucash.org/wiki/Roadmap you'd realize that we have
> > other
> > priorities. Unfortunately it doesn't look like many of your changes
> > advance those priorities, and the way you've done your changes would
> > make it very difficult indeed to cherry-pick out the parts that
> > might
> > be useful. 
> 
> Please have a look at the roadmap again :D There are only two
> paragraphs regarding the UI in the roadmap, and they are "Register
> rewrite" - my work is basically building on top of the register
> rewrite
Not quite. You are mixing migration to gtk+3 with rewriting the register in gtk. Two 
major/fundamental changes in one go. As said in my other mail, that means two objectives to 
keep track of and to untangle in case something is not working well. That's a large additional 
burden in the maintenance phase later on.

Don't get me wrong. I believe both objectives are valuable. But one after the other, not in one 
go.

> - and "Eliminate deprecated widgets and libraries" - that's
> what my patches are all about - going from GTK+ 2 to GTK+ 3, from
> webkitgtk to webkit2gtk, and replacing the deprecated Gnome Canvas
> based code! :)

Again: 3 major migrations in one go. Same objections. Untangle these 3 migrations please.

> 
> Regarding the toolkits, I will respond in detail at the end of this
> reply.
> 
> About the non-GTK+3-ish changes: I've tried to keep some of the more
> general improvements on the next branch, but unfortunately, most of
> the changes are complex enough that cherry-picking them from the gtk3
> branch is possible, but somewhat complicated. Since the actual coding
> work was large enough, I concentrated on getting the initial
> migration ready.
> 
> > Had you come here before starting work we could have guided you
> > towards work that could be merged and coached you about making
> > commit
> > messages, style, and the like. Perhaps you'd consider starting over?
> 
> If by starting over you mean doing some more rebasing to improve the
> commit messages, sure! But as I said, I would rather get my gtk3
> branch feature-ready, i.e. implement the major points I mentioned
> above.

And this is where we seem to disagree on the approach. Getting a branch feature-ready at the 
expense of strategic considerations is making it harder on everybody else that is interested in 
your work.

I'll repeat I prefer change sets that are well structured (to the extent possible), even if that 
means the end goal of feature completeness takes longer to achieve. It saves time in the 
maintenance phase which is generally much longer still than the initial implementation phase.

Don't get me wrong. I do appreciate what you have achieved so far and the time and effort you 
put into it. I do ask you to consider the other developers' time as well by refactoring your code 
into a more coherent set of patches.

> Please let me know which changes were especially unclear or
> confusing, and I will happily improve their commit messages.
> 
See above for my first impression.

> About the commit messages: I can do better, I promise :D

Good :)

> As mentioned above, I focused on getting the branch ready.
> Most of the "Gnome WIP" commits are pretty similar actually, they all
> consist of the core GTK+ 3 migration changes, i.e. replacing
> deprecated features by their recommended replacements.
> 
Ok. Let the commit messages reflect this. It will probably make it considerably more easy to 
digest your branch.

> What exactly do you mean with style? I tried to have most of my
> additions follow the general style of the relevant file.
> 
> > About your recommendations:
> > * We probably will drop autotools in favor of cmake for the next
> > release.
> > 
> > * Vala is not useful to GnuCash. It is usable only with Gtk+ and we
> > need to be able to write GUIs for other platforms. We decided two
> > years ago to redo the guts in C++11 and are working on that.
> 
> John, I didn't mean to say that the entire GnuCash codebase should be
> written in Vala, that certainly wouldn't be the right way. My idea is
> to rewrite just the UI (i.e. GTK) code in Vala.
> 
> Don't get me wrong, I love C++ and C++11/14 most of all! I just
> thought that if the UI code is rewritten, and I think we both agree
> that the current UI code consists of a lot of boilerplate code, it
> should be rewritten in Vala. (But honestly, that's not a very strong
> opinion of mine, as I said, I really like C++ too.)
> 
> The reason why I suggested Vala instead of C++/gtkmm is that Vala is a
> 1:1 match to the GObject system, and while gtkmm code is certainly
> easier to write that pure GTK+/C code, they aren't really a perfect
> match.

That does make sense indeed. On the other hand the current objective is the slowly migrate 
away from the GObject system, replacing it with true C++ OO.

One important reason for that is portability to mobile platforms (think IOS, Android). Some time 
back it looked like glib/GObject was a major roadblock in that direction. I don't know whether it 
still is, but at the time that was one major driving factor to switch to C++. The future GUI 
toolkit will also be evaluated in that context.

> 
> My general point is that the UI code, after migrating it to GTK+ 3,
> has some parts that could benefit from some refactoring, e.g.
> removing certain now unnecessary functions (especially