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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
