Best GUI for small-scale accounting app?

[Bulba!]

I'll soon start development of a specialized small app and need
to choose GUI for it.

I have narrowed the choice to wxPython/PythonCard and QT/PyQT
(buying commercial licenses is not a big problem, the company
would pay for it).

Which is better for this kind of application? I mean, looking
from purely technological and long-term development aspects
and ignoring licensing issues:

- QT seems to be industrial-strength, but.. it's probably
more complex/difficult to use.

- wxPython/PythonCard is probably simple to use, but..
are there not some pitfalls that development will fall
into once the app starts growing (they all do)?

The long lists of invoices, subcontractors and tasks (possibly
hundreds or thousands) will have to be displayed - which toolkit
is better for that in your experience?

I would appreciate anybody sharing their experiences with
relevant toolkits in development of this type of software
or similar.

 

[Paul Rubin]

I'll soon start development of a specialized small app and need
to choose GUI for it.

I have narrowed the choice to wxPython/PythonCard and QT/PyQT

What does the app need to do? I'd try to make it web based unless
there's a good reason not to. That's even if it just runs on the
user's desktop; run the http listener on the localhost and let the
user connect to it with a browser.

However, between those two you mention, wxPython seems easier to use
and runs on more platforms. On the other hand, it may be less well
maintained than QT. For example, its current installation script
seems to assume an older version of GTK is installed, and it fails
with newer GTK versions.

 

[Diez B. Roggisch]

I have narrowed the choice to wxPython/PythonCard and QT/PyQT

(buying commercial licenses is not a big problem, the company
would pay for it).

Which is better for this kind of application? I mean, looking
from purely technological and long-term development aspects
and ignoring licensing issues:

- QT seems to be industrial-strength, but.. it's probably
more complex/difficult to use.

- wxPython/PythonCard is probably simple to use, but..
are there not some pitfalls that development will fall
into once the app starts growing (they all do)?

If you can spend the money, I'd certainly go for qt. I just created a
mid-size gui app with it, and it simply rocks. The designer is really cool,
and the whole framework is thouroughly designed and works (so far) flawless
for me. Also the signal-slot mechanism makes implementation of a MVC
pattern pretty easy.

But I have to admit that I don't have larger expierience with wx. Try
googling this newsgroup, there have been plenty of discussions on this.

As you can qt for free on linux, you could try both and see what suits your
needs best.

 

[Steve Holden]

What does the app need to do? I'd try to make it web based unless
there's a good reason not to. That's even if it just runs on the
user's desktop; run the http listener on the localhost and let the
user connect to it with a browser.

I'm not sure I'd agree with this advice. It's easier than it used to be
to put a good-looking web interface together, but considerably more
difficult still than using either wxPython or PyQT. The web is still
clunky for certain types of interaction, as you either have to
completely redisplay after a server round-trip or closely co-ordinate
client-side code to keep some interactions local to the client. This is
a difficult compromise, and requires a lot of experience.

However, between those two you mention, wxPython seems easier to use
and runs on more platforms. On the other hand, it may be less well
maintained than QT. For example, its current installation script
seems to assume an older version of GTK is installed, and it fails
with newer GTK versions.

Both packages are maintained be people who know what they are doing.
wxPython has had its issues over the years, but many of those have (I
believe) been due to the instability of the underlying wxWindows (no
wxWidgets) package, which in turn has often been due to the introduction
of serious chunks of new functionality.

Personally I think that the choice may well come down to which API is
closest to what Bulba has used in the past.

Both kits are well capable of handling everything a serious programmer
would want to do. I personally think that wxPython gets closest to the
native look-and-feel of the windowing platform, but that may just be my
limited experience speaking.

regards
Steve

 

[Bulba!]

What does the app need to do?

Basically, it's for a "data-entry monkey" and/or PM - check if this
task has been done, possibly edit some data. Once task is closed,
move it to the invoicing module and add the task's data to the
semi-final invoice.

I'd try to make it web based unless
there's a good reason not to.

