geert.gnucash at kobaltwit.be
Sat Jul 8 12:31:38 EDT 2017
I had a few merge conflicts to resolve during merge. There was one that wasn't
To be able to continue with the merge I have reverted it to the state on
master, except for the name changes for the primary dialogs. That way it still
builds fine, but your deprecated widgets changes are lost. There is
unfortunately no way to sanely resolve merge conflicts in a glade file.
So this file has to be converted again.
What I did is pull in your branch (which also includes my and John's work) and
merged it locally in the current master branch, after resolving the conflicts.
I then pushed this result back to my github repo (gjanssens). So the master
branch in that repo is now running gtk3.
Note that this branch currently doesn't install if you enable building with
aqbanking. This is also the case for our central master branch though. It
looks like there are a few issues with the dist/distcheck/uninstall commit. I
fixed one of them on my local branch but I have no idea how to fix the
Anyway to avoid we have to do this merge again in the future, can you (re)base
your local commits you haven't pushed yet on my master branch ?
I'm holding off on pushing the whole thing to master on code.gnucash.org until
I heard from John.
On zaterdag 8 juli 2017 16:02:01 CEST Geert Janssens wrote:
> I'm done with reviewing your work. You'll find mi comments directly on the
> github commits.
> In general - well done! This really brings us much closer to a real gtk3
> As far as I'm concerned your branch is ready for merging:
> - the tree builds fine
> - the build executable seems to work barring a few visual details
> So IMO this is ready to be tested by a bigger audience.
> On zaterdag 8 juli 2017 15:01:38 CEST Geert Janssens wrote:
> > Bob,
> > While reading through your changes I note we have lots of places where we
> > make some small tweaks to the default gui style. It shows in your commits
> > because we have to change from GtkStyle api to
> > GtkStyleContext/GtkCssProvider api.
> > This got me thinking about a future streamlining we should consider:
> > instead of adding code snippets that insert custom CSS, can't we collect
> > all of these snippets in one big CSS file we ship with gnucash, to be
> > stored in /etc/ gnucash/gnucash.css and which we read at load time ? Much
> > like we now load a custom .gtk3.0-gnucash.css file.
> > Both can co-exist IMO, with the latter taking precedence over the former.
> > The one in etc should be "Application" priority the one in the homedir
> > "User" priority.
> > This would keep the code cleaner and separate function from presentation.
> > Especially your initial work of adding style context to most widgets is a
> > big step in the right direction.
> > What do you think ?
> > Regards,
> > Geert
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel