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.


--
It's a man's life in a Python Programming Association.

[Paul Rubin]

Bulba! <bu***@bulba.com> writes:

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.

--
Regards,

Diez B. Roggisch

[Steve Holden]

Paul Rubin wrote:

Bulba! <bu***@bulba.com> writes:

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.

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
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[Bulba!]

On 20 Dec 2004 04:43:06 -0800, Paul Rubin
<http://ph****@NOSPAM.invalid> wrote:

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?
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!

--
It's a man's life in a Python Programming Association.

[Bulba!]

On Mon, 20 Dec 2004 08:03:38 -0500, Steve Holden <st***@holdenweb.com>
wrote:

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?

--
It's a man's life in a Python Programming Association.

[Paul Rubin]

Steve Holden <st***@holdenweb.com> writes:

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.

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]

Bulba! <bu***@bulba.com> writes:

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]

Bulba! <bu***@bulba.com> writes:

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 Mon, 20 Dec 2004 14:20:43 +0100, Bulba! <bu***@bulba.com> wrote:

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

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.

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: ca********@gmail.com
mail: ca********@yahoo.com

[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
<ca********@gmail.com> wrote:
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.

"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...

--
It's a man's life in a Python Programming Association.

[Bulba!]

On 20 Dec 2004 05:36:48 -0800, Paul Rubin
<http://ph****@NOSPAM.invalid> wrote:

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.


--
It's a man's life in a Python Programming Association.

[Bulba!]

On 20 Dec 2004 05:53:03 -0800, "RM" <ny**********@yahoo.com> wrote:

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?

--
It's a man's life in a Python Programming Association.

[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]

Bulba! <bu***@bulba.com> writes:

"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]

Bulba! wrote:

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]

Bulba! <bu***@bulba.com> writes:

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.
--
Regards,

Diez B. Roggisch

[Carlos Ribeiro]

On 20 Dec 2004 07:47:53 -0800, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:

Bulba! <bu***@bulba.com> writes:

"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.

You don't need a separate socket listener... CherryPy is fairly easy
to work with, and very pythonic IMHO. For a multi application
scenario, I would recommend installing each application as a subtree
of the main site: http://myserver:8000/app1,
http://myserver:8000/app2, and so on. It is possible to build it in
such a way that you can update a part of the site without the need to
bring it down, just by reloading the module and rebinding the value
stored at the cpg.root.<mountpoint> variable.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com

[Kevin Walzer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Diez B. Roggisch wrote:
|>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.
|
|
PhotoShop is not created with Qt. I believe it's created with CodeWarrior.

PhotoShop Album is created with Qt--a very different beast.

- --
Cheers,

Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:[e-mail]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBxzrmJmdQs+6YVcoRAtcDAJ96YHfTfxxHKU4HT3uteB nmh95diQCfd+D+
lAhzXIeXPmihJgmTFhC8wJU=
=RU7/
-----END PGP SIGNATURE-----

[John Machin]

Thomas Heller wrote:

Bulba! <bu***@bulba.com> writes:

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): [snip] mangelt an jeder Dokumentation (und ich habe weder Zeit noch Lust, mich durchzuwursteln) und PyQt ist zwar etwas besser dokumentiert, aber

nicht

Babelfish gave up on "durchzuwursteln" and so did I --
"through-to-sausage-???" -- but the gist was plain enough :-(

[Luke Skywalker]

On 20 Dec 2004 13:28:02 -0800, "John Machin" <sj******@lexicon.net>
wrote:

Babelfish gave up on "durchzuwursteln" and so did I --
"through-to-sausage-???"

This is getting erotic ;-)

Luke.

[Peter Otten]

John Machin wrote:

Thomas Heller wrote:

Bulba! <bu***@bulba.com> writes:

> 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):

[snip]

mangelt an jeder Dokumentation (und ich habe weder Zeit noch Lust,

mich

durchzuwursteln) und PyQt ist zwar etwas besser dokumentiert, aber

nicht