Reason 1: It would be somewhat complex to develop it using
PHP (I have done some recon in that area) and using GUI
on Windows is actually faster way of entering and editing data
than via the Web browser I think.

Reason 2: I don't want to learn yet another language
just for this app and want to avoid integration problems
as we plan to develop yet another application for other workers
that would connect to the common DB and sent the data directly
for that accounting app.

ZOPE could provide the workaround but ZOPE seems really huge to
me and an overkill for this. Or maybe it would work?

That's even if it just runs on the
user's desktop; run the http listener on the localhost and let the
user connect to it with a browser.

However, between those two you mention, wxPython seems easier to use
and runs on more platforms. On the other hand, it may be less well
maintained than QT. For example, its current installation script
seems to assume an older version of GTK is installed, and it fails
with newer GTK versions.

I will consider that, thanks for prompt reply!

 

[Bulba!]

Personally I think that the choice may well come down to which API is
closest to what Bulba has used in the past.

Well I haven't used any of them - I only plan to start learning and
using GUI toolkits. Hence the question, precisely because I know that
once I get into particular toolkit, it's going to stay with me for a
long time.

Both kits are well capable of handling everything a serious programmer
would want to do.

...and that is one of important things that I needed to know. Thanks.

BTW, do you have any experience with how respective GUI builders
actually work? QT Designer seems great and people seem to use
it in industry, but how useful is PythonCard useful in real-world app
development?

 

[Paul Rubin]

I'm not sure I'd agree with this advice. It's easier than it used to
be to put a good-looking web interface together, but considerably more
difficult still than using either wxPython or PyQT.

I think I can put together a useable (but not visually stunning) web
interface faster than I can put together any pure client-side
interface. Making the web interface look really good might be harder
than making wx or QT look really good, but for lots of applications,
"useable" is good enough.

The web is still clunky for certain types of interaction, as you
either have to completely redisplay after a server round-trip or
closely co-ordinate client-side code to keep some interactions local
to the client.

True, and applications that can't stand that redisplay are an example
of a good reason not to use a web interface. But for many apps, the
redisplay is ok. And a little client-side JS here or there isn't
THAT hard to deal with and can help a lot.

Both packages are maintained be people who know what they are
doing. wxPython has had its issues over the years, but many of those
have (I believe) been due to the instability of the underlying
wxWindows (no wxWidgets) package, which in turn has often been due to
the introduction of serious chunks of new functionality.

Fair enough, but we have to consider wxPython to encompass the whole
suite including wxWidgets and GTK and whatever.

For functionality purposes I've found tkinter to be adequate so far,
but it sure doesn't look as nice on the screen as the other packages.

 

[Paul Rubin]

BTW, do you have any experience with how respective GUI builders
actually work? QT Designer seems great and people seem to use
it in industry, but how useful is PythonCard useful in real-world app
development?

I'd use Glade if I could.

 

[Paul Rubin]

Reason 1: It would be somewhat complex to develop it using
PHP (I have done some recon in that area) and using GUI
on Windows is actually faster way of entering and editing data
than via the Web browser I think.

Well, I was concentrating more on implementation hassle. But I
was thinking in terms of Python, not PHP.

ZOPE could provide the workaround but ZOPE seems really huge to
me and an overkill for this. Or maybe it would work?

Zope seems huge to me too. I'd just use a Python cgi, optionally with
one of the simpler Python template libraries. Just try to keep things
simple, and never allow access except to authorized, trusted users
(i.e. don't run the app on the open internet without SSL and login
authentication) and you won't have to worry too much about security.

 

[Carlos Ribeiro]

On 20 Dec 2004 04:43:06 -0800, Paul Rubin

Reason 1: It would be somewhat complex to develop it using
PHP (I have done some recon in that area) and using GUI
on Windows is actually faster way of entering and editing data
than via the Web browser I think.

Reason 2: I don't want to learn yet another language
just for this app and want to avoid integration problems
as we plan to develop yet another application for other workers
that would connect to the common DB and sent the data directly
for that accounting app.

