PyGUI as a standard GUI API for Python?

261 views
Skip to first unread message

Michael Palmer

unread,
Sep 3, 2008, 12:34:32 PM9/3/08
to greg....@canterbury.ac.nz
As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.

I've come across two projects that have the appeal of striving for
simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
wxPython. It is lacking documentation but actually quite usable and
concise. The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.

So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation? This
might make it easier for people to contribute implementation code and
maybe port the API to additional toolkits. It seems that this approach
has been quite successful in case of the Python database API. That API
defines levels of compliance, which might be a way of accommodating
different GUI toolkits as well.

I may be underestimating the difficulties of my proposed approach - I
don't have much practical experience with GUI programming myself.

Best, Michael

Diez B. Roggisch

unread,
Sep 3, 2008, 12:57:38 PM9/3/08
to
Michael Palmer schrieb:

> As anyone knows, the state of Python GUI programming is a little
> fractured at this time, with many toolkits, wrappers and meta-wrappers
> dead and alive, with or without documentation.
>
> I've come across two projects that have the appeal of striving for
> simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
> wxPython. It is lacking documentation but actually quite usable and
> concise. The other, PyGUI, has an even nicer API and more docs but has
> relatively few widgets implemented at this time. It also strives for
> compatibility with several toolkits (two at this time), which I think
> is the right idea.

I disagree with that. Meta-wrappers like this will always suffer from
problems, as they have difficulties providing a consistent api. For
example wx is said to be very windows-toolkit-centric in it's API. Yes I
know that it works under Linux with GTK, but it does not come as natural .

> So far, development of PyGUI seems to be a one-man effort, and it may
> be slowed down by the attempt to develop the API and the
> implementations concurrently. Could it be useful to uncouple the two,
> such that the API would be specified ahead of the implementation? This
> might make it easier for people to contribute implementation code and
> maybe port the API to additional toolkits. It seems that this approach
> has been quite successful in case of the Python database API. That API
> defines levels of compliance, which might be a way of accommodating
> different GUI toolkits as well.
>
> I may be underestimating the difficulties of my proposed approach - I
> don't have much practical experience with GUI programming myself.

I think you do. The reason for the various toolkits is not because of
python - it's the proliferation of toolkits that exist out there. As
long as none of these is "the winner" (and it doesn't look is if that's
to happen soon), I doubt that one API to rule them all will exist - they
all have their different strengths and weaknesses, and a python-API
should reflect these.

Diez

Michael Palmer

unread,
Sep 3, 2008, 2:57:51 PM9/3/08
to
On Sep 3, 12:57 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> Michael Palmer schrieb:

>
> > The other, PyGUI, has an even nicer API and more docs but has
> > relatively few widgets implemented at this time. It also strives for
> > compatibility with several toolkits (two at this time), which I think
> > is the right idea.
>
> I disagree with that. Meta-wrappers like this will always suffer from
> problems, as they have difficulties providing a consistent api. For
> example wx is said to be very windows-toolkit-centric in it's API. Yes I
> know that it works under Linux with GTK, but it does not come as natural .

wax actually does a nice job at wrapping wxPython with a cleaner API.

> > So far, development of PyGUI seems to be a one-man effort, and it may
> > be slowed down by the attempt to develop the API and the
> > implementations concurrently. Could it be useful to uncouple the two,
> > such that the API would be specified ahead of the implementation? This
> > might make it easier for people to contribute implementation code and
> > maybe port the API to additional toolkits. It seems that this approach
> > has been quite successful in case of the Python database API. That API
> > defines levels of compliance, which might be a way of accommodating
> > different GUI toolkits as well.
>
> > I may be underestimating the difficulties of my proposed approach - I
> > don't have much practical experience with GUI programming myself.
>
> I think you do. The reason for the various toolkits is not because of
> python - it's the proliferation of toolkits that exist out there.

Right. But that is similar to the situation with relational databases.
There are so many of them that it's impossible to include an adapter
to each of them in the stdlib. The next best thing is to provide a
high-level API that abstracts away the differences.

> As long as none of these is "the winner" (and it doesn't look is if that's
> to happen soon), I doubt that one API to rule them all will exist - they
> all have their different strengths and weaknesses, and a python-API
> should reflect these.

I rather think that a standard API would cover a reasonable subset -
it should NOT contain the idiosyncrasies of each individual toolkit.

The anygui project, which has been dormant for a while, is another
attempt at a high-level api. Apparently, it tried to implement
backends for a lot of toolkits - which again may have been to
ambitious an agenda. Maybe someone who was involved in that project
might provide some insight.


Diez B. Roggisch

unread,
Sep 3, 2008, 3:25:48 PM9/3/08
to
Michael Palmer schrieb:

>> I disagree with that. Meta-wrappers like this will always suffer from
>> problems, as they have difficulties providing a consistent api. For
>> example wx is said to be very windows-toolkit-centric in it's API. Yes I
>> know that it works under Linux with GTK, but it does not come as natural .
>
> wax actually does a nice job at wrapping wxPython with a cleaner API.

wax wraps wx. It does not wrap PyQt, Tk, win32, GTK and whatnot. That
was what I was talking about.

> Right. But that is similar to the situation with relational databases.
> There are so many of them that it's impossible to include an adapter
> to each of them in the stdlib. The next best thing is to provide a
> high-level API that abstracts away the differences.
>
>> As long as none of these is "the winner" (and it doesn't look is if that's
>> to happen soon), I doubt that one API to rule them all will exist - they
>> all have their different strengths and weaknesses, and a python-API
>> should reflect these.
>
> I rather think that a standard API would cover a reasonable subset -
> it should NOT contain the idiosyncrasies of each individual toolkit.

And thus reduce the usability massively. A reasonable subset is already
included in python, with tkinter, available on a wide range of plattforms.

Yet still people strive for the various other toolkits, because they
miss richer widgets, gui-designers (an important topic you don't cover
at all) or e.g. multi-threading capabilities.

> The anygui project, which has been dormant for a while, is another
> attempt at a high-level api. Apparently, it tried to implement
> backends for a lot of toolkits - which again may have been to
> ambitious an agenda. Maybe someone who was involved in that project
> might provide some insight.

Sure, that would be interesting.

Diez

OKB (not okblacke)

unread,
Sep 3, 2008, 5:09:02 PM9/3/08
to
Michael Palmer wrote:

> As anyone knows, the state of Python GUI programming is a little
> fractured at this time, with many toolkits, wrappers and meta-wrappers
> dead and alive, with or without documentation.

How about Dabo? http://www.dabodev.com/


--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

Greg Ewing

unread,
Sep 3, 2008, 9:44:13 PM9/3/08
to
Michael Palmer wrote:

> So far, development of PyGUI seems to be a one-man effort, and it may
> be slowed down by the attempt to develop the API and the
> implementations concurrently. Could it be useful to uncouple the two,
> such that the API would be specified ahead of the implementation?

I'm not sure that would work very well. I don't think
it's possible to invent a good API for something as
complex as a GUI toolkit in the absence of experience
using it, so the API has to evolve in parallel with at
least one implementation, and with real applications
that actually use the features concerned.

Also, the features that go into the PyGUI API are partly
determined by what is available in the underlying target
libraries. I don't want to end up with things in the
API specification that are too difficult or unwieldy
to implement on some of the target platforms. I also
don't want one implementation to get too far ahead of
the others, for the same reason.

If anyone wants to help, what's needed most right now
is a good native Windows implementation. One or two
people claimed to be working on that some time ago,
but I haven't heard from them recently. For the reasons
I mentioned above, I'm reluctant to forge ahead with
too many new features until a native Windows version
exists.

--
Greg

Kay Schluehr

unread,
Sep 4, 2008, 1:49:21 AM9/4/08
to
On 3 Sep., 18:34, Michael Palmer <m_palme...@yahoo.ca> wrote:
> As anyone knows, the state of Python GUI programming is a little
> fractured at this time, with many toolkits, wrappers and meta-wrappers
> dead and alive, with or without documentation.

A few thoughts.

1) This topic is discussed here every few months. While some kind of
AnyGUI is theoretically very elegant it hasn't worked out well in
practice: GUI libs are huge and heterogeneous. It's much unlike
building an API-layer on top of SQL. Moreover I'd like to ask whether
the fragmentation turns out to be that much of a problem in practice?

2) Tcl/Tk might have a revival due to the new Tk-theme engine in
version 8.5.

http://www.tcl.tk/software/tcltk/8.5.tml
http://wiki.tcl.tk/13636

Chances are Tkinter widgets will not look like early '90s legacy
anymore.

3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.

Ciao, Kay

Message has been deleted

M.-A. Lemburg

unread,
Sep 4, 2008, 4:31:45 AM9/4/08
to Kay Schluehr, pytho...@python.org
On 2008-09-04 07:49, Kay Schluehr wrote:
> 3) Following the public rumor mill and the latest hype RIA i.e. the
> merge of web- and desktop applications with systems like Adobe AIR,
> JavaFX, Google Gears and MS Silverlight is the future of frontend
> development. With the exception of IronPython and Silverlight, Python
> hasn't even entered this game and no one knows if it ever will.

Actually, it has already and quite some time ago:

http://www.artima.com/weblogs/viewpost.jsp?thread=208528

The recipe is simple: use Python for the business logic, database
interfacing, etc and have it talk to a Flex front-end via XML-RPC
or REST.

As a nice side-effect, this also results in a better separation
between GUI and backend, effectively making the solution future-proof
and easy to adapt to other front-end technologies.

We've been working with this approach for almost a year now and
so far never had to look back.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Sep 04 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611

Kay Schluehr