Babelfish gave up on "durchzuwursteln" and so did I --
"through-to-sausage-???" -- but the gist was plain enough :-(

Unauthorized translation, not idiomatic, but should beat babelfish any time:

"After some consideration I have decided that I am going to write programs
that need graphical output and a GUI in Java. I have been waiting for too
long for an improvement of the state of (cross-platform) GUIs in Python.
Tkinter is nothing but ill, wxPython doesn't seem too bad, but lacks
documentation (and I have neither time nor motivation to muddle through),
and PyQt, while a bit better documented, is not as widespread and governed
by a somewhat strange license. Swing on the other hand has an excellent
documentation, Eclipse has become usable, and Java itself has -- braces not
withstanding -- inherited just enough from Oberon that I don't suffer from
an allergic reaction when I have to use it."

Not my opinion by the way, I'm planning to give the sausage a try...

Peter

[tfillmor]

Personally I think the priority of all new project developmnent should
be based principally on web technologies, with OS-specific (i.e.,
desktop) versions only if there is absolutely no other way.

You should really try CherryPy (http://www.cherrypy.org) - for
Python-based web development I don't think you will be disappointed.
It's platform-agnostic, provides its own threaded webserver, supports
just about every templating schema out there for Python (and even
optionally one of it's own), is actively developed and projects can
even be run off a CD when deployed, if necessary.

I've written some smallish things using CherryPy and found it to be
easy to work with... The current version is 2.0 alpha (read the site
about this, some pretty serious changes were made between 1.x and 2.0
that only improve the project), but I always use the development
versions from svn. I know, I know, they are only development versions,
and shouldn't be deployed, right? This really doesn't worry me much as
there is a really good pace on the project's development and
essentially daily snapshot releases that, as of yet, have only improved
the speed of what I've coded when my code is run against the newer
versions. In fact I've never seen a cherryPy server/process crash,
although my code certainly does... 8-)

Give it a whirl!!

Tom Fillmore
Paul Rubin wrote:

Bulba! <bu***@bulba.com> writes:

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.

[Phil Thompson]

> 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?

By default Qt uses it's own except for the file dialog. By default the
native file dialog is used (but it can be disabled by reseting a bool that
isn't wrapped by PyQt). The same applies to MacOS.

Phil

[Richie Hindle]

[Gerhard, quoting a blog]

wxPython doesn't seem bad, but it lacks any documentation

I see this a lot, and it baffles me. wxPython is a thin wrapper over
wxWidgets, which is very well documented. Where they differ, the
wxWidgets documentation discusses those differences. Add the excellent
wxPython demo, and you've got better documentation than some commercial
toolkits (MFC, for instance).

Is it just a communication problem - do newcomers not realise that the
wxWidgets documentation applies to wxPython?

(The latest version of the wxPython demo even lets you modify the demo
code at runtime, and compare the behaviour of your modified version with
the original, all without leaving the demo - fantastic! Huge thanks to
whoever did that.)

--
Richie Hindle
ri****@entrian.com

[Dave Cook]

On 2004-12-20, Bulba! <bu***@bulba.com> wrote:

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

I've had success with pygtk on win32 and Linux (and OS X with the X11
server installed.)

http://www.pcpm.ucl.ac.be/~gustin/win32_ports/
http://gladewin32.sourceforge.net/index.php (for the C devel and runtime
packages)

The pygtk manual, tutorial, and FAQ are all very good. You don't have to
wade through C or C++ documentation.

The only complaints I have are that the glade GUI builder hasn't caught up
with gtk development (particularly the new UIManager), and that the list
widget is relatively slow.

Lately I've been evaluating jython and Swing, though.

Dave Cook

[Dave Cook]

On 2004-12-20, Paul Rubin <http> wrote:

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.

Web browser "widgets" seem pretty limited to me, though. You don't even
have something as simple as a combo box (i.e. an editable entry with a drop
down), let alone the rich set of widgets something like wxwidgets offers.
Also web development doesn't seem as coherent to me as development with a
good GUI framework.

Dave Cook

[Ed Leafe]

On Dec 20, 2004, at 7:25 AM, Bulba! wrote:

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.

You might want to check out Dabo, an application framework of which I
am one of the authors. We use wxPython as our UI toolkit, but have
streamlined the programming of the UI. We've also added data binding,
making developing apps that need to work with a database much, much
simpler.

Even though Dabo is still in development, I've used it to create an
app that helps me manage the archives of the technical email lists I
host (currently holding over a quarter-million rows).

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

[Jarek Zgoda]

Bulba! wrote:

- 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)?