Two good reasons indeed. There are some types of data entry tasks that
don't map well to the browser. Rich grid style data entry just comes
to mind, it requires a ton of Javascript code, not to mention XMLRPC,
if you want it to be dynamic and responsive. But if the data entry
forms are simple, I recommend you to check some lightweight approaches
for Web development in Python. I personally used CherryPy
(www.cherrypy.org); you can also check Quixote or Snakelets. All three
are much lighter than Zope. CherryPy in particular is extremely light
and easy to work with, and includes a reasonably powerful embedded
Python-based webserver; it's not Apache, but it's much easier to set
up. And all three options are free.


--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[RM]

Here is another question, are you deploying in Linux, Windows, Mac, or
some combination of these? I think that may be a big factor to
consider. I do like the look of Qt under Linux, however, I have never
seen it under Windows. Qt seems to be very focused in Linux, with Mac
and Windows support as a reluctant afterthought.

I have used wxPython and PythonCard under Windows and Linux. Under
Windows, both of these are excellent, and allow you to do some very
nice looking apps. I love the way PythonCard separates the interface
code from the rest of the app functionality. PythonCard is a pleasure
to use. It is not quite finished, but its developers are now in the
final stretch towards the final 1.0 version.

In Python, when you run into its speed limitations, you may have to
resort to writing pure C. Similarly, when you run into a widget
limitation in PythonCard, you may have to resort to pure wxPython code.
In both cases, the advantages of using Python and PythonCard, will
usualy make it worth living with their limitations.

-Ruben

 

[Bulba!]

On Mon, 20 Dec 2004 11:37:23 -0200, Carlos Ribeiro

forms are simple, I recommend you to check some lightweight approaches
for Web development in Python. I personally used CherryPy
(www.cherrypy.org); you can also check Quixote or Snakelets. All three
are much lighter than Zope. CherryPy in particular is extremely light
and easy to work with, and includes a reasonably powerful embedded
Python-based webserver; it's not Apache, but it's much easier to set
up. And all three options are free.

"Your CherryPy powered web applications are in fact stand-alone Python
applications embedding their own web server. You can deploy them
anywhere you can run Python applications." - cool!!

Python is getting damn serious contender in dev arena I see...

 

[Bulba!]

Zope seems huge to me too. I'd just use a Python cgi, optionally with
one of the simpler Python template libraries. Just try to keep things
simple, and never allow access except to authorized, trusted users
(i.e. don't run the app on the open internet without SSL and login
authentication) and you won't have to worry too much about security.

Right, and this way I could keep Python, DB of my choice, have
a Web interface for accounting (if accounting aspect is kept limited
enough to make it practical it) and still connect that another app via
the internet to Pythonic environment.

 

[Bulba!]

Here is another question, are you deploying in Linux, Windows, Mac, or
some combination of these? I think that may be a big factor to
consider. I do like the look of Qt under Linux, however, I have never
seen it under Windows. Qt seems to be very focused in Linux, with Mac
and Windows support as a reluctant afterthought.

Server will run on Linux, clients on Windows (all those Windows
apps that workers typically use...). We're not excluding possible
deployment of some specialized workstations on Linux only,
however (thus one of the reasons for considering either wxWindows
or QT is that they're cross-platform).

I have used wxPython and PythonCard under Windows and Linux. Under
Windows, both of these are excellent, and allow you to do some very
nice looking apps. I love the way PythonCard separates the interface
code from the rest of the app functionality.

That's a strong pro, I don't like aspects of various problems
intertwining too much in a particular place in a program, I like to
keep them separate (that's one reason I don't like PHP very much,
where the "business logic" naturally wants to be "mixed" with PHP
with HTML over the whole damn place - maybe it's possible to
keep all those separate in PHP but I don't see convenient ways of
doing that).

PythonCard is a pleasure
to use. It is not quite finished, but its developers are now in the
final stretch towards the final 1.0 version.

Too much of a good thing I guess. Now the choice between
GUIs is harder for me instead of it being easier. ;-) But it's great
to know that Python can be used for serious GUI and other development,
it seems like it's not going to die...

In Python, when you run into its speed limitations, you may have to
resort to writing pure C.

