Ten Essential Development Practices

[Ed Leafe]

Bar and line graphics, mainly.  In an easy and portable way.  Something
that calculates the axis scales automatically, that allows users to change
some information, add legends, put values in specific points and all those
things that are common to business graphs.

OIC - I thought that you were referring to a specific part of wxPython that
we haven't wrapped yet.

I'll defer this to my partner, Paul McNett. He's spearheading the reporting
module for Dabo, and may know of some tools that are already out there that
could generate the image, which Dabo could then display.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

 

[Jorge Godoy]

Ed Leafe wrote:

I'll defer this to my partner, Paul McNett. He's spearheading the
reporting
module for Dabo, and may know of some tools that are already out there
that could generate the image, which Dabo could then display.

There are some out there. There's one implementation that is compatible
with Matlab and is also compatible with wxPython. Take a look at
matplotlib: http://matplotlib.sourceforge.net/

 

[Jorge Godoy]

Ed Leafe wrote:

I'll defer this to my partner, Paul McNett. He's spearheading the
reporting
module for Dabo, and may know of some tools that are already out there
that could generate the image, which Dabo could then display.

There are some out there. There's one implementation that is compatible
with Matlab and is also compatible with wxPython. Take a look at
matplotlib: http://matplotlib.sourceforge.net/

 

[Bugs]

But how stable is GTK on systems such as Windows and OS/X? That has
been what has kept me from using it. Most GTK apps I've used on Windows
(including the venerable GIMP) are nowhere near as stable as their Linux
counterparts (although this may not be entirely the fault of GTK).
Also, GTK on OS/X requires Fink, which is a pretty hefty requirement to
place on an end user.

wxWidgets only uses GTK on Linux. On Windows and OS X it uses native
widgets where possible.

 

[Mike Meyer]

Hallöchen!

I disagree. A modern language must provide a convenient and
well-embedded way to write GUI applications.

I disagree. A modern development environment aimed at developers of
desktop applications may be required to provide that; not being a
developer of desktop applications, I'm not really qualified to say. A
*language* doesn't need to provide that. I'd say that a language
providing that would limit the language. Or cause it to branch when it
got ported to platforms for which the graphics elements of the
language were totally unsuitable.

The tools for writing GUI applications belong in a library, not the
langauge.

This is not a sign of decadence, but a very good promotional argument.

But it's not required for the language to succeed. C and C++ are both
doing very well without your a well-embedded way to write GUI
applications.

However, you can get compilers for both that come bundled with a good
GUI library. Could it be that that's what you really want - someone to
distribute Python bundled with an enterprise-class GUI library and
IDE?

However, in my opinion we don't need yet another binding so thin
that C or C++ is shining through, but a modern replacement for
Tkinter with its Pythonic way of thinking.

I don't particularly like Tkinter, but it seems to me that it's pretty
much won. It seems to be installed on every desktop platform along
with Python. That means that if I want to distribute GUI apps, I'm
going to cause the least headache for my end users by writing them in
Tkinter.

<mike

 

[phil hunt]

Hallöchen!

[...]

How about sometihing with the same API as Tkinter (so no need to
relearn), but which looks prettier? Would that fix your gripes?

I haven't learned Tkinter.

You mightn't have, but I suspect more Python programers who've
written GUI apps have used Tkinter than any of the other APIs.

Not that I'm a particular fan of it, it's just I like
standardisation, because then you get network effects.

So for me, it needn't be like Tkinter. The three most important
attributes for me are Pythonic, modern (both nice-looking and
comprehensive), and non-niche.

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

 

[Torsten Bronger]

Hallöchen!

I disagree. A modern language must provide a convenient and
well-embedded way to write GUI applications.

[...]

The tools for writing GUI applications belong in a library, not
the langauge.

None of us has talked about changing syntax. However, the standard
library is part of the language unless you're really very petty.

But it's not required for the language to succeed.

Today it is (except for very special-purpose languages).

C and C++ are both doing very well without your a well-embedded
way to write GUI applications.

I don't think that much money is made with new C programs. Almost
all money with C++ is made with VC which has been having a GUI
toolkit in its standard library right from the beginning. And most
money is made with VB AFAIK.

However, you can get compilers for both that come bundled with a
good GUI library. Could it be that that's what you really want -
someone to distribute Python bundled with an enterprise-class GUI
library and IDE?

Well, a nice thing to have, but besides my point.

We do have a standard library with a robust GUI package, and a
standard distribution with a so-called IDE. What I really want is a
better GUI included into the standard library.

I don't particularly like Tkinter, but it seems to me that it's
pretty much won. It seems to be installed on every desktop
platform along with Python. That means that if I want to
distribute GUI apps, I'm going to cause the least headache for my
end users by writing them in Tkinter.

A "replacement for Tkinter" would have the same properties,
otherwise it wouldn't be a replacement.

