On 6/12/2010 9:26 AM, lkcl wrote:
[ye gods, i think this is the largest thread i've ever seen,
For python-list, it is possibly the longest this year, but definitely
not of all time ;-)
yep. that's why i ported pyjamas, which was a web-only/browser-only
UI toolkit, to the desktop. it's a _real_ eye-opener to try to use
the "failed" ports of pyjamas to both pygtk2 and pyqt4, which you can
still get at http://github.com/lkcl/pyjamas-desktop - see pyjd-pyqt4
and pyjd-pygtk2
these failed ports give you the clearest and bluntest indication of
the failings of pyqt4 and pygtk2. after using those two "top"
mainstream python GUI widget sets, i didn't try any others.
Can you expand on this? In brief, What were the 'failings' and were they
failings of the wrappers or the underlying toolkits?
* how much effort has been and is being spent, right now, on
developing and debugging each of the python GUI widget sets, as
compared to the efforts on web browser technology (MSHTML, KHTML ok
maybe not kHTML, WebKit, XulRunner)? (put another way: how long have
web browsers existed and how much user-market-share do web browsers
have, compared to GUI and python GUI widget sets?)
Your point that browser widget sets have gotten a lot of competitive
commercial development is well taken. HTML5 will be even more
competitive with desktop. It certainly will be a nicee cross-platform
platform for. for instance, casual no-install open-source games.
* are python GUI widget sets easy to compile cross-platform, as
compared to web browser technology which is _definitely_ cross-
platform?
* how easy is it to extend the existing python GUI widget sets with
"new" or "custom" widgets, as compared to web browser technology where
you can manipulate bits of DOM? if you're not sure of how simple/
complex each task is, read and compare these:
http://www.learningpython.com/2006/07/25/writing-a-custom-widget-using-pygtk/
http://pyjd.sourceforge.net/controls_tutorial.html
The latter has a link to http://pyjd.sourceforge.net/controls/
which is currently a 403 Error.
It also has a link to
http://github.com/lkcl/pyjamas-desktop/blob/master/pyjamas-webkit/pyjamas/Controls.py
This works fine, but github has a formatting glitch.
It insists on displaying code in an embedded page/frame? of fixed width
(about half the width of my screen, what a waste). If a code line like
if type == "mousedown" or type == "mouseup" or type ==
"mousemove" or type == "mouseover" or type == "mouseout":
is too long for the restricted width, it provides a horizontal slider,
but it attaches the slider to the bottom of the embedded page rather
than to the bottom of the browser window. So the slider is only visible
when one scrolls down to the bottom of the embedded page. To read the
end of the above line with the scroll bars, one must scroll down with
the vertical slider to make the horizontal scroll visible, scoll right
with the horizontal slider, then scroll back up to where the line is.
And then repeat to go on to the next line.
It turns out that I can also scroll by selecting and moving the mouse. I
discovered that while cutting to write the above.
3 Suggestions:
1. 'type' is a built-in function. Reading a line like the above is
jarring to me. Use 'etype' for the event type.
2. I belive the above is equivalent to
if etype in ("mousedown", "mouseup", "mousemove" "mouseover",
"mouseout"):
which would fit github's (soft) limit and be clearer and faster.
3. Until you can persuade github to change, with a better explanation of
the needed change than I can give, keep to their line limit for code you
expect others to look at.
I enjoyed the rest of the post. When I need to do gui stuff, I will
definitely look at pyjamas as an alternative to desktop-only kits.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