unread,
Sep 4, 2008, 5:14:21 AM9/4/08
to
On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.com> wrote:
> On 2008-09-04 07:49, Kay Schluehr wrote:
>
> > 3) Following the public rumor mill and the latest hype RIA i.e. the
> > merge of web- and desktop applications with systems like Adobe AIR,
> > JavaFX, Google Gears and MS Silverlight is the future of frontend
> > development. With the exception of IronPython and Silverlight, Python
> > hasn't even entered this game and no one knows if it ever will.
>
> Actually, it has already and quite some time ago:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=208528
>
> The recipe is simple: use Python for the business logic, database
> interfacing, etc and have it talk to a Flex front-end via XML-RPC
> or REST.

Python is still server-side in this scenario and plays no role in UI
definitions. So one doesn't get more than e.g. Django apps that
respond to HTTP requests triggered by JavaScript forms except that
JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer.
The role of Python is somewhat arbitrary. This could change only if
Python becomes a client side language executed by AVM, V8 etc. like
IronPython in Silverlight.

About separating UI from application logics by assigning functionality
to different general purpose languages I have to admit that I don't
think it is such a great idea ...

M.-A. Lemburg

unread,
Sep 4, 2008, 6:15:16 AM9/4/08
to Kay Schluehr, pytho...@python.org
On 2008-09-04 11:14, Kay Schluehr wrote:
> On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.com> wrote:
>> On 2008-09-04 07:49, Kay Schluehr wrote:
>>
>>> 3) Following the public rumor mill and the latest hype RIA i.e. the
>>> merge of web- and desktop applications with systems like Adobe AIR,
>>> JavaFX, Google Gears and MS Silverlight is the future of frontend
>>> development. With the exception of IronPython and Silverlight, Python
>>> hasn't even entered this game and no one knows if it ever will.
>> Actually, it has already and quite some time ago:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=208528
>>
>> The recipe is simple: use Python for the business logic, database
>> interfacing, etc and have it talk to a Flex front-end via XML-RPC
>> or REST.
>
> Python is still server-side in this scenario and plays no role in UI
> definitions.

That depends on how you design the application. It is well possible
to have Python drive the GUI by sending the required details to
the Flex front-end via XML (ie. data-driven GUIs).

> So one doesn't get more than e.g. Django apps that
> respond to HTTP requests triggered by JavaScript forms except that
> JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer.

You really can't compare the Flex stack to an AJAX stack. Flex
has a lot more to offer for GUI programming than AJAX, it also
doesn't suffer from the problems of AJAX having to support several
different sets of browser or library bugs.

We switched from an AJAX approach to a Flex-based approach last year
and never even considered moving back again.

> The role of Python is somewhat arbitrary. This could change only if
> Python becomes a client side language executed by AVM, V8 etc. like
> IronPython in Silverlight.
>
> About separating UI from application logics by assigning functionality
> to different general purpose languages I have to admit that I don't
> think it is such a great idea ...

In my experience, Flex + Python gives you the best of both worlds,
the nice GUI features of Flex and the efficiency of Python for the
business logic.

A long time ago, there was a Python plugin for Netscape
which allowed you to run Python straight in the browser. Perhaps
it's time to revive such an idea... but then you're still missing
out on the GUI part, since you're still stuck with what the
browser has to offer in terms of widget support.

M.-A. Lemburg

unread,
Sep 4, 2008, 9:59:36 AM9/4/08
to Banibrata Dutta, pytho...@python.org
On 2008-09-04 12:57, Banibrata Dutta wrote:

> On Thu, Sep 4, 2008 at 3:45 PM, M.-A. Lemburg <m...@egenix.com> wrote:
>
>> On 2008-09-04 11:14, Kay Schluehr wrote:
>>> On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.com> wrote:
>>>> On 2008-09-04 07:49, Kay Schluehr wrote:
>>>>
>>>>> 3) Following the public rumor mill and the latest hype RIA i.e. the
>>>>> merge of web- and desktop applications with systems like Adobe AIR,
>>>>> JavaFX, Google Gears and MS Silverlight is the future of frontend
>>>>> development. With the exception of IronPython and Silverlight, Python
>>>>> hasn't even entered this game and no one knows if it ever will.
>>>> Actually, it has already and quite some time ago:
>>>>
>>>> http://www.artima.com/weblogs/viewpost.jsp?thread=208528
>>>>
>>>> The recipe is simple: use Python for the business logic, database
>>>> interfacing, etc and have it talk to a Flex front-end via XML-RPC
>>>> or REST.
>>> Python is still server-side in this scenario and plays no role in UI
>>> definitions.
>> That depends on how you design the application. It is well possible
>> to have Python drive the GUI by sending the required details to
>> the Flex front-end via XML (ie. data-driven GUIs).
>>
>>> So one doesn't get more than e.g. Django apps that
>>> respond to HTTP requests triggered by JavaScript forms except that
>>> JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer.
>> You really can't compare the Flex stack to an AJAX stack. Flex
>> has a lot more to offer for GUI programming than AJAX, it also
>> doesn't suffer from the problems of AJAX having to support several
>> different sets of browser or library bugs.
>>
>> We switched from an AJAX approach to a Flex-based approach last year
>> and never even considered moving back again.
>
>
> The approach does seem quite impressive, but isn't Flex's platform
> neutrality quite over-rated ? I mean after-all, it assumes that Flex is
> available for and available on the platform. Flex today is not yet so
> ubiquitous as the JRE...

Since Flex is compiled to Flash and runs inside the Flash player, it
is fairly easy to get Flex apps running. You do have to have the
Flash9 player installed and the default minimum is 9.0.115.0 for
Flex builder 3.

> Are there some established best-practices on how to package such
> applications -- s.a. shipping with its's own Flex runtime, offer-download if
> missing etc. ? What happens if owner of target machine decides to upgrade
> their version of Flex, will it impact the application package in anyway, and
> render rest of it "non-upgradable" ?

So far we have not had any such problems, but that could change when
Flash10 starts to ship, of course.

We currently ship the application as a server application. The only
requirement on the client side is having a browser with Flash9
installed. Pointing the browser at the server will then load the
compiled Flex application (as .swf file).

An alternative approach is bundling the client as AIR application
which then runs as stand-alone app on the client side, but we
haven't tried that yet.

>>> The role of Python is somewhat arbitrary. This could change only if
>>> Python becomes a client side language executed by AVM, V8 etc. like
>>> IronPython in Silverlight.
>>>
>>> About separating UI from application logics by assigning functionality
>>> to different general purpose languages I have to admit that I don't
>>> think it is such a great idea ...

>> In my experience, Flex + Python gives you the best of both worlds,
>> the nice GUI features of Flex and the efficiency of Python for the
>> business logic.
>>
>> A long time ago, there was a Python plugin for Netscape
>> which allowed you to run Python straight in the browser. Perhaps
>> it's time to revive such an idea... but then you're still missing
>> out on the GUI part, since you're still stuck with what the
>> browser has to offer in terms of widget support.
>>

