Are There Plans For A GUI Overhaul?

[Geert Janssens]

On Monday 03 October 2016 21:42:54 Linux Luser wrote:
> I've been doing my personal finances using spreadsheets for many years
> now. I've gotten things down where it's easy now. However, it's hard
> to get good data out of it. I needed a real financial program so I
> turned to gnucash. I am happy I did. It was challenging to have to
> learn good accounting practices, terminology and approaches to
> finances. The learning experience itself was worth it and I now feel
> I can utilize gnucash for my financial needs.  Thanks a lot to all
> who've contributed!
> 
> 
> Now I have concerns of a technical nature. I have run into so many
> usability bugs in the application that I've lost track. I thought,
> "I'll see if there's a bug open for this or maybe open a new one."
> I've even thought "Well, time learn C again!" I looked through the
> bug queue and noticed that lots of the GUI-related bugs were years
> old. Even things that should be simple to fix.
> 
> In the code I found out about cutecash, a QT-based GUI for gnucash. I
> ran into lots of build problems on my machine that I haven't resolved
> yet (does it still build?), so I was unable to see it first hand.
> 
> However, all of this, taken together, has lead me to believe that
> gnucash is due for a GUI transplant. It needs a makeover, if only for
> the developer's sake so that it's easy to fix usability bugs qiuckly
> (which appears not to be the current case).
> 
> 
> What are the current discussions surrounding build a new, modern GUI
> for gnucash? Has there been talk about using a different language,
> other than C/C++ for the GUI? QT or GTK3?
> 
> And to expose my biases a little, my experience is mostly with Python.
> Python + Glade has worked well in the past for to create a GUI in a
> surprisingly small amount of time. I also use Python at work for
> mostly data-related tasks so I know how easy it is do some very cool
> data work in Python. Most meta-type of programming can be done well
> using dictionaries!
> 
> 
> I'm wanted to get my feet wet and help, but I feel like trying to work
> out all of the GUI problems with the current build of gnucash would
> be futile. It seems to me that if a new language/toolkit combo could
> be found that most current developers could agree upon, then it would
> re-ignite interest in gnucash's usability.

Hi Dave,

I'm pleased you are interested in an better user experience for GnuCash. 
It's one of the things I care a lot about as well.

This has been discussed in the past a couple of times, but we never got 
to a conclusive decision.

What is clear is that a gui overhaul is needed and will eventually 
happen. It's currently not a priority though. The currently active 
developers have decided to first refactor the non-gui parts of gnucash. 
We're in the middle of a transition from C to C++, aiming for easier to 
manage code with better abstraction and encapsulation and - more related 
to this thread - a better separation of functionality and gui.

As this rewrite makes the non-gui code quite a moving target it was more 
or less decided to postpone the gui rewrite to later. Too many moving 
targets are too difficult to keep track of.

The choice as C++ as our base language also makes Gtk less attractive as 
GUI toolkit to continue with in the long term. There are C++ bindings 
for Gtk, but overall it's not a very good match.

In addition the multi-platform nature of gnucash further limits the 
possible choices of GUI toolkit.

In particular your suggestion to do the gui in python + glade is 
currently not an option as we don't have python integration available on 
our Windows or OS X ports. This has been tried in the past, but so far 
it wasn't successfully implemented.

Taking all restrictions together, the last discussions in the passed 
proposed two potential candidates to become the new gui toolkit for 
gnucash: Qt and WxWidgets.

This brings us to cutecash as well, which was an experiment by one of 
the developers to see if it was feasible to use the gnucash business 
logic with a new gui toolkit (qt). While the experiment in itself could 
be considered successful it never was developed further into a fully 
fledged replacement gui for gnucash. The experiment did expose several 
issues with the business logic and hence was an indirect trigger for the 
rewrite that's currently going on.

Considering the limited manpower we currently have, it will still take a 
few years before we get to really replacing the current GUI. This 
doesn't mean however I'm not welcoming patches for the current GUI as 
well if they fix small usability issues. And I personally think we may 
have to finish the port to Gtk3 even before we get to porting a new 
toolkit. Gtk2 may not be supported long enough for us to be able to make 
the transition.

There are two things holding back that switch to Gtk3:
1. our register code, which is based on the deprecated gnome-canvas. A 
replacement was written but never finished.

2. the use of webkitgtk. For Gtk3 we need a newer version and this turns 
out to be surprisingly challenging to build on Windows.

So to summarize, you're most welcome to join in in any way you see fit. 
Small improvements can already be made in the existing GUI as far as I'm 
concerned. User Experience (UX) is GUI toolkit independent IMO. If we 
improve the UX now already, the same good UX can later be reimplemented 
in a future toolkit. Finishing the port to gtk3 even though it will 
likely be only a transition is still useful as well, considering the 
time it will take to do all the rewrites.

Regards,

Geert