On 11-02-13 19:36, John Ralls wrote:
On Feb 11, 2013, at 10:23 AM, Derek Atkins <[email protected]> wrote:
John Ralls <[email protected]> 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
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