From my point of view, PyQt is easier to use (and is simpler, runs
faster, looks better on Linux etc), while wxPython is much cheaper (and
runs faster on Windows). As I am guerilla Python programmer (and try to
drive as much Python into company as I can), I use wxPython on Windows
platform as it doesn't trigger unnecessary questions on licensing,
pricing et caetera.

wxPython has very nice GUI builder (wxGlade), it is not about as
complete as Qt Designer, but speeds-up development significantly.

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

[Paul Rubin]

Dave Cook <da******@nowhere.net> writes:

Web browser "widgets" seem pretty limited to me, though.
You might not care.
You don't even have something as simple as a combo box (i.e. an
editable entry with a drop down),
Just put an input field and a dropdown on the page.
let alone the rich set of widgets something like wxwidgets offers.
The rich set of widgets is sort of like a rich set of fonts in a word
processor. Most of the time, your document can function perfectly
well with just one font.
Also web development doesn't seem as coherent to me as development
with a good GUI framework.

I'm not sure what that means. But yeah, any gui (web or client side)
tends to need a lot of tweaking.

[Bulba!]

On Tue, 21 Dec 2004 16:20:48 -0500, Ed Leafe <[e-mail]> wrote:

You might want to check out Dabo, an application framework of which I
am one of the authors. We use wxPython as our UI toolkit, but have
streamlined the programming of the UI. We've also added data binding,
making developing apps that need to work with a database much, much
simpler.

This advice of yours (thanks) may have "slashdotted" your site by
flood of requests from Python programmers all looking at your
website. ;-)

"Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /."

--
It's a man's life in a Python Programming Association.

[kdahlhaus]

> ZOPE could provide the workaround but ZOPE seems really huge to

me and an overkill for this. Or maybe it would work?

I am intenionally *not* trying to argue web vs traditional gui for your
app, but to tuck away for future apps, CherryPy2 is a lot easier than
Zope to use and programming it does not require much of a learning
curve.

Recently I did a simple app that started as wx Windows, got bogged
down, and switched to CherryPy/Cheetah running locally on the users
station. I know more about wxWindows now than before, so perhaps
things would be different now, but at the time the gui was really
slowing my down my development. I had a hard time getting my hands
around the wxWindows sizers. They are simple in concept, but not easy
to learn at first in practice.

I went w/wxPython for a second app because of its printing capabilities
and the large number of controls that come with it. Otherwise I would
use pyFltk for small apps.

[huy]

Dave Cook wrote:

On 2004-12-20, Paul Rubin <http> wrote:

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.

Web browser "widgets" seem pretty limited to me, though. You don't even
have something as simple as a combo box (i.e. an editable entry with a drop
down), let alone the rich set of widgets something like wxwidgets offers.
Also web development doesn't seem as coherent to me as development with a
good GUI framework.

I think it depends on your target audience. Many people love simplicity.
Many people hate multiple tabs, tree structures, deep nested menus etc
etc. If you wanted to make a web program as complex as a rich client
program then it's probably a bad idea to do as a web program. But If you
wanted to keep it simple, then I'd go with a web program any day.
Huy

[Steve Holden]

huy wrote:

Dave Cook wrote:

On 2004-12-20, Paul Rubin <http> wrote:

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.

Web browser "widgets" seem pretty limited to me, though. You don't even
have something as simple as a combo box (i.e. an editable entry with a
drop
down), let alone the rich set of widgets something like wxwidgets offers.
Also web development doesn't seem as coherent to me as development with a
good GUI framework.