>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Source (#1, Sep 04 2008)
>>>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
>> ________________________________________________________________________
>>
>> :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
>>
>>
>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>> Registered at Amtsgericht Duesseldorf: HRB 46611

>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> http://mail.python.org/mailman/listinfo/python-list

Peter Decker

unread,
Sep 5, 2008, 11:19:20 AM9/5/08
to pytho...@python.org
On Wed, Sep 3, 2008 at 11:57 AM, Diez B. Roggisch <de...@nospam.web.de> wrote:
> Michael Palmer schrieb:
>>
>> As anyone knows, the state of Python GUI programming is a little
>> fractured at this time, with many toolkits, wrappers and meta-wrappers
>> dead and alive, with or without documentation.
>>
>> I've come across two projects that have the appeal of striving for
>> simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
>> wxPython. It is lacking documentation but actually quite usable and
>> concise. The other, PyGUI, has an even nicer API and more docs but has
>> relatively few widgets implemented at this time. It also strives for
>> compatibility with several toolkits (two at this time), which I think
>> is the right idea.
>
> I disagree with that. Meta-wrappers like this will always suffer from
> problems, as they have difficulties providing a consistent api. For example
> wx is said to be very windows-toolkit-centric in it's API. Yes I know that
> it works under Linux with GTK, but it does not come as natural .

With all due respect, it seems like you are not terribly familiar with
wxPython. It uses the native UI toolkit for each platform wherever
possible: Aqua on OS X; MFC on Windows and Gtk on Linux. Applications
tend to look 'natural' on each platform, rather than uniform across
platforms, and I believe that this is what most people prefer.

--

# p.d.

Diez B. Roggisch

unread,
Sep 5, 2008, 11:48:54 AM9/5/08
to
Peter Decker schrieb:

You got me wrong. I didn't say it doesn't use the native toolkit under
various OSes, I'm well aware of that it does.

What I *did* say was that wx API is designed primarily with windows'
toolkit as base, and as a consequence the API tends to be less
functional for other toolkits, making it harder to work with it. As the
OP was after a "one API to rule them all" for GUIs, I pointed that out.

See for example this (arguably somewhat dated) post that illustrates my
point:

http://mail.python.org/pipermail/python-list/2005-March/313354.html

From my personal experience with Qt and Cocoa, I can say that both are
great, but their full power is unleashed only if used directly - talk
about Multi-threading in Qt4, or KeyValue-coding in Cocoa. Neither is
available in wx.

Diez

Todd Whiteman

unread,
Sep 5, 2008, 12:33:35 PM9/5/08
to pytho...@python.org
M.-A. Lemburg wrote:
> A long time ago, there was a Python plugin for Netscape
> which allowed you to run Python straight in the browser. Perhaps
> it's time to revive such an idea... but then you're still missing
> out on the GUI part, since you're still stuck with what the
> browser has to offer in terms of widget support.
>

There is still a plugin (extension) for Mozilla based products, that
enables use of Python in products like Firefox:
http://pyxpcomext.mozdev.org/

Mark Hammond's Python/Mozilla work has enabled products like Komodo,
Miro (Democracy) and the OLPC project to use Python as a major driver
for consistent cross-platform GUI applications.

Personally, I believe XULRunner has a lot to offer for Python GUI
development, I'm currently finishing up some documentation steps to show
off how to use it specifically for Python (I'll post it to this list
when it's finished).

Cheers,
Todd

Peter Decker

unread,
Sep 5, 2008, 2:35:05 PM9/5/08
to pytho...@python.org
On Fri, Sep 5, 2008 at 10:48 AM, Diez B. Roggisch <de...@nospam.web.de> wrote:

> You got me wrong. I didn't say it doesn't use the native toolkit under
> various OSes, I'm well aware of that it does.
>
> What I *did* say was that wx API is designed primarily with windows' toolkit
> as base, and as a consequence the API tends to be less functional for other
> toolkits, making it harder to work with it. As the OP was after a "one API
> to rule them all" for GUIs, I pointed that out.
>
> See for example this (arguably somewhat dated) post that illustrates my
> point:
>
> http://mail.python.org/pipermail/python-list/2005-March/313354.html

OK, that's a little clearer.

That's one of the things that I like about Dabo - it gets rid of the
ugly (IMO) wxPython API and replaces it with a much more consistent
(and, IMO) more Pythonic API. I hated coding in wx, but I love coding
in Dabo.

--

# p.d.

Fred Pacquier

unread,
Sep 10, 2008, 2:36:15 PM9/10/08
to
Todd Whiteman <to...@activestate.com> said :

> Personally, I believe XULRunner has a lot to offer for Python GUI
> development, I'm currently finishing up some documentation steps to show
> off how to use it specifically for Python (I'll post it to this list
> when it's finished).

That would be really nice !

I've long been curious about the potential of XUL+Python, but put off by
the lack of leads to follow up, and not having time to do the digging
myself...

TIA,
fp

David Trem

unread,
Sep 14, 2008, 2:32:53 PM9/14/08
to

I will also like to see such documentation as soon as possible.
To me, XUL+python really looks like what could be my prefered solution
for multiplatform GUI for my python program.
I'm really impatient and hope a strong and motivated community could
set up arrond such XUL+python project.

All the best,

David

David Trem

unread,
Sep 14, 2008, 2:34:00 PM9/14/08
to
On 10 sep, 20:36, Fred Pacquier <xne...@fredp.lautre.net> wrote:

I will also like to see such documentation as soon as possible.

Todd Whiteman

unread,
Sep 16, 2008, 9:16:19 PM9/16/08
to Todd Whiteman, pytho...@python.org
Todd Whiteman wrote:
> Mark Hammond's Python/Mozilla work has enabled products like Komodo,
> Miro (Democracy) and the OLPC project to use Python as a major driver
> for consistent cross-platform GUI applications.
>
> Personally, I believe XULRunner has a lot to offer for Python GUI
> development, I'm currently finishing up some documentation steps to show
> off how to use it specifically for Python (I'll post it to this list
> when it's finished).

Here is the tutorial I've started in order to show off building a
Python/XULRunner GUI application.
http://pyxpcomext.mozdev.org/no_wrap/tutorials/pyxulrunner/python_xulrunner_about.html

The details in this tutorial mostly targets a Windows/Linux platform
(MacOSX is possible with a few deviations, I have tried to cover these
deviations where applicable).

Feedback is welcome.

Cheers,
Todd

lkcl

unread,
Oct 11, 2008, 3:49:00 AM10/11/08
to
> 3) Following the public rumor mill and the latest hype RIA i.e. the
> merge of web- and desktop applications with systems like Adobe AIR,
> JavaFX, Google Gears and MS Silverlight is the future of frontend
> development. With the exception of IronPython and Silverlight, Python
> hasn't even entered this game and no one knows if it ever will.

http://pyjd.org
tadaaaaa :)
(based on webkit, just like adobe air is).

lkcl

unread,
Oct 11, 2008, 3:56:02 AM10/11/08
to

> The role of Python is somewhat arbitrary. This could change only if
> Python becomes a client side language executed by AVM, V8 etc.

pyv8 - http://advogato.org/article/985.html
pyjs.py - standalone python-to-javascript compiler, see http://pyjs.org.

lkcl

unread,
Oct 11, 2008, 4:05:04 AM10/11/08
to
On Sep 17, 1:16 am, Todd Whiteman <to...@activestate.com> wrote:
> Todd Whiteman wrote:
> > Mark Hammond's Python/Mozilla work has enabled products like Komodo,
> > Miro (Democracy) and the OLPC project to use Python as a major driver
> > for consistent cross-platform GUI applications.
>
> > Personally, I believe XULRunner has a lot to offer for Python GUI
> > development, I'm currently finishing up some documentation steps to show
> > off how to use it specifically for Python (I'll post it to this list
> > when it's finished).
>
> Here is the tutorial I've started in order to show off building a
> Python/XULRunner GUI application.http://pyxpcomext.mozdev.org/no_wrap/tutorials/pyxulrunner/python_xul...

>
> The details in this tutorial mostly targets a Windows/Linux platform
> (MacOSX is possible with a few deviations, I have tried to cover these
> deviations where applicable).
>
> Feedback is welcome.


oh for _goodness_ sake :) i don't know whether to be derangedly-happy
and overexcited that pyxpcom and pydom exist, or whether to be annoyed
that i'll have to do _yet another_ port of the pyjamas widget set api
to another platform.

how come this stuff is so hard to find? it's a _brilliant_ idea to be
running python in a web browser, direct.

l.

lkcl

unread,
Oct 11, 2008, 5:19:24 AM10/11/08
to
On Sep 3, 4:34 pm, Michael Palmer <m_palme...@yahoo.ca> wrote:

> So far, development of PyGUI seems to be a one-man effort, and it may
> be slowed down by the attempt to develop the API and the
> implementations concurrently. Could it be useful to uncouple the two,
> such that the API would be specified ahead of the implementation?


michael, i went back to the beginning of this thread, to reply to your
question, because i have some insights to share with you from my
failed attempts on porting pyjamas to the desktop - which you can
collect here: http://lkcl.net/pyjamas-desktop

there, you will find an IronPython-GtkSharp port; a pyqt4 port and a
pygtk2 port. they were each failures in their own unique and special
ways.

to explain: pyjamas is a widget set api that looks desktop-like; you
write code in python, it's compiled to javascript; the DOM.py module
actually does things like document.getElementById() etc. etc. and in
this way you end up completely manipulating the DOM model, turning the
browser into just a giant desktop-like canvas.

in fact, the pyjamas widget set api is _so_ similar to a desktop api
that i decided to have a go at porting it _to_ the desktop.
eventually i succeeded.

the first attempt was with ironpython. i actually got a long way with
this one - i chewed through the pyjamas examples in about a day. i
had a small stumbling block implementing the HTML() widget, but
GtkSharp.HTML came to the rescue, there, and i was off again.
i then ran into a wall i decided not to bash my head against at such
an early stage (36 hours) - an implementation of XMLHTTPRequest
(remember - i was implementing every single bit of functionality that
a DOM model has access to).

so, i decided to port the ironpython port to pygtk2. unfortunately,
whilst i got a lot further and managed to implement all of the
examples, there was no equivalent of HTML(). GTK itself totally lacks
a rich media content widget. there is python-gtkhtml2 which is good,
but not good enough. the much better gtkhtml3 library doesn't have
python bindings around it, and i wasn't in the mood to write any (and
hadn't at the time any experience with pygtk codegen.py).

also i heard that gtkhtml2 had been abandoned, and gtkhtml3 wasn't
going to be followed up on, and that there were rumours about webkit.

crucially - much more importantly - gtkhtml 2 and 3 have absolutely no
"automatic" resizing of the HTML content within them. so, unless you
specify both the width and the height of the widget container, you end
up with a flatlined widget. by that i mean a widget of say 200 pixels
in width but ZERO pixels in height! and, as you may well know, if you
specify a width and height on a gtk widget, that's it: it's entirely
fixed. there's no going back. you're screwed.

this was an absolute killer.

with no foresight in the design of gtk or gtkhtml2 to make even a
_guess_ at the width and height of the content, the port was screwed.
i made half-hearted attempts to not specify width/height at all, but
all that that resulted in was piss-poor layout, and when you shrank
the app to small size, all the text disappeared because there was a
margin defaulting to 5px or so and all but the top left corner of the
text boxes would disappear!

so, there was no point in me attempting to make python bindings around
gtkhtml3, even though it has a system for inserting widgets into HTML
(using span ids).

and, even though there's python-gtkmozembed wrappers which would have
allowed me to embed flash plugins etc. into my application, thus
neatly emulating the way that html allows you to do that.

so - sadly - on to pyqt4.

well, i say sadly, but it was actually quite fun. i'm doing a
complete comprehensive test of absolutely every single feature of the
major widget sets out there, crawling every single corner of their
functionality in order to map concepts one-for-one, and finding that
they don't really cope.

pyqt4. again, i got a long long way. the rich media support of qt4
allowed me to do widgets that looked reasonable. i even had, by that
time, a non-asynchronous version of XMLHTTPRequest. then i got to the
implementation of Grid() and FlexTable(). this is where it started to
go wrong.

pyqt4 has the concept of layouts. a layout can be a horizontal
layout, vertical, grid, and you can even specify the percentage or
ratio of the width (or height) that individual cells can use. you
attach a layout to a widget; you can attach layouts to layouts. you
can remove layouts from widgets. what you _can't_ do is _remove_
layouts from layouts.

disappointingly, this was the killer, for me. it was just getting...
too complicated. i had already encountered advice that, in order to
implement the means to move widgets around, i should remove
*everything* and redo the layout. it just... wasn't happening.

plus, i think also that there are problems, again, with the HTML
layout: you can't _entirely_ stop text-squashing. so, although pyqt4
was _better_, it still wasn't _enough_.

so, i was _almost_ ready to give up, entirely, when i'd heard about
webkit - http://webkit.org - and this looked _perfect_. the only down-
side: it didn't have python bindings. a quick search showed
pywebkitgtk.

so, i decided to try something absolutely awful: wrap the
_javascript_! i augmented pywebkitgtk, thanks to some assistance from
the author of midori i borrowed some of his code and made it possible
for pywebkitgtk to execute javascript code-fragments (equivalent of
eval and exec). except, immediately i ran into a problem: how to pass
in function call arguments. i decided against doing func_code
grunginess and creation of variable scope management to emulate python
local function call context (!!!) and instead... insanely...

... dived straight into adding glib bindings around webkit, with a
view to then doing python-bindings around the glib bindings, using
pygtk2's "codegen.py". ... cue piped elevator music and such-like, to
substitute for two weeks of intensive programming, involving python, c+
+, perl, c ... suffice to say: it worked. it actually bloody worked.

very very quickly, i was able, once i had the glib bindings, to port
pyjamas to webkit. i had my first succesful hello world within under
an hour; i had most of the examples done within 18 hours or
thereabouts; the entire port was completed within about five days,
because i had to go back and add extra functionality such as event
handling and XMLHTTPRequest.

when i say "done" i mean that you can do eeevvverrryything that
everyone keeps lamenting about that pygtk2 and pyqt4 lack. complete
and full support for CSS stylesheets. complete and full support for
embedded plugins (such as adobe). complete and full support for HTML
syntax. _proper_ HTML, not a subset. you even get the added bonus of
being able to execute javascript fragments, if you're feeling
particularly obtuse.

and, with a few days extra work on the glib bindings, you'd even be
able to run SVG canvas from python (whereas at the moment, you'd have
to do it as javascript fragments).

the moral of the story is that web browser technology makes for a hell
of a lot better widget set than a desktop-designed widget set does. a
_lot_ better. there's been far more effort put into it, for a start.
browsers are designed to make the content look "readable" in far more
circumstances - hostile and conflicting circumstances - than desktop
apps are. we stare at browsers far more than we do at desktop apps,
for the most part.

and so, you get things like text flowing neatly around, and even
widgets flowing neatly. _properly_. you can even specify, thanks to
CSS styling, whether you want the "flowing" to be vertical-first or
horizontal-first.

imagine trying to implement that with GTK2 or QT4 - it'd be a
_nightmare_ gone wrong. yet, browsers have been doing text-flowing
and div-flowing for... forever.

now, at this point, having got what i wanted, i didn't want to spend
time on wxWidgets, but i can imagine that there would be similar
limitations.

the issue with implementing a widget set is that there is a very
specific set of functionality that is absolutely absolutely required,
and without every single bit of functionality, you are entirely
wasting your time to make the port. threading. timers. rich text
(aka HTML). event handling including window resize, onload, mouse
over, in, out, move; keyboard handling; asynchronous external
communication with the rest of the world. embedded plugins. layout
management, including horizontal, vertical, grid and flow, with
_decent_ cell proportion subdivision of available space, and respect
for minimum widths / heights as well as fixed widths / heights.

without _all_ of these things, done properly, you're hosed before you
even begin to create your widget set "wrapper".

GTK lacks flow-layout, rich text support and proportion subdivision of
layouts, making every GTK application in existence look utterly...
shit. scuse my french. fortunately, someone's come to the rescue
with a gtk theme engine which allows you to customise gtk with CSS
stylesheets, but it is early days yet.

_other_ than these significant failings, GTK is technically pretty
damn good and provides everything else you'd need - including
embedding flash and other plugins by leveraging mozplugger - in an
easy-to-use and well-documented fashion.

QT4 lacks crucial layout management (layouts not being deletable from
layouts), flow-layout, and variable-sized rich text. they _do_ have
proportional subdivision of layouts (allowing you to specify a fixed
width on one cell and a percentage width on others) but it is very
clumsy.

other than those failings, which are less than those of GTK2 but as
equally significant, QT4 _looks_ better than GTK2 but ... it's still
not good _enough_.

when you've written an app with pyjamas-desktop, and it looks good no
matter whether you resize the window to 1200x800 or down to 320x800,
because you cater for onResize events and reformat the layout, _then_
you know you're on to a winner [my first ever pyjamas app was my own
web site - http://lkcl.net/site_code - see the onWindowResize
function, which adapts the site layout. _yes_ my web site runs under
pyjd as a desktop app :) ]

