Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?

[Jeff Kletsky]

In my opinion, it is great that Scheme and Guile are on the way out.

I would suggest though, that something more than how few lines of code 
are needed go into the determination of the language for the UI. 
Otherwise, APL is going to win hands down. Even the presence of bindings 
doesn't sway me much. The amount of UI code (and proper re-factoring of 
business logic out of the UI) is probably going to be much larger than 
the bindings. Part of me also cringes at the thought of using two 
different languages for one application unless there is a good reason.



I'd argue for at least the following:



* Modern, object-oriented code

This one really goes without saying, I hope.

I'd personally prefer one that handles "multiple inheritance" in a 
reasonable way and clearly supports anonymous functions, closures, and 
"lazy build" functionality.



* Popular among developers

You want people to already have the skills to be able to contribute to 
the project. The Open Source world is not really much different than the 
commercial world. Now matter how slick "your" language is, it is going 
to be much easier to, for example, find top-notch Java programmers, than 
some niche language (unless it is deemed "the next great thing").



* "xPad" aware

Consider that I wouldn't be surprised if there are more iPads out there 
than Linux desktops. Android is on the upswing. The increasing number of 
handheld devices, to some extent, argues against heavyweight 
interpreters. Why should the user have to not only download an app, but 
also another language interpreter, and potentially another GUI 
framework? I'm not saying that GNUCash must be in Objective C, but 
thinking about platform support and impact is worthwhile.



* Understandability and Maintainability

I guess that rules out APL...




On 01/10/2011 02:24 AM, Christian Stimming wrote:
> Dear all,
>
> We've been discussing various future directions for gnucash, including 
> a switch to a different programming language for the GUI code [1]. GUI 
> coding in C sucks. Because of this, I've experimented with C++/Qt and 
> was able to write up a usable gnucash-like register window GUI in 2-3 
> weeks which already includes features that are unavailable in 
> "conventional gnucash" [2]. I chose C++/Qt because I'm very familiar 
> and productive with that platform.
>
> However, a scripting language might be even more suitable for writing 
> the GUI code of a project like gnucash. The language Python is a 
> particularly good candidate here because gnucash already has python 
> wrappers for most of its underlying data type and storage code, 
> thankfully provided by Mike Evans and others. See 
> src/optional/python-bindings/ and the doxygen output [3] and the 
> example scripts in python-bindings/example_scripts/, in particular 
> scripts like simple_book.py: Loading an existing file, modifying some 
> of the data, and writing again, all in 12 lines.
>
>