I think it depends on your target audience. Many people love simplicity.
Many people hate multiple tabs, tree structures, deep nested menus etc
etc. If you wanted to make a web program as complex as a rich client
program then it's probably a bad idea to do as a web program. But If you
wanted to keep it simple, then I'd go with a web program any day.

Indeed the best advice to many programmers is to spend A LOT of time
considering the user interface, since that's what will often have the
major impact on user experience, and hence ultimately on acceptance.

I still moan about having to use EIGHT mouse clicks in Mozilla 1.7 to
change my default SMTP host to the other one on a list of two. Which
remionds me, time to check out the latest release ...

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[Dave Cook]

On 2004-12-21, Paul Rubin <http> wrote:

Dave Cook <da******@nowhere.net> writes:

Web browser "widgets" seem pretty limited to me, though.

You might not care.

And in that case Tk is much simpler than just about anything else, unless
looks are really important.

You don't even have something as simple as a combo box (i.e. an
editable entry with a drop down),

Just put an input field and a dropdown on the page.

Takes up twice as much space and is potentially confusing as the dropdowns
tend to look like real combo boxes in IE and Mozilla (only Konquerer seems
to make it visually clear that you can't edit the text.)

Also web development doesn't seem as coherent to me as development
with a good GUI framework.

I'm not sure what that means.

Basically it means that I find it harder and less intuitive. I don't think
I'm stupid, just pragmatically lazy.

Dave Cook

[Paul Rubin]

Dave Cook <da******@nowhere.net> writes:

You might not care.
And in that case Tk is much simpler than just about anything else, unless
looks are really important.

I've used tk and I don't think it's simpler than html.
Takes up twice as much space and is potentially confusing as the dropdowns
tend to look like real combo boxes in IE and Mozilla (only Konquerer seems
to make it visually clear that you can't edit the text.)

I guess I'm not clear on when this is needed.

Also web development doesn't seem as coherent to me as development
with a good GUI framework.

I'm not sure what that means.

Basically it means that I find it harder and less intuitive. I
don't think I'm stupid, just pragmatically lazy.

I don't think you're stupid either, but it looks like what's intuitive
for you might be less intuitive for (some) other people, and vice
versa.

[Al Christians]

>>> Web browser "widgets" seem pretty limited to me, though. You don't even

have something as simple as a combo box (i.e. an editable entry with
a drop
down), let alone the rich set of widgets something like wxwidgets
offers.
Also web development doesn't seem as coherent to me as development
with a
good GUI framework.

I think it depends on your target audience. Many people love
simplicity.

wxPython has an HTML control that lets you do most of your UI web-like
and just drop in the other wxWidgets kinds of controls here and there if
you need to. The html control does most of the rendering and such, and
you can do most of the user interaction with standard clickable links,
etc, but you can also mix in the full boat of high-powered gizmos to
perplex the users when you run out of other tactics and annoyances.

Is it pretty? As a conglomerate with features of a desktop app and
features of a browser-based app, it's kind of pretty like a platypus.
Platypus, penguin, or python, there's many a way to lay an egg.
Al

[McBooCzech]

Sorry to bother, but I didn't find the final answer to the question
what is the "Best GUI for small-scale accounting app"?

I am the newbie in Python, so I am trying to find some "usable" GUI as
well. But it looks to me there is a lot developers, beta-versions,
tools etc. I have spent a lot of time trying to find which is the
"best" one tool. But now it looks more confusing to me than at the
beginning.

I do not have time to try/test all of them, it is so time-consuming
and confusing specially for total beginner.

IMHO this is the worst think for the Python community: you can find
one Python only with an excellent support. Great!!!! But on the other
hand it is possible to find plenty of GUI tools and for the beginner
(and may be not just for the beginner) it is so hard to choose the
"proper" one!!!!! The field of GUI tools is so fragmented!!!! that I
am close to give it up and start with some commercial product like
Delphi/Kilyx.

BTW you did not discussed Boa, Wingware and BlackAdde (last two are
commercial) here? Are they bad?

Petr

[Paul Rubin]

"McBooCzech" <pe**@tpc.cz> writes:

I am the newbie in Python, so I am trying to find some "usable" GUI as
well. But it looks to me there is a lot developers, beta-versions,
tools etc. I have spent a lot of time trying to find which is the
"best" one tool. But now it looks more confusing to me than at the
beginning.

If all you want is "usable", use Tkinter. And if you're a newbie, use
Tkinter. After you've gotten some experience with Tkinter is the time
to start worrying about "best".

[JanC]

McBooCzech schreef:

IMHO this is the worst think for the Python community: you can find
one Python only with an excellent support. Great!!!! But on the other
hand it is possible to find plenty of GUI tools and for the beginner
(and may be not just for the beginner) it is so hard to choose the
"proper" one!!!!! The field of GUI tools is so fragmented!!!!

I think the field of GUI frameworks / tools for Python is fragmented
because it's fragmented outside of Python too...
--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Paul Rubin]

Ed Leafe <[e-mail]> writes:

Oh, geez. After months of us getting skewered for releasing
Dabo under GPL, with everyone saying that they wouldn't even *look* at
it for fear of 'infecting' all of their code, we change the license to
the MIT license, and now the complaint is that Microsoft is going to
sell the code!
Well, those are commercial developers who are afraid of the GPL. If
they want to require people to pay to use the code they release, then
they, just like Microsoft, should also expect to pay the developers of
the components they use. If I were you I would have stood firm on the
GPL, unless they offered you funding.
Ever get that feeling that you can't win? ;-)
I don't see how you lose with the GPL, unless you count missing out on
the exciting opportunity to be an unpaid employee of someone else's
corporation, without even getting back improvements made to your code.

I hope Dabo can read the xml files Glade generates, so you have a gui
builder that's already deployed.

That's definitely part of the development plan. But after
looking at Glade and several other designers, our conclusion is that
they all lack something: either flexibility, ease of use, or something
else. Sizers were probably the item that was the most difficult thing
to handle well. The best designer for sizers we found was Qt
Designer. We'd like to make our designer as visually clear as that one.

I'm not sure what sizers are, but why not just add them to Glade?
Also, Dabo is not just a UI toolkit: it's a full 3-tier
application framework. Our major design goal is to integrate the
database connections defined into the UI designer, so that you can
drag and drop fields from the tables in the connection onto the design
surface, and create data-bound controls in one step.

Ehhh, sounds a little too much like javabeans :).

