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

[Geert Janssens]

On Saturday 27 February 2016 17:15:56 Tobias Markus wrote:
> On Mo, 2016-02-22 at 22:57 +0100, Geert Janssens wrote:
> > A few general suggestions:
> > 1. Better commit messages. Each commit message should summarize what
> > the commit does.
> > 2. Make changes as atomic as possible. One commit should focus on
> > one
> > change. Depending on the change, a commit can be large or small. As
> > long as it remains clear what that commit is doing.
> > 3. Split out cosmetic changes (like whitespace and indentation
> > fixes)
> > from functional changes.
> 
> That's what I have in mind

Good!

> - it's just a lot of work for the ~150
> commits I already have, not to mention those to come :D
> 
That's ok. Take your time. The next major release is at least 1 year from now.

> >  
> > I'll add more comments below between your message.
> >  
> > 
> > On Sunday 21 February 2016 20:12:58 Tobias Markus wrote:
> > > Hi GnuCash developers,
> > >
> > > 
> > >
> > > over the last few feeks, I have developed a fundamental patchset
> > 
> > that
> > 
> > > should get GnuCash up and running in GTK+ 3.
> > >
> > > 
> > >
> > > The source code is available at GitHub:
> > > https://github.com/hesiod/gnucash/tree/gtk3
> > >
> > > 
> > >
> > > Some independent commits are on the next branch.

I didn't realize "next" was actually the name of a branch. I read it to mean "some other branch 
with follow-up commits to be merged afterwards".

I looked at the next branch. Most of the commits on that branch are fine to me, except for:

1. One commit adds egg-menu-manager files, but is not using them in any way (yet). Move this 
into the gtk+3 branch to the point you actually need them.
2. I haven't check whether your clang-format-style definition matches the formatting we have 
been doing so far with astyle from time to time. The last time I ran it was with these settings:
astyle --indent=spaces=4 --brackets=break --suffix=none
If that's what your clang formatter does I'm fine with it.

Do keep in mind for all subsequent commits we prefer to keep formatting changes in separate 
commits from actual code changes. That helps tremendously in bisecting later on.

So if you make these few changes, that part can be merged already as far as I'm concerned.

<snip>

> > We will have to check what's available in the distributions we
> > intend
> > to support. The two most conservative ones typically are Debian and
> > RHEL.
> > Current stable Debian (8.0/Jesse) is at gtk+ 3.14.5. I don't think
> > Debian will have another major release at least one year before the
> > next major gnucash release.
> > RHEL (7.2) is at gtk+ 3.14.13.
> >  
> > So I expect we will need to support 3.14.
> 
> That should be doable.
> 
> I'm really not a distributions expert, but wouldn't Debian for example
> wait anyway before picking up a version 3.0.0? I thought they would
> probably stay with the latest stable series anyway.
> 
True. However there are also the backports. If we stick to a version of gtk+3 that's available on 
debian stable, this will make it a lot easier for package maintainers to provide a backport of a 
more recent version of gnucash. And so debian stable users can have a choice of the stable 
version of a more recent one. That's an opportunity we shouldn't miss out on.

<snip>

> >  
> > What's the motivation to remove the splash screen ? GnuCash is a
> > slow
> > loading application. Several users prefer to have a splash screen
> > indicating progress (like LibreOffice does for example).
> > And yes, I understand that we could optimize loading speed to avoid
> > the need for a splash screen altogether. But we're not there yet by
> > a
> > long shot.
> 
> This is more of a temporary measure. I reasoned that if the loading
> speed was improved significantly in time for the release, then the
> splash screen wouldn't be needed anymore. And if startup speed was
> still rather slow, reintegrating the splash screen into the
> GApplication-based code would need some thought anyway to make sure it
> integrates well.
> 
Ok. That's a fair assumption. I'll do my mantra thing again here: the loading speed has to be 
acceptable on all platforms we currently support. I can tell you that the Windows port 
sometimes still loads magnitudes slower than the linux version. So even if we don't need a 
splash screen any more on linux, we still may require it on Windows. Time will tell.

> GApplication provides a way to indicate to the user that the
> application is currently busy via g_application_mark_busy. I included
> that in the startup process, so even if the splash screen wasn't
> needed anymore, the user would receive some feedback.
> 
What does that indicator do exactly ? And does it work on Windows and OS X as well ?

> >  
> > 
> > > * I updated the HTML code to use the Webkit2 API, but it needs
> > > some
> > >   more love.
> > 
> >  
> > That's a nice improvement. We were lagging on the Webkit upgrades.
> > There is an important reason for that though: it's almost impossible
> > to build webkit on Windows. Do you intend to tackle that part as
> > well
> > ? We'll need a usable Webkit2 library on Windows before we can land
> > your webkit2 api.
> 
> Sorry, but I'm no expert in doing Unix-ish stuff on Windows :D