and - this is the kicker: the pyjamas API itself, as long as you stick
to it, you know that the same application will run - unmodified - in a
_real_ web browser, by being compiled to javascript.

now all i have to do is investigate pydom and pyxpcomext, because -
again, porting pyjamas to utilise pydom i believe will be utterly
trivial. if i hadn't had to cater for some of glib's foibles, with
silly naming conventions, i reckon i'd be done in about 16 hours flat
(i'll let you know how i get on, when i have 16 hours of time
available to _try_!).

oh - one last thing. glib != gtk. therefore, the possibility exists
to do a pywebkitqt4, a pywebkit/wxWidgets, and, also, thanks to google
chrome's use of webkit, what google have done is write their OWN
drawing library (!!!) making ANOTHER graphics-port of webkit that is
completely independent of and having nothing to do with gtk2, qt4 or
wxWidgets. then what they have done is provide accelerated drivers
for ARM-embedded devices (in android) and another one for windows.
ripping that library (i forget its name) out of the clutches of the
monster 450mb hairy tarball that is called "google chrome" should be
given some high priority.

anyway - the reason i mention it is because with a tiny bit of messing
about, you can get a pywebkit-<anything> that is entirely and wholly
independent of the underlying "helper-widget-set" on which it sits.
the only real reason why, then, you would want to use a particular
pywebkit-<xxx> - e.g. pywebkit-qt4 with bindings to the DOM model -
would be because you wanted to embed the webkit engine into an
existing pyqt4 application.

in this way, i hope that i have highlighted that the pyjamas API is
entirely independent of the "underlying" widget set which it uses to
draw on-screen, making it a proper "cross-widget-set" API, even though
at the moment there is only widget set that it's been ported to
(pywebkitgtk).

the summary: doing a decent cross-widget-set API that is also cross-
platform, cross-desktop, cross-browser is damn hard - but it _can_ be
done, and _has_ been done, albeit in a very roundabout and obscure
fashion. http://pyjs.org and http://pyjd.org

l.

David Boddie

unread,
Oct 11, 2008, 11:31:58 AM10/11/08
to
On Saturday 11 October 2008 11:19, lkcl wrote:

> pyqt4 has the concept of layouts. a layout can be a horizontal
> layout, vertical, grid, and you can even specify the percentage or
> ratio of the width (or height) that individual cells can use. you
> attach a layout to a widget; you can attach layouts to layouts. you
> can remove layouts from widgets. what you _can't_ do is _remove_
> layouts from layouts.

You can remove layouts from layouts with the QLayout.removeItem() method.

> disappointingly, this was the killer, for me. it was just getting...
> too complicated. i had already encountered advice that, in order to
> implement the means to move widgets around, i should remove
> *everything* and redo the layout. it just... wasn't happening.

You'll need to delete the contents of those layouts yourself - maybe that's
the real problem. You shouldn't need to redo the whole layout structure,
though.

> plus, i think also that there are problems, again, with the HTML
> layout: you can't _entirely_ stop text-squashing. so, although pyqt4
> was _better_, it still wasn't _enough_.

These days, you'd probably use PyQt4's WebKit integration for HTML
rendering, anyway, though I imagine that it doesn't help you much if
you're already using WebKit directly.

[...]

> QT4 lacks crucial layout management (layouts not being deletable from
> layouts), flow-layout, and variable-sized rich text. they _do_ have
> proportional subdivision of layouts (allowing you to specify a fixed
> width on one cell and a percentage width on others) but it is very
> clumsy.

You can write your own layouts as well, but maybe that's more work than
you're prepared to do, especially now that you seem to have settled on
WebKit as your toolkit.

David

lkcl

unread,
Oct 11, 2008, 3:40:34 PM10/11/08
to
On Oct 11, 3:31 pm, David Boddie <da...@boddie.org.uk> wrote:
> On Saturday 11 October 2008 11:19, lkcl wrote:
>
> > pyqt4 has the concept of layouts. a layout can be a horizontal
> > layout, vertical, grid, and you can even specify the percentage or
> > ratio of the width (or height) that individual cells can use. you
> > attach a layout to a widget; you can attach layouts to layouts. you
> > can remove layouts from widgets. what you _can't_ do is _remove_
> > layouts from layouts.
>
> You can remove layouts from layouts with the QLayout.removeItem() method.

yes... it didn't work. a layout within a layout - i think it was a
QHorizontalLayout within a QGridLayout - didn't want to be removed.
it's probably a bug.


> These days, you'd probably use PyQt4's WebKit integration for HTML
> rendering, anyway, though I imagine that it doesn't help you much if
> you're already using WebKit directly.

[see below...]

> You can write your own layouts as well, but maybe that's more work than
> you're prepared to do,

definitely.

> especially now that you seem to have settled on
> WebKit as your toolkit.

well, it just made vast amounts of sense - cut out all the middle
men. if you're going to pull in a 17mb binary dependency, why do it
in a clumsy way?

in order to pull in flash plugins and other material, the accepted
method in pygtk2 is to use python-gtk-mozplugger. that's crazy.
embed an _entire_ web browser, just to pull in a flash component.
likewise, for doing a single bit of HTML, in pyqt4 and/or pygtk2, pull
in a 17mb binary dependency using python-webkit-qt4 and/or
pywebkitgtk, _just_ to display _one_ bit of HTML text?? _that's_
crazy.

