> On Oct 4, 2016, at 6:42 AM, Linux Luser <linuxlu...@gmail.com> 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.
Dave, Thanks for your interest, and especially thanks for asking before starting to work! The current GUI is indeed a bit tired, but we're blocked from making substantial changes to it by two problems with the code. The more significant is that there's a lot of "business logic" inside of the GUI code coupled rather tightly with Gtk2. That needs to be extracted to break the coupling and to make it available to alternative GUI frameworks. The other problem is that the core of the GUI, the register, was lifted from gnumeric 15 years ago and has its own list view that was a precursor to GtkTreeView for Gtk+-2.0. Bob Fewell rewrote a Gtk+-2.24 GtkTreeView replacement (you'll see it in the code base as "Register2" but he wasn't able to get it stable in time for 2.6 and hasn't pursued it since because we still don't know for the long term what toolkit we want to use and he feels that any work on Register2 might be thrown away. Around the time that we started discussing a new GUI we also realized that our core library is tightly bound to Gtk+ through the extensive use of GLib and GObject. We need to break that dependency in order to be able to use non-Gtk GUIs and to port GnuCash to mobile platforms. Geert and I have prioritized rewriting the core in C++ for the current and next development cycles (i.e. through 2020). There's one other core item on the agenda: Removing Scheme from everything except the report system. We haven't made any progress at all on that. There are no plans at all to use a language other than C++ for new work in the near term. Once those three projects are completed we'll be in a position to write Android (in Java, the only choice) and iOS (Swift or Objective-C, again the only choices) as well as whatever we decide upon for the desktop GUI. Python isn't likely to be a choice: There are no native Python GUIs, only Python wrappers of varying quality (merely OK to abysmal) around C and C++ frameworks, and modern C++ is just as expressive as Python without the burden of garbage collection and portability problems for the wrappers. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