Tschö,
Torsten.

 

[Torsten Bronger]

Hallöchen!

[...]

How about sometihing with the same API as Tkinter (so no need to
relearn), but which looks prettier? Would that fix your gripes?

I haven't learned Tkinter.

[...]

Not that I'm a particular fan of it, it's just I like
standardisation, because then you get network effects.

Me too. Therefore I'd like to see a new toolkit in the standard
library to see a new network growing. You mustn't do something like
this too often of course but I think in this case it would be the
right time.

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

I don't like to set arguments to -1 or NULL, but to None. I'd like
to have extensive support for keyword arguments. I don't like
mucking about with ID values. Partly this is cosmetical but partly
it's a rich source of errors.

Tschö,
Torsten.

 

[Cliff Wells]

I don't particularly like Tkinter, but it seems to me that it's pretty
much won. It seems to be installed on every desktop platform along
with Python. That means that if I want to distribute GUI apps, I'm
going to cause the least headache for my end users by writing them in
Tkinter.

By this argument, we should just give up and use Visual* on Windows.

The least headache for end users comes from properly packaging your
application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same. It should be irrelevant to end users what
libraries or tools you use to develop the app.

Regards,
Cliff

 

[Cliff Wells]

wxWidgets only uses GTK on Linux. On Windows and OS X it uses native
widgets where possible.

You missed my point. I'm advocating wxPython over PyGTK for this
reason. I'm quite aware of how wxPython functions.

Regards,
Cliff

 

[Paul Rubin]

What you say Pythonic, what do you mean? And how do you rate
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"?

Tkinter is not very Pythonic because it's sort of a Frankenstein
hybrid of Python and Tcl, but at least it's there and it more or less
works. The others are non-Pythonic because they're not included in
the standard distro and therefore the Pythonic "use the included
batteries" tenet says to use Tkinter despite its flaws.

 

[Torsten Bronger]

Hallöchen!

[...]

The least headache for end users comes from properly packaging your
application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same.

Does py2exe work for all GUI libraries? It'll highly probably work
with Tkinter, and I've read that it also works with pyGTK, but does
it also work with wxPython or PyQt?

Tschö,
Torsten.

 

[Paul Rubin]

Does py2exe work for all GUI libraries?

No, it's Windows-only.

 

[Paul Rubin]

application. End users shouldn't need to worry about installing third
party packages (or even Python for that matter). Tools such as py2exe
and Inno installer make this pretty simple on Windows, and py2app on
OS/X accomplishes the same. It should be irrelevant to end users what
libraries or tools you use to develop the app.

What if I want to be able to write multi-platform applications without
having to deal with OS-specific packaging schemes for every OS that I
want to run on? Even if I only want to run on Linux, I don't see how
to package a wxPython application to minimize end user hassle. The
only realistic GUI's to use are Tkinter or HTTP/HTML over a local
socket talking to a user-provided web browser.

 

[phil hunt]

I don't like to set arguments to -1 or NULL, but to None.

Fair enough

I'd like
to have extensive support for keyword arguments.

Tkinter has that

 

[phil hunt]

Tkinter is not very Pythonic because it's sort of a Frankenstein
hybrid of Python and Tcl, but at least it's there and it more or less
works. The others are non-Pythonic because they're not included in
the standard distro and therefore the Pythonic "use the included
batteries" tenet says to use Tkinter despite its flaws.

OK, hows this for an idea:

1. create a new API, loosely based on the Tkinter API, but more
Pythonic

2. implement Tk using this API (probably won't be difficult because
we can use Tkinter as a base)

3. Implement bindings to Gtk and Qt/KDE using this API.

 

[phil hunt]

Like PyGUI, more or less?

http://www.cosc.canterbury.ac.nz/~greg/python_gui/

Not really, PyGUI attempts to be a thing in itself; what I had in
mind was more of a slight reworking of Tkinter to make it more
Pythonic (and at the same time give it better documentation which
odesn't depend on refering to the Tcl/Tk documentation).

 

[Torsten Bronger]

Hallöchen!

No, it's Windows-only.

However, OS'es and GUI libraries are different axes in the space of
possibilities.

Tschö,
Torsten.

 

[Robert Kern]

OK, hows this for an idea:

1. create a new API, loosely based on the Tkinter API, but more
Pythonic

2. implement Tk using this API (probably won't be difficult because
we can use Tkinter as a base)

3. Implement bindings to Gtk and Qt/KDE using this API.

Like PyGUI, more or less?

http://www.cosc.canterbury.ac.nz/~greg/python_gui/

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Paul Rubin]

However, OS'es and GUI libraries are different axes in the space of
possibilities.

I'm not sure what you mean. Whatever GUI library the Mac uses, py2exe
doesn't work with it, since py2exe doesn't work for Macs.