That's not an issue here, as I obviously am not going to write my
own DB server and I don't think accounting programming really
needs the speed of C.

Similarly, when you run into a widget
limitation in PythonCard, you may have to resort to pure wxPython code.

Hmm.. and if I may ask, what limitations you have stumbled on?

 

[Phil Thompson]

Here is another question, are you deploying in Linux, Windows, Mac, or

some combination of these? I think that may be a big factor to
consider. I do like the look of Qt under Linux, however, I have never
seen it under Windows. Qt seems to be very focused in Linux, with Mac
and Windows support as a reluctant afterthought.

Sorry, I can't let such an uninformed statement pass without some sort of
comment. While Qt is probably installed on more Linux desktops than
Windows desktops (because of KDE), Trolltech sell more Windows licenses
than Linux/UNIX licenses. One of the main points of Qt is that it runs
equally well on all platforms.

To the OP, get wxPython and PyQt/Qt for Windows, try them both out and go
with the one that best fits your criteria. There are free, fully
functional, evaluation versions of both Qt and PyQt.

Phil

 

[Paul Rubin]

"Your CherryPy powered web applications are in fact stand-alone Python
applications embedding their own web server. You can deploy them
anywhere you can run Python applications." - cool!!

You might not really want a separate socket listener for each application.

 

[RM]

Hmm.. and if I may ask, what limitations you have stumbled on?

In reality, PythonCard is just an easier way of manipulating wxPython.
The thing is that PythonCard needs to have a wraper for each wxPython
widget that it uses, and, then that wrapper needs to be incorporated
into the PythonCard designer (Resourse Editor). At the moment, I don't
think all wxPython widgets are implemented yet. The good thing is
that, for cases like that, you can simply use regular wxPython code to
reach the desired widget.

What I would recommend, as others have, is to download it and try it,
along with the other options you are considering. There are some very
nice introductions you can quickly go through to get a feel for what
you can do in PythonCard here:
http://pythoncard.sourceforge.net/documentation.html

-Ruben

 

[Thomas Heller]

I'll soon start development of a specialized small app and need
to choose GUI for it.

Quoting a somewhat popular german blogger, on the state of cross
platform Python GUI toolkits (http://blog.schockwellenreiter.de/7282):

Ansonsten habe ich nach einiger Überlegung entschieden, daß ich in
Zukunft Programme, die graphische Ausgaben und eine GUI benötige, in
Java schreiben werde. Ich habe zu lange auf Besserung der
(plattformübergreifenden) GUI-Situation in Python gewartet. Tkinter ist
nur noch krank, wxPython scheint zwar nicht schlecht zu sein, doch es
mangelt an jeder Dokumentation (und ich habe weder Zeit noch Lust, mich
durchzuwursteln) und PyQt ist zwar etwas besser dokumentiert, aber nicht
so weit verbreitet und es besitzt eine etwas seltsame Lizenz. Swing
dagegen ist hervorragend dokumentiert, Eclipse hat sich zu einer
brauchbaren IDE gemausert und Java selber hat -- trotz der geschweiften
Klammern -- doch soviel von Oberon geerbt, daß ich nicht gleich Pickel
bekomme, wenn ich darin programmieren muß. ;o)


Thomas

 

[RM]

I admit that I don't know much about Qt in Windows. As, I said, I've
never seen it. The fact that they don't offer a GPLed version for
Windows is a deterrent for me.

I have heard very nice things about Qt's api. I even bought a book on
it, but since the apps I've needed to write, had to be cross platform,
and were nicely done in wxPython/PythonCard on Windows *for free*, I
haven't been able to justify the time to look at it.

Question for you, does Qt use the native Windows dialogs and widgets or
does it use its own? If the latter, how close are they to the native
look? Will they change appearance when a user chooses a different
theme in the Display Dialog?

 

[Diez B. Roggisch]

Question for you, does Qt use the native Windows dialogs and widgets or

does it use its own? If the latter, how close are they to the native
look? Will they change appearance when a user chooses a different
theme in the Display Dialog?

AFAIK they do all stuff themselves. And also AFAIK photoshop is created
using qt.