especially as webkit actually has far better rendering capability,
features and flexibility than any of the standard desktop widget sets
which had been designed for the job!

wonderfully ironic...

oh - for completeness, if anyone's reading this and goes "no chance i
will _ever_ convert to the pyjamas API because i've spent so much time
writing pygtk2 apps" - there is a project by luis pamirez, where he
has _reimplemented_ gtk.py, gobject.py and gdk.py to sit _on top_ of
the pyjamas DOM model.

at present, it's only available in the subversion repository of
http://code.google.com, and you'll need to check out a revision some
time around sep 2007 of the llpamies branch.

basically, what that will give you is a means to run your pygtk2
applications... in a web browser!

very cool. i'll do a port to pyjamas-desktop at some time, if i have
a need for it, and will be happy to help guide anyone who wants to
spend the time on it themselves.

> especially now that you seem to have settled on WebKit as your toolkit.

well, it's not _my_ toolkit - i just use it. but you're right
inasmuch as i won't be initiating any new applications using pyqt4 or
pygtk2, not out of personal choice, anyway.

l.

lkcl

unread,
Oct 11, 2008, 3:44:12 PM10/11/08
to
ofhttp://code.google.com, and you'll need to check out a revision some

> time around sep 2007 of the llpamies branch.

rsrrmsrrwssrrfssnrssrr :)

http://code.google.com/p/pyjamas then follow through to svn
instructions, bearing in mind that, other than the llpamies branch,
that code is out-of-date.

David Boddie

unread,
Oct 11, 2008, 6:45:34 PM10/11/08
to
On Saturday 11 October 2008 21:40, lkcl wrote:
> On Oct 11, 3:31 pm, David Boddie <da...@boddie.org.uk> wrote:

>> You can remove layouts from layouts with the QLayout.removeItem() method.
>
> yes... it didn't work. a layout within a layout - i think it was a
> QHorizontalLayout within a QGridLayout - didn't want to be removed.
> it's probably a bug.

Was it detached from the layout, but still visible?

[...]

> in order to pull in flash plugins and other material, the accepted
> method in pygtk2 is to use python-gtk-mozplugger. that's crazy.
> embed an _entire_ web browser, just to pull in a flash component.
> likewise, for doing a single bit of HTML, in pyqt4 and/or pygtk2, pull
> in a 17mb binary dependency using python-webkit-qt4 and/or
> pywebkitgtk, _just_ to display _one_ bit of HTML text?? _that's_
> crazy.

Sure, if all you want to do is display one bit of HTML text. It always
helps if you choose the most appropriate libraries for each task.

David

Terry Reedy

unread,
Oct 11, 2008, 7:17:21 PM10/11/08
to pytho...@python.org
lkcl wrote:

I got the impression that there is currently no Windows binary
available. Correct? If not, perhaps someone trustworthy will someday
donate one.

lkcl

unread,
Oct 13, 2008, 5:42:16 AM10/13/08
to
> >> You can remove layouts from layouts with the QLayout.removeItem() method.

> > yes... it didn't work. a layout within a layout - i think it was a


> > QHorizontalLayout within a QGridLayout - didn't want to be removed.
> > it's probably a bug.

> Was it detached from the layout, but still visible?

i don't know if it _was_ detached from the layout, but it was
definitely still visible. see http://pyjs.org/examples/gridtest/output/GridTest.html
for the example i was porting to pyqt4. each time i clicked "Next", a
new set of N,N would be _overlaid_ on top of the old ones, even though
i was doing removeItem().

the code's at http://lkcl.net/pyjamas-desktop/pyqt4.tgz

although i'm interested to know if there's a solution (to this
particular problem), the amount of additional work to provide an
equivalent of the "1px", "10em", "25%" etc. subdivisions on layouts,
and the amount of additional work to provide "flowing" and HTML-
substitutable layouts (see http://pyjd.org/api/pyjamas.ui.HTMLPanel-class.html)
is just... it's a lot of work.

l.

lkcl

unread,
Oct 13, 2008, 9:07:17 AM10/13/08
to

sorry, terry, you deleted a bit too much context :)
so, assuming that you mean "that there is currently no http://pyjd.org
windows binary", then then answer is:

pyjamas-desktop is pure python, relying on a modified version of
pywebkitgtk and a modified version of webkit to add glib bindings to
it.

i spent one week fighting with mingw32 to cross-compile webkit for
win32 - when i say fighting i mean segfaults at link time (!!), which
was tracked down to the msvc-compiled version of libicu 3.8 and
eliminated by hack-compiling libicu with mingw32; _rebuilding_ mingw32
from the latest svn at the time, in order to include support for
exceptions across thread boundaries (libstdc++ exceptions -
libgcc_a.dll)

all in all, it was a bitch :)

_then_ i started on cross-compiling python2.5 because there's no .exe
or .zip installer for python - only a .MSI, and, having installed MSI
under wine on linux with the excellent "winetricks" script, it causes
a segfault when you try to run a .MSI.

cross-compilation of python2.4 was successful (by the person who did
the initial patch, a year ago). cross-compilation of python2.5, to
generate a libpython2.4.dll and .a, fails miserably.

why the python developers didn't include the patches, and keep them up-
to-date, isn't clear.

at that point, i gave up, despite valiant efforts, because it was
clear that, given that there was no financial incentive to continue, i
was wasting my time.

the bottom line is: if you want a windows version of pywebkitgtk, i'm
happy to assist and advise anyone of the process- it should be quite
straightforward _if_ you have MSVC and follow the standard procedure,
but i'm not about to spend my own time and effort on providing a win32
port using ming32, doing all the work _myself_, on my own, without
financial incentive and renumeration.

i'll happily explain to other people what _they_ need to do, though.

l.

Propad

unread,
Oct 13, 2008, 12:03:16 PM10/13/08
to
> the bottom line is: if you want a windows version of pywebkitgtk, i'm
> happy to assist and advise anyone of the process- it should be quite
> straightforward _if_ you have MSVC and follow the standard procedure,
> but i'm not about to spend my own time and effort on providing a win32
> port using ming32, doing all the work _myself_, on my own, without
> financial incentive and renumeration.

Is Visual Studio 2005 OK, or is some other compiler required?

> i'll happily explain to other people what _they_ need to do, though.
>
> l.

If Visual Studio 2005 suffices, I'd give it a try.

Propad

Terry Reedy

unread,
Oct 13, 2008, 5:12:28 PM10/13/08
to pytho...@python.org
lkcl wrote:
> On Oct 11, 11:17 pm, Terry Reedy <tjre...@udel.edu> wrote:
>> lkcl wrote:
>>
>> I got the impression that there is currently no Windows binary
>> available. Correct? If not, perhaps someone trustworthy will someday
>> donate one.
>
> sorry, terry, you deleted a bit too much context :)

I was referring to this at pyjd.org:

Pre-built amd64 .debs are available for download, providing
pywebkitgtk-1.0, libwebkit-1.0-2 and libwebkit-dev, here:

* Download libwebkit-dev, libwebkit-1.0-2 and pywebkitgtk-1.0

and this


>> If not, perhaps someone trustworthy will someday donate one.

was my acknowledgement that a Windows binary is not trivial and that I
don't expect one from you after all the nice work you have done.

[compiling with mingw32]


> why the python developers didn't include the patches, and keep them up-
> to-date, isn't clear.

Mostly likely because no one who uses mingw32 has volunteered to become
the mingw32 Python developer who would update such patches to current
Python (now 2.6/3.0) and support them by responding to bug reports and
by upgrading them to 2.7/3.1 in the next few years.

Any system supported in core Python code with a set of #includes needs
*someone* who will support that set. If the supporter disappears and no
one else volunteers, the #includes become obsolete and get deleted.

Terry Jan Reedy

Terry Reedy

unread,
Oct 13, 2008, 5:16:07 PM10/13/08
to pytho...@python.org
Propad wrote:
>> the bottom line is: if you want a windows version of pywebkitgtk, i'm
>> happy to assist and advise anyone of the process- it should be quite
>> straightforward _if_ you have MSVC and follow the standard procedure,
>> but i'm not about to spend my own time and effort on providing a win32
>> port using ming32, doing all the work _myself_, on my own, without
>> financial incentive and renumeration.
>
> Is Visual Studio 2005 OK, or is some other compiler required?

I believe 2.4/2.5 used VS 2003 while 2.6/3.0 do (and 2.7/3.1 will) at
least officially use VS 2008. The free express version apparently
works. It is possible the extension extension modules compiled with
2005 have/will work. I would ask in a separate thread with VS 2005 in
the subject line.


>
>> i'll happily explain to other people what _they_ need to do, though.
>>
>> l.
>
> If Visual Studio 2005 suffices, I'd give it a try.
>
> Propad

> --
> http://mail.python.org/mailman/listinfo/python-list
>

Orestis Markou

unread,
Oct 13, 2008, 5:59:56 PM10/13/08
to lkcl, pytho...@python.org
Just want to say, thank you for a very enlightening writeup. You
should really post this somewhere that we can link to.
--
ore...@orestis.gr
http://orestis.gr/

> --
> http://mail.python.org/mailman/listinfo/python-list

David Boddie

unread,
Oct 13, 2008, 6:56:00 PM10/13/08
to
On Monday 13 October 2008 11:42, lkcl wrote:

> i don't know if it _was_ detached from the layout, but it was
> definitely still visible. see
> http://pyjs.org/examples/gridtest/output/GridTest.html
> for the example i was porting to pyqt4. each time i clicked "Next", a
> new set of N,N would be _overlaid_ on top of the old ones, even though
> i was doing removeItem().

