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

[John Ralls]

> On Feb 27, 2016, at 5:32 AM, Tobias Markus <tobias at miglix.eu> wrote:
> 
> On Mo, 2016-02-22 at 21:18 -0800, John Ralls wrote:
> 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.

Immaterial. Webkit2 and Gtk3 migration are separate, so they need to be in separate PRs.
> 
> 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.

Contrary to my experience: Gramps migrated from Gtk2 to Gtk3 two years ago without adopting any of GtkApplication or GApplication code. Separate PRs.

>> 
>> 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?

Because Gtk's developers are no better at maintaining documentation than everyone else's.
> 
> 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."

No argument. That's about new code.

> 
>> is a significant architectural change in the program and is separate
>> from Gtk3 migration.
> No, it's not separate. See above.

Repeating: Gramps migrated to Gtk3 and did not rewrite to GApplication. 
>> I haven't actually tested it.
> Is you having tested GApplication in person a prerequisite for it to be
> worth merging?

Not only have *I* not tested it but I don't know of any major Gtk application that has either. I'm sure it works fine on Linux but I have no reason
>> Have any major applications switched?
> Which major applications? All major applications don't use Guile, so
> should Guile be removed from GnuCash?

Yes, but that's a separate matter entirely. Examples of other major Gtk applications whose development team maintains Windows and Mac versions include The GIMP and Ardour. GIMP is the progenitor of Gtk -- the TLA originally decomposed as GIMP Tool Kit -- and they have not yet merged their Gtk3 development branch. Not only that but it uses GtkOSXApplication, not GApplication.

What other applications of similar size and with large cross-platform user bases have adopted GApplication?
 
>> 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.

No, because Github *doesn't* use DOAP files adding one to GnuCash accomplishes *nothing*. GnuCash isn't hosted at git.gnome.org and it would be *really* strange for it to be in PyPI.