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

[Tobias Markus]

On Mo, 2016-02-22 at 21:18 -0800, John Ralls wrote:
> > 
> > On Feb 22, 2016, at 1:57 PM, Geert Janssens <geert.gnucash at kobaltwi
> > t.be> wrote:
> > 
> > > 
> > > Major changes already in my tree:
> > > * All "rich" GtkActions/GtkRadioActions/GtkToggleActions were
> > > replaced
> > > by abstract GActions/GMenus. This doesn't sound like a lot, but
> > > is a
> > > major change. Please read the relevant API documentation and do
> > > not
> > > hestitate to ask me if you have any questions about the new
> > > GAction-
> > > based infrastructure. Sorry for not going into more detail, but
> > > describing the technical peculiarities here would take
> > > considerably
> > > too long.
> > > * I removed the splash screen and replaced it by GApplication's
> > > busy
> > >  notification in some places.
> > 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.
> > 
> > > 
> > > * 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.
> > 
> > As an aside: I would prefer to see the migration to the Webkit2 API
> > as a separate project from 
> > the gtk3 migration to reduce the amount of moving parts per branch.
> > If gtk3 migration depends 
> > on webkit2 API, it should be done first. If not, it can also be
> > done after the gtk3 migration has 
> > stabilized.
> > 
> > > 
> > > * Using GtkApplication renders everything related to
> > >  gtk-osx-integration unnecessary.
> > That would certainly be nice. John is in a better position to
> > confirm or deny this.
> > 
> > > 
> > > * This is unrelated to the GTK+ 3 migration, but I added a
> > > Markdown
> > >  version of the README and added a DOAP project description.
> > So now there are 2 README's to keep in sync and an additional DOAP
> > description. I would 
> > propose to keep only one README file. I have no strong preference
> > over plain vs Markdown. 
> > What benefit is the Markdown edition ?
> > 
> > And what benefit does the DOAP file bring us ?
> > 
> > Lastly as you say yourself, this is not Gtk+3 migration related, so
> > would best be submitted as a 
> > separate PR.
> Several different branches: WebKit2, GApplication, and Gtk3
> migration. At least. There's probably more buried in there.
I have to disagree here:

WebKit2 sounds like a huge step, but it really isn't. As one of the
last things before releasing the patchset, I tried to convert gnc-html-
webkit to WebKit2, and it was done rather quickly (and it works as in
"it shows a report, but I didn't go any further", but that doesn't mean
this really breaks stuff). The report system integration is not working
correctly right now, so I couldn't really test it, but I don't really
expect there are major deal-breakers along the way.

Moving to GApplication sounds unrelated, but it is not: In GTK+ 3,
there are window actions and application actions. Most actions are
window actions, except for file-unrelated actions like Quit, Help,
About, Preferences, etc. The latter actions are - big surprise - added
to the GApplication/GtkApplication. So without moving to GApplication,
the migration to GActions (which, oversimplified, is what moving to
GTK+ 3 is all about), is not possible. Unless you intended to merge the
move to GApplication right now, independently of the GTK+ 3 migration,
I see no reason for the significant effort of separating the two.
> 
> GApplication (NOT GtkApplication, that's obsolete and doesn't work on
> OS X or replace gtk-mac-integration)
That is simply not true, GtkApplication is not obselete at all. Why
should the *official* GTK+ tutorial (https://developer.gnome.org/gtk3/s
table/gtk-getting-started.html) use GtkApplication if it was
deprecated?

On gtk-mac-integration: Citing from your gtk-mac-integration repo at ht
tps://github.com/jralls/gtk-mac-integration:

"NB: Applications already using Gtk+-3.4 and GLib 2.36 and later should
use the GApplication/GtkApplication and GMenuModel/GMenu APIs which
make this library unnecessary."

> is a significant architectural change in the program and is separate
> from Gtk3 migration.
No, it's not separate. See above.
> I haven't actually tested it.
Is you having tested GApplication in person a prerequisite for it to be
worth merging?
> Have any major applications switched?
Which major applications? All major applications don't use Guile, so
should Guile be removed from GnuCash?
> Aside from obviating gtk-mac-integration and maybe integrating better
> with the Gnome3 desktop what are the benefits? 
I thought GtkApplication does not make gtk-mac-integration unnecessary
at all?

There is a simple benefit: GnuCash (currently) is a GTK+ application,
and there is no reason why it shouldn't use a feature that improves
integration with the desktop. If you don't like GApplication and GTK+,
just finish CuteCash.
> 
> A markdown README looks nicer on Github. Markdown is quite legible in
> plain text, there's no reason to have two.
That is my reasoning, too.
> 
> doap files are used by git.gnome.org for organizing the display of
> projects. GnuCash has no need of a doap file.
Ah, so because someone at Gnome uses DOAP files, they are poisoned and
GnuCash should never include a DOAP file?
The Python Package Index Index (PyPi) with over 75k packages uses DOAP
files for their project descriptions.
> 
> Regards,
> John Ralls

John, I think we maybe had a somewhat bad start. But please don't write
off everything I do trying to improve GnuCash as bad just because it is
related to GTK+.

Best regargs,
Tobias