[Ed Leafe]

On Dec 28, 2004, at 1:16 PM, Paul Rubin wrote:

Well, those are commercial developers who are afraid of the GPL.
No, they were several members of the Python community. I disagreed
with their interpretation of the GPL, but the fact remains that it was
a major stumbling block to getting others involved.
I don't see how you lose with the GPL, unless you count missing out on
the exciting opportunity to be an unpaid employee of someone else's
corporation, without even getting back improvements made to your code.
The downside is gaining critical mass for the project. Having several
visible Python folks refuse to even look at what we were doing was not
helping things at all. And I think it the chances of someone else using
my code without payment or anything is a pretty small risk. We still
own copyright, which means that while they can use it, they can't claim
it's theirs.
I'm not sure what sizers are
OIC - then this is not going to be very fruitful.
Ehhh, sounds a little too much like javabeans :).

No, it sounds like every other development environment for creating
database applications. I looked a long time for something like this in
Python before undertaking the writing of it myself.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

[JanC]

Ed Leafe schreef:

I think the field of GUI frameworks / tools for Python is fragmented
because it's fragmented outside of Python too...

I think that the reason things are fragmented in this field is that
none of the tools are simple enough to learn.

Even on Windows, where several well-known and/or easy to use "Rapid GUI &
Database Development Tools" exist (Delphi, VB, Access, Visual FoxPro,
FileMaker, ...), the framework field is fragmented: Microsoft's Win32, MFC
& WTL, Borland's VCL & CLX, wxWidgets, System.Windows.Forms, several Java
frameworks, ...