Yes, it just sounds like you needed to delete the layouts after removing
them.

I might take a look later in the week if the code in there is runnable.

David

Paul Boddie

unread,
Oct 14, 2008, 6:33:20 AM10/14/08
to
On 13 Okt, 23:59, Orestis Markou <ores...@orestis.gr> wrote:
> Just want to say, thank you for a very enlightening writeup. You  
> should really post this somewhere that we can link to.

Is this not good enough for you...?

http://mail.python.org/pipermail/python-list/2008-October/511375.html

I don't see the Python mail archives going away soon, although there's
also the Wiki for updated and maintained documents.

Although using browser technologies for desktop applications is
interesting (and not new by any means), there are a few things with
regard to layouts which are very difficult with Web technologies (and
aren't getting any easier, either) but which are almost trivial with
classic graphical user interface toolkits, and of course there are
cases where the roles are reversed. I haven't really written any
classic GUI applications for quite some time, but I feel that it's
worth pointing this out.

Paul

lkcl

unread,
Oct 14, 2008, 6:46:40 AM10/14/08
to
On Oct 13, 9:59 pm, Orestis Markou <ores...@orestis.gr> wrote:
> Just want to say, thank you for a very enlightening writeup. You
> should really post this somewhere that we can link to.

orestis, thank you for the encouragement. i did post it on my diary:
http://advogato.org/person/lkcl/diary/523.html - i decided against
doing a full-blown article because i've been doing quite a _lot_ of
writing on advogato :) but i'm reconsidering. will post here if i do.

i note with interest your comments here:

http://orestis.gr/blog/2008/09/19/random-gui-toolkits-web-and-python/

whilst pyjamas and pyjamas-desktop are definitely cross-browser, cross-
desktop, cross-platform and can even be made to be cross-widget-set,
there isn't anything to substitute for _design_ ethos on a per-
platform basis. by that i mean, expectations of there being a "File"
menu on which the word "Quit" will occur, or, as you point out, mac-
user expectations of application behaviour.

l.

lkcl

unread,
Oct 14, 2008, 6:55:08 AM10/14/08
to
On Oct 13, 10:56 pm, David Boddie <da...@boddie.org.uk> wrote:
> On Monday 13 October 2008 11:42, lkcl wrote:
>
> > i don't know if it _was_ detached from the layout, but it was
> > definitely still visible. see
> >http://pyjs.org/examples/gridtest/output/GridTest.html
> > for the example i was porting to pyqt4. each time i clicked "Next", a
> > new set of N,N would be _overlaid_ on top of the old ones, even though
> > i was doing removeItem().
>
> Yes, it just sounds like you needed to delete the layouts after removing
> them.
>
> > the code's athttp://lkcl.net/pyjamas-desktop/pyqt4.tgz

>
> I might take a look later in the week if the code in there is runnable.

yeah, it is.

hello_loader.py is the main.... err.... um.... i just double-
checked, so i'd be able to advise you and... err... the problem i
described (with the GridTest) seems to have... gone away!!

*slightly embarrassed* :)

however, clicking too fast _did_ end up with fifty little windows of
text (!)

and the respect for text boundaries is definitely broken - shrink the
window to 300 x 400 with the kitchensink example (which is where i
stopped and moved to webkit, so all the _other_ examples prior to that
will work) and you'll see that the text in a column down the left hand
side end up all overlapping each other. so, you get to see the top
few pixels of each word.

if there's a way to enforce the displaying of text - for the _text_
to say "i need to be a total area of X in order to display my words.
if you make my width too small, i will _force_ my height to be larger
as i wrap the text".

just like an HTML <p> </p> does.

l.

lkcl

unread,
Oct 14, 2008, 6:57:17 AM10/14/08
to
On Oct 13, 9:12 pm, Terry Reedy <tjre...@udel.edu> wrote:
> lkcl wrote:
> > On Oct 11, 11:17 pm, Terry Reedy <tjre...@udel.edu> wrote:
> >> lkcl wrote:
>
> >> I got the impression that there is currently no Windows binary
> >> available. Correct? If not, perhaps someone trustworthy will someday
> >> donate one.
>
> > sorry, terry, you deleted a bit too much context :)
>
> I was referring to this at pyjd.org:
>
> Pre-built amd64 .debs are available for download, providing
> pywebkitgtk-1.0, libwebkit-1.0-2 and libwebkit-dev, here:
>
> * Download libwebkit-dev, libwebkit-1.0-2 and pywebkitgtk-1.0

thanks for confirming, i thought so.

> and this
> >> If not, perhaps someone trustworthy will someday donate one.
>
> was my acknowledgement that a Windows binary is not trivial

ha ha - i found that out :)

> and that I
> don't expect one from you after all the nice work you have done.

thanks.

> [compiling with mingw32]
>
> > why the python developers didn't include the patches, and keep them up-
> > to-date, isn't clear.
>
> Mostly likely because no one who uses mingw32 has volunteered to become
> the mingw32 Python developer who would update such patches to current
> Python (now 2.6/3.0) and support them by responding to bug reports and
> by upgrading them to 2.7/3.1 in the next few years.

*nods head side-to-side*... yeahh, good point :)

lkcl

unread,
Oct 14, 2008, 7:12:33 AM10/14/08
to
On Oct 13, 4:03 pm, Propad <npropado...@googlemail.com> wrote:
> > the bottom line is: if you want a windows version of pywebkitgtk, i'm
> > happy to assist and advise anyone of the process- it should be quite
> > straightforward _if_ you have MSVC and follow the standard

> If Visual Studio 2005 suffices, I'd give it a try.

ok. let's change the subject....

it's bog-standard compile-procedure for webkit, under VS, but you
must add in the patch for the glib bindings.

you'll need a _hell_ of a lot of libraries. read this:
http://lkcl.net/webkit/cross-compile-gtk.notes.txt

and of course ignore mingw32 bits - use it to track down the locations
for the various libraries in win32 form, including the .a files.
you'll need cairo, gtk, gdk, libxml, libxslt and libicu. ibm's moved
that on to version 4 and it's compiled up for win32 already.

do make yourself known to the #webkit-gtk team on irc.freenode.net and
ask for their help.

_do_ use the code i have at github.org, use the 16401.master branch, i
do not recommend attempting to use the latest svn plus the patch at
bugs.webkit.org because alp has moved things on a bit and i haven't
the time to update to the latest svn and redo the patch.

http://github.com/lkcl/webkit/tree/16401.master


then, once you have a libwebkit.dll, you'll be in a position to
recompile pywebkitgtk for windows. this should be very very
straightforward: there's nothing out-of-the-ordinary, other than you
must patch it, use the last download / attachment from here:

http://code.google.com/p/pywebkitgtk/issues/detail?id=13

i'm not _entirely_ sure how you go about compiling a c-based python
module under windows, esp. one that requires autoconf: perhaps someone
else here can advise, but if i was to be doing it, i'd start off by
installing MSYS, locating a windows version of autoconf and gnu make
and friends, and seeing how far i could get from there.

you'll definitely need a windows version of python-gtk2 first, though,
which will, aside from anything, give you lots of clues as to how to
go about compiling pywebkitgtk - it's exactly the same principle.

the reason why you'll need python-gtk2 is because of codegen.py - that
is used to turn the webkit.defs into a webkit.c file.

good luck! :)

l.

lkcl

unread,
Oct 14, 2008, 7:45:41 AM10/14/08
to
> Although using browser technologies for desktop applications is
> interesting (and not new by any means), there are a few things with
> regard to layouts which are very difficult with Web technologies (and
> aren't getting any easier, either) but which are almost trivial with
> classic graphical user interface toolkits, and of course there are
> cases where the roles are reversed.

if it wasn't for luis pamirez's brilliant work, porting pygtk to
pyjamas, i would be absolutely agreeing with you, 100%.

see this:

http://code.google.com/p/pyjamas/wiki/GsocLlpamies

luis has demonstrated that it's possible to have your cake and eat it.

effectively - incredibly - he's ported pygtk ... to the browser!

so your python pygtk application gets compiled, along with his
reimplementation of gtk.py, gdk.py etc., into javascript (using the
pyjamas compiler) and - unmodified - your pygtk app gets to run in
every major web browser.

that's just... stunning.

regarding what you say about web technologies being more difficult to
do layouts than traditional desktop apps - i'm really sorry to say
that, from my experience with using the pyjamas widget set API, i
couldn't agree less.

HOWEVER - if this were pure HTML and CSS, i would utterly, utterly be
agreeing with you - 100%. the first paragraph of my talk for ukuug
2009 says it best:
http://ukuug.org/events/linux2008/programme/abstract-LKCLeighton-2.shtml

it was _such_ an abortion trying to do a simple centred layout. and
it's for exactly this reason that GWT was created (and then pyjamas
ported from GWT).

when you're using javascript to manipulate the DOM model (or, in the
case of pyjamas-desktop, manipulating the DOM model directly) then
it's an _entirely_ different matter. then, when you put "standard"-
like widgets which include layout manager on top of _that_, which have
identical functions and functionality to those of Desktop Widgets...

... the distinction between "web" and "desktop" suddenly becomes...
moot. especially in the context of luiz's work.


there isn't a _single_ thing that pyjamas can't do that pygtk2,
wxWidgets or pyqt4 can do. there are _lots_ of things that pyjamas
can do that pygtk2, wxWidgets and pyqt4 can't do (as they stand.
without extra work and/or extensions e.g. derivative customised
classes based on QAbstractLayout)

ok - i'm exaggerating a little :) you can't access standard python
modules from pyjamas apps in a web browser, because javascript is a
restricted execution environment, so you have to make do (and you can
make do _extremely_ well with what's available) with the provided
implementation of builtins. so, if you don't mind using
XMLHTTPRequest to communicate with the rest of the world - even if
it's on http loopback - _then_ you're ok :) and yes, XMLHTTPRequest
is supported in pyjamas-desktop (it has to be).


