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

[Geert Janssens]

On Saturday 27 February 2016 14:32:41 Tobias Markus wrote:
> 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).

Great! So that would make a very valuable first patch set on its own. I realize there will be 
some refactoring required as you did the webkit2 part *after* the gtk3 part. But as it's a small 
change by your own judgment it shouldn't be too hard to split it out and submit by itself ?

That will allow for the next step to be worked on: getting webkit2 to build on Windows under 
mingw (and maybe also on Mac OS X).

Someone will have to spend time on these as well. It would be great if that someone would be 
you, though that's not mandatory. If not you, we'll have to wait for somebody else to find time 
and figure it out.

> 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.
> 
I don't understand this remark. What do you mean with "report system integration is not 
working right now" ?


<snip>
(I won't comment on the GApplication part as I don't know enough about it)

> > 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 need to get into arms here...

I didn't know about DOAP files and other than the comments above I still don't really.

On the other hand, gnucash does carry more files that are only used in specific circumstances 
(think of the xcode project file for example. If it's useful for external projects that can be a fair 
reason to include it. Does it have to be stored in the top-level directory ?