But even then, if DaBo ever becomes as easy to use as Delphi/VB for this
type of applications, while remaining cross-platform, that might easily
double the number of Python developers. ;-)
--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Ed Leafe]

On Dec 28, 2004, at 5:52 PM, JanC wrote:

But even then, if DaBo ever becomes as easy to use as Delphi/VB for
this
type of applications, while remaining cross-platform, that might easily
double the number of Python developers. ;-)

Well, there are at least a half-million Visual FoxPro developers who
have been hung out to dry by Microsoft, most of whom would love to
leave the land of proprietary closed solutions for a bit of fresh air.
That's where Paul and I came from, and that was our initial motivation
for deciding to develop Dabo - there wasn't a Python tool out there
that could even begin to approach what we were used to with VFP. If we
could get Dabo to the point where someone familiar with VFP or even VB
could become productive in a short time, well, I'm certain that there
will be lots of new blood in these parts. Our work is being followed
very closely by those communities.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

[Luke Skywalker]

On Tue, 28 Dec 2004 20:06:57 -0500, Ed Leafe <[e-mail]> wrote:

That's where Paul and I came from, and that was our initial motivation
for deciding to develop Dabo - there wasn't a Python tool out there
that could even begin to approach what we were used to with VFP.

Interesting discussion. I haven't looked at Dabo yet, but the issues
that must be solved before Python is a valid alternative to
proprietary solutions like Delphi or VB are:

- speed where it matters (ie. no 20s load time)

- good RAD (IDE and GUI designer, on par with Delphi or VB)

- high-quality, varied widgets

- good DB connectors

- reasonable footprint (ie. no 20MB program just for a small
appplication; have mercy on users stuck with P3 and dial-up)

- ease of deployment and maintenance (ie. how easy is it for an
application to launch some updated that will fetch updates from the
web)

If Dabo can do all this, it could be a great solution to all those
people Delphi/VFP/VB users whether to go .Net.

Luke.

[Ed Leafe]

On Dec 28, 2004, at 9:04 PM, Luke Skywalker wrote:

Interesting discussion. I haven't looked at Dabo yet, but the issues
that must be solved before Python is a valid alternative to
proprietary solutions like Delphi or VB are:

- speed where it matters (ie. no 20s load time)
Load what? The app, or the data? Users don't care how long the app
takes to start up, since they usually run it all day long. Data
response is a whole 'nother matter, and Dabo is extremely fast in that
regard. After all, a data set is nothing more than lists of lists, and
Python is wicked fast with list handling.
- good RAD (IDE and GUI designer, on par with Delphi or VB)
Still in its infancy in Dabo. Would be nice to have a team working on
it, cos there's only so much a single developer who also has a life can
do.
- high-quality, varied widgets
One of the main reason we picked wxPython as our initial toolkit.
Nearly everything we could want is in there, and they look good on all
platforms.
- good DB connectors
That's not something we control. Dabo is designed to use existing
dbapi-compliant connectors, such as MySQLdb. We currently support
MySQL, PostgreSQL, and Firebird. If anyone has a need to link to
another db, the script to do it is pretty well abstracted.
- reasonable footprint (ie. no 20MB program just for a small
appplication; have mercy on users stuck with P3 and dial-up)
Don't know where we'll come in in this regard. Most database apps
require some sort of runtime engine, and we'll be no different.
- ease of deployment and maintenance (ie. how easy is it for an
application to launch some updated that will fetch updates from the
web)
That seems to me more in the domain of apps created with Dabo, not
Dabo itself. Python already has everything you need to do this, but you
need to create the appropriate scripts for your server and your app.
If Dabo can do all this, it could be a great solution to all those

Of course, we're still pretty early in development; we have 0.3
scheduled to be released in the first week of January. But we do have
our sights set pretty high.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/