also, writing new layouts and new widgets, which _happen_ to operate
underneath on the DOM model of a browser (or a browser-kit-library
such as PyKDE or PyWebKitGTK) is trivial. _really_ trivial. i've
outlined how to write your own widget, here: http://pyjd.sourceforge.net/controls_tutorial.html
and it's interesting to compare that to writing one for pygtk (there's
a "stars" example which is easy to find "python gtk tutorial" i think
it's hit number 3).


the only thing i _can_ say, for definite, is that because pyjamas is
missing an equivalent of glade, the UI-generator, and those GUI-based
UI editors / designers, it _is_ at the moment a bit more... hard work
doing the UI design manually, if you're used to using a GUI tool to
design your UI.

but i'm sure that will change.

l.

lkcl

unread,
Oct 14, 2008, 8:19:40 AM10/14/08
to
> the reason why you'll need python-gtk2 is because of codegen.py - that
> is used to turn the webkit.defs into a webkit.c file.

this might help:
http://aruiz.typepad.com/siliconisland/2006/12/allinone_win32_.html

it includes python-gobject, python-gtk, gtk runtime and much more.
exactly _how_ much help it will be, i don't know: you may need instead
to track down the (individual) libraries instead, in order to get the
header files and appropriate .libs.

l.

lkcl

unread,
Oct 14, 2008, 9:26:18 AM10/14/08
to
> if there's a way to enforce the displaying of text - for the _text_
> to say "i need to be a total area of X in order to display my words.
> if you make my width too small, i will _force_ my height to be larger
> as i wrap the text".
>
> just like an HTML <p> </p> does.

... of course, i'm well aware of the reasons _why_ this isn't
supported - in either of Qt4 or Gtk2. it's because automatic-
resizing, and correct (i.e. exact) size-hinting, is a complete lairy
nightmare to implement. browsers get it right, because they have to,
and the trade-off is a rather awkward judder-judder-displaying of
content (which, for example, gives the use of HTML tables such a bad
name).

all of which of course makes the desktop-app developers' job just that
little bit more awkward...

David Boddie

unread,
Oct 14, 2008, 7:11:14 PM10/14/08
to
On Tuesday 14 October 2008 12:55, lkcl wrote:

> hello_loader.py is the main.... err.... um.... i just double-
> checked, so i'd be able to advise you and... err... the problem i
> described (with the GridTest) seems to have... gone away!!

There are lots of references to PyGTK classes in there. Is there a
way to select Qt instead of GTK?

> however, clicking too fast _did_ end up with fifty little windows of
> text (!)
>
> and the respect for text boundaries is definitely broken - shrink the
> window to 300 x 400 with the kitchensink example (which is where i
> stopped and moved to webkit, so all the _other_ examples prior to that
> will work) and you'll see that the text in a column down the left hand
> side end up all overlapping each other. so, you get to see the top
> few pixels of each word.

Hacking the code a bit, I can run the hello_loader.py example. The items
on the left do indeed overlap. It looks like the minimum size of the
labels aren't being respected for some reason.

> if there's a way to enforce the displaying of text - for the _text_
> to say "i need to be a total area of X in order to display my words.
> if you make my width too small, i will _force_ my height to be larger
> as i wrap the text".

Yes, there are ways to relate the height of a widget to its width, and
there may well be a way to do that for a standard text widget, but it
might involve some experimentation with the underlying text document.

David

greg

unread,
Oct 14, 2008, 8:27:53 PM10/14/08
to
Paul Boddie wrote:
> there are a few things with
> regard to layouts which are very difficult with Web technologies (and
> aren't getting any easier, either) but which are almost trivial with
> classic graphical user interface toolkits, and of course there are
> cases where the roles are reversed.

I've written quite a lot of desktop gui apps, and I
don't think I've ever felt the need for free-flowing
widget layouts. To say that a desktop gui api is
severely lacking without this feature is somewhat
overstating the case.

Also, I think that proportional resizing is overrated.
In my experience, either it's sufficient to just
resize one pane and keep the others a fixed size, or
you really want user control over the size of each
pane individually. Proportional resizing is a
compromise that just ends up annoying me.

--
Greg

lkcl

unread,
Oct 15, 2008, 4:33:41 AM10/15/08
to
On Oct 15, 12:27 am, greg <g...@cosc.canterbury.ac.nz> wrote:
> Paul Boddie wrote:
> > there are a few things with
> > regard to layouts which are very difficult with Web technologies (and
> > aren't getting any easier, either) but which are almost trivial with
> > classic graphical user interface toolkits, and of course there are
> > cases where the roles are reversed.
>
> I've written quite a lot of desktop gui apps, and I
> don't think I've ever felt the need for free-flowing
> widget layouts.

i have. an image library. placed in a scrollpanel, the images
automatically flow left-to-right then down the page. the application
doesn't dictate what size of panel the user _must_ view the images
in. if they want to use the whole screen width, they can. if they
want to view the images in a single column, they can.


> To say that a desktop gui api is
> severely lacking without this feature is somewhat
> overstating the case.

it's the _combination_ of the limitations that makes them severely
lacking. each limitation on its own does not, of course.

the key point is, really, that if you take away one particular layout
methodology from designers, they _will_ adapt - they _will_ cope, and
rejig the design of the app to fit the widget set.

... but that's cart-before-horse. that's "IT tail wagging the
business Dog".

so, when it comes to moving the same application functionality to a
different platform, or to the web, people freak out. you're locked
in. the cost is too great. the effort is too much.

... as you might be aware, i'm not really a big fan of restrictions
imposed by software design :)


> Also, I think that proportional resizing is overrated.

proportional resizing is very difficult to do well, and so many
people don't even consider it. many designers will say "this app is
to be used on a 1024x768 screen" (and now of course they're running
into difficulties with the netbook pcs with the 1024x600 screens, and
KDE's control panel "close" button is now off-screen for example!)

it took several months to design a 2d graph widget which was "useful"
when scaled down to 200x150, especially given that the axes could be
logarithmic (!) starting with the axes themselves, we had to break
things down into small, medium and large graticules, where the
distance between each range of graticules would no longer be
displayed, below a certain number of pixels (5 or so). likewise with
the axes numbering. then the axis description had to go, below a
certain size.

then, we had controls (sliders and dials) where, again, the graticules
automatically disappeared, and, also, if below a certain size, the
"readout" would also disappear.

so if you're doing _simple_ applications, then yes, proportional
resizing is entirely unnecessary.

but if you're doing applications where you have to display vast
amounts of interactive graphical data (the example above was a real-
time digital audio restoration GUI) then you really do have to think a
bit harder about what you're going to present the user with.

> Proportional resizing is a
> compromise that just ends up annoying me.

if it's done badly, then yeah, i agree.

if you look, for example, at the source code of my web site,
http://lkcl.net/site_code, you'll see that the site is capable of
resizing to deal with anything down to about 300 pixels in width. the
onResize function redoes the layout, placing the seven components in a
hexagon if there's space, a side-on "H" below 800 pixels, and a single
line below 640 pixels.

it didn't take too much effort, and it means that anyone viewing my
web site even on a QVGA screen won't have to do horizontal scrolling.

not that i'm _expecting_ anyone to do that - i just wanted to prove a
point :)


l.

lkcl

unread,
Oct 15, 2008, 4:44:23 AM10/15/08
to
> > hello_loader.py is the main.... err.... um.... i just double-
> > checked, so i'd be able to advise you and... err... the problem i
> > described (with the GridTest) seems to have... gone away!!
>
> There are lots of references to PyGTK classes in there.

yes, that's because i had started with the gtk port, and was going
through the examples one-by-one removing them and replacing them with
qt.

as i only got up to the "Info" tab of KitchenSink, there is still
quite a bit to do. i _say_ quite a bit - but it's only about ...
16-24 hours of work.

pyjamas is surprisingly small.

> Is there a way to select Qt instead of GTK?

sorry! removing them :)

> Hacking the code a bit,

:)

> I can run the hello_loader.py example. The items
> on the left do indeed overlap. It looks like the minimum size of the
> labels aren't being respected for some reason.

yeah. and the pyjamas ui.HTML() class is based on a Qt.QLabel(). if
that can be fixed, then there's a fair good reason to continue.

> Yes, there are ways to relate the height of a widget to its width, and
> there may well be a way to do that for a standard text widget, but it
> might involve some experimentation with the underlying text document.

*sharp intake of breath* :) yehhh, i did word-breaking by wrapping
groups of 8 letters at a time in floating-divs once, to simulate word-
breaking in a situation where the column width was 200px and people
were putting in web site addresses of 50 chars in length.... yukk.

lkcl

unread,
Oct 15, 2008, 6:02:17 AM10/15/08
to
terry, hi:
instructions to ensure that you have the right build environment for
windows is here:
http://webkit.org/building/tools.html

it's not made clear whether the use of VS 2005 will _automatically_
download all of the build dependencies for you - you'll have to find
out :)

regarding pywebkitgtk:

http://www.python.org/doc/2.5.2/ext/win-cookbook.html

not sure how much use this will be, but i'm sure you'll definitely
need gnu autoconf and friends, so i'd start here:

http://gnuwin32.sourceforge.net/

l.

Albert-jan Roskam

unread,
Oct 15, 2008, 6:16:19 AM10/15/08
to pytho...@python.org
Hi,

I wrote the program below to merge all xls files in a given directory into one multisheet xls file. It uses xlwt and xlrd. The xls files I use for input are generated by Spss. When I open and re-save the files in Excel, the program works, but when I use the xls files as they were created by Spss, the program returns an error message (see below). Some details: Python 2.4, xlwt version 0.7.0, xlrd version 0.5.2, Win NT.

