Beyond 2.6

[Geert Janssens]

On 11-02-13 19:36, John Ralls wrote:
> On Feb 11, 2013, at 10:23 AM, Derek Atkins <warlord at mit.edu> wrote:
>
>> John Ralls <jralls at ceridwen.us> writes:
>>
>>>> As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're
>>>> dumping Gtk+ because we don't like the direction they're going, Gtkmm
>>>> doesn't get us anywhere.
>>> Having argued that C++ in the backend in not such a big deal, I'm
>>> going to turn around and point out that dropping Gtk+ in favor of wx,
>>> Qt, or some other GUI framework isn't a easy job: That *is* a complete
>>> rewrite, and there's a lot of it.
>>>
>>> Who would do it?
>> I was just pointing out that if we had to spend a lot of time migrating
>> to Gtk3 we might be better off spending the time migrating to something
>> else.
> OK. In fact we've (meaning Geert's) already done 90% of the job. All that's left is fixing the register to draw with Cairo surfaces instead of the ancient libgnome stuff. Not an easy job, but much easier than porting everything to Qt.
It's only fair to mention that I got a lot of help from Robert Fewell in 
this porting work. He is currently also working on a GtkTreeView based 
replacement for the register.

The '90%' that is done is actually *preparing* for Gtk3, which means 
dropping all deprecated widget api's and rebasing to Gtk 2.24. To really 
go Gtk3, we will need another round of api juggling and a rebase to Gtk 
3.x. This effort would be smaller than what we have done so far though.

Obviously this is less work still than completely replacing the GUI with 
Qt or wxWidgets.

There are several reasons not to switch:
- the size of the job of rewriting all GUI's
- Gtk may not be the most elegant code, but our code written in it is 
very tuned. We have lots and lots of small gui features implemented, 
tiny workflow optimizations, shortcuts, advanced tricks... All these 
don't come by default, so on top of reimplementing all the windows and 
dialogs, it will take a considerable effort to recreated the same (or an 
improved) user experience.
- social aspect: several developers have spent quite some time on the 
Gtk dialogs. I don't want to demotivate them by just throwing that all 
that work away just like that.

There are reasons to switch as well:
- As Christian suggested - when the core engine moves to C++, it would 
be much cleaner to have a signaling and gui framework associated with it 
that's better adapted. Perhaps gtkmm could still fit the bill here, 
though I have no idea.
- Qt and wxWidgets have a reputation of being more portable than Gtk 
(one of my key interests)
- Personally, I'm really curious to QML as a GUI description language 
(incidentally with very strong cross-platform support). It seems more 
readable than gtkbuilder's xml files. I haven't investigated it very 
thoroughly tough. On the other hand I have heard rumours that Gnome is 
promoting javascript as their main implementation language. I don't know 
any details, but that could bring similar advantages compared to QML.

In any case, if we want to switch, it will be a long-term project. And 
in my opinion one that should be executed in parallel to properly 
maintaining the current UX. I don't think we can afford to stop 
improving the existing GnuCash application for years while we're busy 
rewriting the GUI's in some other framework. The decision can mean some 
priorities shift, but I am a strong proponent of keeping a consistent 
user experience until we're very confident an alternative GUI branch is 
ready to take over. We have real users using GnuCash and I wouldn't want 
to drive them away by sending the wrong signal.

Geert