GUI speed

[Kevin Altis]

Despite Tim's enthusiasm for PythonCard, I have to caution you that
PythonCard is still alpha-quality meaning that the API will change. The
framework is not in a state right now where you should plan on building
something and then have it work without any code changes even 3 months from
now, let alone a year or more. The API and the format of key elements such
as the resource file WILL CHANGE; that isn't an if, that is a surety and
there is no attempt at backwards compatability with each release at this
early stage, there will be once we reach a 1.0 release.

While you can download PythonCard today and use the samples and tools and I
encourage you to do so, it is not ready for a big project and anyone using
PythonCard is encouraged to be on the mailing list so they can keep track of
changes. If possible, they should also checkout the package from cvs to get
bug fixes and changes rather than waiting for the releases which only occur
once every couple of months.

Also, the resource file is not presently using XML, but may migrate to using
the wxPython/wxWindows XML resource format in the future, that is just
another item open for debate on the mailing list.

PythonCard is open for developers that want to help define and write code
for the framework and tools.

If you just need a stable API then you can use wxPython directly,
incorporating some elements of PythonCard in your own classes that your
group maintains. I am slowly adding some wrappers and code such as the
function wrappers for wxPython dialogs to the main wxPython distribution and
that code does not rely on PythonCard

ka
---
Kevin Altis
http://radio.weblogs.com/0102677/
http://www.pythoncard.org/

"Tim Churches" <tchur at optushome.com.au> wrote in message
news:mailman.1042079655.13981.python-list at python.org...
On Wed, 2003-01-08 at 15:32, Gerhard Häring wrote, not entirely
helpfully,:
> Rick Richardson wrote:
> >
> > I'm currently reviewing technologies for a large, gui intensive
application.
> > We're planning on having a template driven dynamic gui system, but
having
> > written Java gui's in the past I'm concerned that python may share
java's
> > affliction and be slower than molassses in January.
> >
> > Can anyone out there comment on the relative speed of Java's gui libs
and
> > any one of the python gui libs?
>
> Sure I can. Try it out.

If you are "planning on having a template driven dynamic gui system"
then you might want to look seriously at PythonCard (see
http://pythoncard.sourceforge.net/ ), which is an XML template driven
dynamic GUI system. PythonCard is built on top of wxPython, which is a
binding for wxWindows, which is a cross-platform wrapper around native
GUI calls. The end result is very fast. On Windows systems, wxPython is
a piece of cake to install (it may require some library updates and
hence a bit more effort on some Linux and unix system, but not too
hard). PythonCard is simplicity itself to install once you have
wxPython.

Others will comment on pyQT and Tkinter, neither of which I have used
much. If it is a big project, it is worth spending time investigating
and testing all these, and comparing them against Java GUIs, before
making a decision. Don't forget to investigate licensing issues, which
is a factor with PyQT on some platforms, I believe.

So ultimately Gerhard's advice is sound.

Tim C