Any ideas?

Thanks in advance!

Albert-Jan


"""
Merge all xls files in a given directory into one multisheet xls file.
The sheets get the orginal file name, without the extension.
File names should not exceed 31 characters, as this is the maximum
sheet name length
"""

import xlrd, xlwt
import glob, os.path

def merge_xls (in_dir, out_file="d:/merged_output.xls"):

xls_files = glob.glob(in_dir + "*.xls")
sheet_names = []
merged_book = xlwt.Workbook()

[sheet_names.append(os.path.basename(v)[:-4]) for k, v in enumerate(xls_files)]
for k, xls_file in enumerate(xls_files):
if len (sheet_names[k]) <= 31:
book = xlrd.open_workbook(xls_file)
ws = merged_book.add_sheet(sheet_names[k])
for sheetx in range(book.nsheets):
sheet = book.sheet_by_index(sheetx)
for rx in range(sheet.nrows):
for cx in range(sheet.ncols):
ws.write(rx, cx, sheet.cell_value(rx, cx))
else:
print "File name too long: <%s.xls> (maximum is 31 chars) " % (sheet_names[k])
print "File <%s.xls> is *not* included in the merged xls file." % (sheet_names[k])
merged_book.save(out_file)

print "---> Merged xls file written to %s using the following source files: " % (out_file)
for k, v in enumerate(sheet_names):
if len(v) <= 31: print "\t", str(k+1).zfill(3), "%s.xls" % (v)

merge_xls(in_dir="d:/temp/")

*** WARNING: OLE2 inconsistency: SSCS size is 0 but SSAT size is non-zero ***
put_cell 0 1

Traceback (most recent call last):
File "G:\generic_syntaxes\merge_xls.py", line 37, in -toplevel-
merge_xls(in_dir="d:/temp/")
File "G:\generic_syntaxes\merge_xls.py", line 21, in merge_xls
book = xlrd.open_workbook(xls_file)
File "C:\Python24\lib\site-packages\xlrd\__init__.py", line 139, in open_workbook
bk.get_sheets()
File "C:\Python24\lib\site-packages\xlrd\__init__.py", line 389, in get_sheets
sht = self.get_sheet(sheetno)
File "C:\Python24\lib\site-packages\xlrd\__init__.py", line 379, in get_sheet
sh.read(self)
File "C:\Python24\lib\site-packages\xlrd\sheet.py", line 285, in read
self.put_cell(rowx, colx, XL_CELL_TEXT, bk._sharedstrings[index])
File "C:\Python24\lib\site-packages\xlrd\sheet.py", line 214, in put_cell
self._cell_types[rowx][colx] = ctype
IndexError: list assignment index out of range



John Machin

unread,
Oct 15, 2008, 9:14:19 AM10/15/08
to
On Oct 15, 9:16 pm, Albert-jan Roskam <fo...@yahoo.com> wrote:
> Hi,
>
> I wrote the program below to merge all xls files in a given directory into one multisheet xls file. It uses xlwt and xlrd. The xls files I use for input are generated by Spss. When I open and re-save the files in Excel, the program works, but when I use the xls files as they were created by Spss, the program returns an error message (see below). Some details: Python 2.4, xlwt version 0.7.0, xlrd version 0.5.2, Win NT.
>
> Any ideas?

The version of xlrd that you are using is an antique. Go to
http://pypi.python.org/pypi/xlrd and get the latest version. If that
doesn't work, send me a copy of one of the files that is displaying
this problem.


>
> Thanks in advance!
>
> Albert-Jan
>
> """
> Merge all xls files in a given directory into one multisheet xls file.
> The sheets get the orginal file name, without the extension.
> File names should not exceed 31 characters, as this is the maximum
> sheet name length
> """
>
> import xlrd, xlwt
> import glob, os.path
>
> def merge_xls (in_dir, out_file="d:/merged_output.xls"):
>
>     xls_files   = glob.glob(in_dir + "*.xls")
>     sheet_names = []
>     merged_book = xlwt.Workbook()
>
>     [sheet_names.append(os.path.basename(v)[:-4]) for k, v in enumerate(xls_files)]

Wah! Try this:
sheet_names = [os.path.basename(v)[:-4]) for v in xls_files]


>     for k, xls_file in enumerate(xls_files):
>         if len (sheet_names[k]) <= 31:
>             book = xlrd.open_workbook(xls_file)
>             ws = merged_book.add_sheet(sheet_names[k])
>             for sheetx in range(book.nsheets):
>                 sheet = book.sheet_by_index(sheetx)
>                 for rx in range(sheet.nrows):
>                     for cx in range(sheet.ncols):
>                          ws.write(rx, cx, sheet.cell_value(rx, cx))

I presume that you're not too worried about any date data.

If an input file has more than 1 sheet, you are creating only one
sheet in the output file, and overwriting cells.

>         else:
>[snip]


>
> merge_xls(in_dir="d:/temp/")
>
> *** WARNING: OLE2 inconsistency: SSCS size is 0 but SSAT size is non-zero ***
> put_cell 0 1
>
> Traceback (most recent call last):

[snip]


>     self._cell_types[rowx][colx] = ctype
> IndexError: list assignment index out of range

Yeah, symptom of an xls file with a DIMENSIONS records that lies ...
xlrd has like Excel become more resilient over time :-)

BTW, consider joining the python-excel group at http://groups.google.com/group/python-excel

Cheers,
John

Albert-jan Roskam

unread,
Oct 15, 2008, 11:42:44 AM10/15/08
to pytho...@python.org, John Machin
Hi John,

Thanks! Using a higher xlrd version did the trick! Regarding your other remarks:
-yep, input files with multiple sheets don't work yet. I kinda repressed that ;-) Spss outputs only single-sheet xls files, but I agree it's nicer if the programs works in other cases too.
-and no, I don't intend to use data fields. Wouldn't it be easier to convert those to string values if I ever came across them?

Thanks again!
Albert-Jan


--- On Wed, 10/15/08, John Machin <sjma...@lexicon.net> wrote:

> --
> http://mail.python.org/mailman/listinfo/python-list



Terry Reedy

unread,
Oct 15, 2008, 2:15:23 PM10/15/08
to pytho...@python.org
Albert-jan Roskam wrote:
> Hi,
When you start a new topic/, make sure that you start a new thread by
hitting the appropriate button on your program and not by replying to a
different thread. Your post has nothing to do with GUIs and will be
missed by anyone who has threads collapsed and who skips the GUI thread.

Support Desk

unread,
Oct 15, 2008, 11:09:06 AM10/15/08
to pytho...@python.org
Hello all,

I was wondering if it would be possible to make a script to grab my
balance account balance a few times a day without having to login every
time. I know I can use the urlib2 library, but not sure how to go about
filling in the forms and submitting them. BOA has a mobile site that is
pretty simple. Anyone else use Bank of America and would be interested in
this. This is not for anything illegal, just for me to prevent overdrafting
my account

https://sitekey.bankofamerica.com/sas/signonScreen.do?isMobileDevice=true

y =
urllib.urlopen('https://sitekey.bankofamerica.com/sas/signonScreen.do?isMobl
eDevice=true',urllib.urlencode({'onlineID':'MYONLLINEID'})).readlines()

Chris Rebert

unread,
Oct 16, 2008, 11:15:01 AM10/16/08
to Support Desk, pytho...@python.org
You'd probably have to use something like mechanize
(http://wwwsearch.sourceforge.net/mechanize/) to fill out the forms,
but if BofA's website uses Javascript at all, you're probably out of
luck.

Cheers,
Chris
--
Follow the path of the Iguana...
http://rebertia.com

> --
> http://mail.python.org/mailman/listinfo/python-list
>

Support Desk

unread,
Oct 16, 2008, 1:20:14 PM10/16/08
to Chris Rebert, pytho...@python.org
I was also looking at the ClientForm Library
http://wwwsearch.sourceforge.net/ClientForm/

which can get me past the first username form, but I noticed it then goes
to a challenge question form and im not sure how to take the resulting for
and resubmit it with new information and then resubmit the resulting form
with the password

Kay Schluehr

unread,
Oct 23, 2008, 3:51:56 AM10/23/08
to
On 11 Okt., 09:56, lkcl <luke.leigh...@googlemail.com> wrote:
> > The role of Python is somewhat arbitrary. This could change only if
> > Python becomes a client side language executed by AVM,V8etc.
>
> pyv8 -http://advogato.org/article/985.html
> pyjs.py - standalone python-to-javascript compiler, seehttp://pyjs.org.

O.K. you got me all. I give up!

I've already imlemented some small Flex supporting functionality in
the P4D Langlet [1] and I'll also checkout pyjamas ( didn't worn them
for long ) and if they are fine I work out a bridge the next days.
Then only style sheets are left :)

[1] http://pypi.python.org/pypi/P4D Langlet/

Jules Stevenson

unread,
Oct 23, 2008, 2:46:16 PM10/23/08
to pytho...@python.org
Hello all,

I've been tearing my hair out trying to get pylon installed most of the day,
and it seems that both setup tools and paster.exe have some serious issues
with 64bit on windows.

Unfortunately I'm stuck with 2.6 64bit.

I think I've got it nearly all up and running, the biggest problem is that
paster fails to find the python executable when run, as it is 32bit and the
python executable is 64 [afaik]. Does anyone either have a 64bit compile, or
know where the source code for paster.exe lives so I can attempt to compile
it myself. It doesn't appear to be in the source for PasterScript package.
Somehow it 'appears' when setup .py install is run, but I cannot find any c
code anywhere.

Many thanks in advance

Jules

Reply all
Reply to author
Forward
0 new messages