GUIs - A Modest Proposal

[Kevin Walzer]

that's not quite true - you can create a simple core which is easily
extensible with third party contributions to create more comprehensive
widgets.

That's exactly the design philosophy of Tk: a small core widget set
(recently expanded somewhat with the ttk widgets) and an API that is
easily extensible, either at the script level (megawidgets, cf. using an
entry widget and a listbox to build a combobox) or at the C level (more
complex, but hardly impossible).

I've used a browser-based app before (Adobe AIR app running in IE) and
while it wasn't horrible, I certainly did not prefer it to a native
desktop app: I got sick of waiting for the app to reload because of a
slow network connection.

 

[lkcl]

But you know i think it boils down to fear really. He is comfortable
in his life and wishes to keep it as cookie cutter as he can. Any
outside influence must be quashed before these meddling forces can
take hold of him. He is so fearful of seeing the light in an opposing
argument that blinding himself from reality is easier than facing
reality.

a very wise person told me a phrase which he'd heard, and i believe
it's relevant and hope you won't mind me quoting it:

"stress is where the mind compares the internal world with the
external, cannot cope with the discrepancy, and places blame on the
*external* world".

there's food for thought in that, for all concerned. nobody's
actions, here, are "wrong", they just "are".

l.

 

[lkcl]

On 06/09/10 08:20, Martin P. Hellwig wrote:

Doesn't Mac uses an X server as well?

not by default, no. you have to install it (from the XCode bundle/
package).

l.

p.s. i skipped replying to the other message but yes there is actually
an implementation of x11 directly in pure python. you can use it to
write window managers in it. but it's _not_ an x11 server
implementation, it's just equivalent to... ooo... probably libx11:
i.e. it connects to e.g. KDE, GDM, Fvwm and sends and responds to
events.

 

[lkcl]

And who are the beginning programmers going to turn into? If we do our
stuff right, Python programmers. If not,
Java or PHP or Visual Basic programmers. Or website designers. Or
worse (is there a worse?).

yes - Java programmers who use COM under Win32 to connect to a OCX
browser plugin written in Visual Basic, in a website written in PHP.

no - wait: Java programmers who use COM under Win32 to connect to a
Silverlight .NET application written in Visual Basic, in a website
written in PHP.

yeeehawww. got all the god-awful trite crap which has driven people
nuts for years, and into the welcoming and consoling arms of the
python community, alll into one gory sentence.



l.

 

[Stephen Hansen]

That's not problematic at all, for the standard library. Just write that
C extension.

Come now, of course it is. It may not be problematic for *you*, but it
*is* problematic for a lot of people.

The pool of people competent to write solid, Pythonic, capable Python
code and contribute it-- then add a few lines of ctypes for a
windows-specific workaround-- is surely larger then the pool of people
competent to write a safe C extension.

I know I only *barely* fit into the latter category.

Maybe Cython'll be mature enough eventually that the stdlib could accept
Cython-based "C" extensions for such cases.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJME6jRAAoJEKcbwptVWx/lXtwH/iBtoAWU2RQAnpnMukcZrorp
VpoL7XuP0AC3ZNjAsT7U/8nTYZ+1M1FpPzRsEQB8hMaFApv+OTAZZH0K9NHFBYky
kBEY9fSOIDzho+0U0XXfDyMYSZ9Jh3tDPkF0ke82XFFp+5VmfjDl+VvdAciBT31D
Ksh3NFKXFREOGTEYpCJG6d+4A5QdgFIGfK1shkRQ59XAps5fCi7rMbbXWzAolhN6
htcjf7s+uuW1kho5vWtAKMDevYRoxkeCBiWUEVRaGlHKk5m35uJ1SR+qnfGUZiSI
svSO9fdTBySMlHWTeA4OkLUtsrGEuDFZD4flEVF/Hi4edwerxqfe9IkhjQtXNyU=
=gorz
-----END PGP SIGNATURE-----

 

[lkcl]

*Alert*  Potentially dumb question following:  On the MS Windows
platform, Gtk is not required, just win32?

by using python-comtypes and python-ctypes, you can pretty much
control absolutely anything that's installed, and access just about
anything: any win32 dll, any function. some of the function
parameters you might have to guess, but it's doable.

in this way you can actually access the win32 GDI (graphics driver
interface) which is a serrriously low-level GUI toolkit built-in to
the win32 API, and can implement much higher-level APIs on top of it.
GDI is somewhat at the level of the X11 protocol.

as it's so low-level, the number of applications which actually do
this is _extremely_ small. the only reason i got involved at all was
to do the aaaabsolute minimum amount of work required to embed _one_
single object instance into a GDI window, taking up the entire width
and height: an IWebBrowser2 OCX control, lifted straight out of
MSHTML.DLL.

you can look at what i did, here:
http://pyjamas.git.sourceforge.net/git/gitweb.cgi?p=pyjamas/pyjamas;a=tree;f=pyjd;hb=master

see windows.py and pyjd.py. windows.py is lifted straight out of a
library by henk punkt; pyjd.py is a mish-mash amalgam of various bits
of code i found by googling for 3 weeks solid on variations of "python
MSHTML IWebBrowser2" and so on. much of the work that i found i had
to go back _years_, to older versions of python and older python
libraries that have long since been retired because nobody bothered
with the techniques that were offered.

so, yah. thanks to henk punkt's little windows.py module, it's
possible to "appear" to have direct access to win32 functions such as
"CreateWindowEx", and thanks to python-comtypes it's possible to get
access to the COM interface of DLLs and then you're off (in this case,
with the fairies).

l.

 

[lkcl]

Yes we need a leader. Someone who is not afraid of the naysayers.
Someone with Guido's vision. When the leader emerges, the people will
rally.

... Mahh? Whey'rus ma guuhhn? haww haww

 

[lkcl]

That's the reason why it won't happen. Everybody asking for change is

not willing to lead the effort. Everybody who would be able and might be
willing to lead the change fails to see the need for change.

*lol*. i don't know why, but i think that's so hilarious i might
make it my .sig. it must be because it's so beautifully zen and
circular.

there are foools who aren't confident and know it;
there are foools who _are_ confident, and experienced enough to not
try it.

that just leaves the foools who are confident enough to try it, but
whom nobody will follow

it's a bloody wonder anything gets achieved at all in free software
ha ha


l.

 

[lkcl]

ctypes is inherently unsafe.

that's ok. only the sanest and most careful of programmers are going
to use it. and all they're going to do is crash their application if
they get it wrong. or, on an OS which is _known_ to be so unstable
that it will fall over with the slightest provocation, crash the OS
and require a press of that little button which was moved to the front
_just_ to deal with that OS's instability, once again.

just because a library has a means for programmers to shoot
themselves in the foot doesn't mean that the programming language
should come with kevlar-reinforced bullet-proof vests.

It must be possible to remove it
from a Python installation,

as long as that's not an official policy statement that ctypes will,
at some point in the future, be removed from python, i'm happy.

the last thing i want to have to do is to have to include and
maintain, as part of the pyjamas download, a complex python-ctypes
library in order to get at the win32 functions "CreateWindowEx"; the
second last thing i want to have to do is rewrite pyjd's MSHTML port;
the third last thing i want to have to do is state that a 2nd and
_much_ larger library dependency/download is required: pywin32.

one of the really nice things about having chosen ctypes and a copy
of henk punkt's windows.py file is that the only dependency required
is one single 350k download: python-ctypes. last time i looked,
pywin32 was a whopping 6mb, and there's _nothing_ in pywin32 that pyjd
actually needs.

i deliberately bypassed python-win32com for exactly the same reason:
it turns out that direct ctypes access to Variant and all other OLE /
COM types is perfectly sufficient.

removal of ctypes would be a big, big mistake. i trust that i have
misinterpreted the implication of what you're saying, martin.

l.

 

[lkcl]

For example: if you want to embed a CSS-capable web-browser into your
app? PyQT is actually your best option-- albeit a commercial one if
you're not open source.. wx/Python haven't yet finished WebKit
integration(*).

there are _lots_ other options that i know of. here are three of the
best:

* python-comtypes and wrap an IWebBrowser2 instance (out of MSHTML) -
you can get a win32 GDI "handle" id out of this: if you know what
you're doing, you could likely embed that into a gtk or qt app, just
in the same way as you can embed X11 "windows" into pygtk apps, by
knowing the X11 window "handle" id.

* python-xpcom and python-hulahop on top of xulrunner. hulahop is
the python "magic glue" between GTK and the XPCOM "access" interface
to the xulrunner web engine. hulahop allows the xulrunner engine to
be embedded as a python gtk "widget", whilst also giving you a handle
to the xpcom interface.

* pywebkitgtk - in its current released/stable form, it gives you
juuust enough to embed a web browser, but you can't actually get
access to any of the DOM functions (unlike hulahop/xpcom and comtypes/
MSHTML).

i'm recording all of these, and any other web browser manipulation
technology that i've ever encountered, here:

http://wiki.python.org/moin/WebBrowserProgramming

l.

 

[lkcl]

In some sense, a C module wrapping a selected number of functions
(like the win32 extensions) is exactly that.

Notice that it's not (only) the functions itself, but also the
parameters. It's absolutely easy to crash Python by calling a function
through ctypes that expects a pointer, and you pass an integer. The
machine code will dereference the pointer (trusting that it actually is
one), and crash.

what's so bad about that? (this is a genuine, non-hostile, non-
rhetorical, non-sarcastic question).

(if the answer is "because you can't catch a segfault as a python
exception", then the question is repeated)

l.

 

[lkcl]

That's exactly the design philosophy of Tk: a small core widget set
(recently expanded somewhat with the ttk widgets) and an API that is
easily extensible, either at the script level (megawidgets, cf. using an
entry widget and a listbox to build a combobox) or at the C level (more
complex, but hardly impossible).

thank you for pointing this out, kevin. learned a lot today, just
from reading this one thread. about msg no 170 was where mention of
tk libraries for opengl, and various other types of highly
sophisticated widgets were mentioned.

personally i think that these third party comprehensive extras alone
make the answer to "should there be a replacement for python-tcl/tk" a
resounding "no" but then i don't really need to say that - we kinda
know the answer's "no" anyway

I've used a browser-based app before (Adobe AIR app running in IE) and
while it wasn't horrible, I certainly did not prefer it to a native
desktop app: I got sick of waiting for the app to reload because of a
slow network connection.

yeahh, adobe AIR is basically webkit. not entirely sure what else
they did with it - extended it to include their much-abused version of
ecmascript (aka actionscript). never really been that interested in
it, being a pythonistaaaa myself i think there's something about
flash/AIR apps that just grates against the nerves. it doesn't really
matter what reasons people come up with - it just feels... "wrong".

that's not to say, however, based on that _one_ leveraging of browser-
based web-app technology, that _all_ browser-based web-app technology
falls into the same "feels wrong" bucket. coming back to pyjamas
(again - sorry!) as an example:
http://bit.ly/9xZ3MZ

take a look at maxima's reply: you can clearly see that he's nuts
about pyjd, and finds it to be slightly scarily wonderful for GUI
development. perhaps it's because it's pythaaaaan, and free software-
based, not adobe-driven, i don't know.

*shrug*

l.

 

[Terry Reedy]

Only if you can live with the respective module not being available all
the time.

The issue is not that you may mistakes in the ctypes code, thus allowing
users to crash Python. The issue is that if users remove ctypes (which
they may want to do because it's not trustworthy), then your module will
stop working (unless you have a fallback for the case that ctypes is
unavailable).

In general, it's undesirable that absence of some module causes a
different module to stop working in the standard library, except that
absence of Tkinter clearly causes IDLE and turtle to stop working.

Having the absence of ctypes causing IDLE and turtle to stop working
would not be any worse, in a sense, though probably less expected.

That's not problematic at all, for the standard library. Just write that
C extension.

I suppose one could develop in ctypes and then rewrite when 'stable',
though 'stable' seldom is.

Would it be possible to write a program that converts a module that uses
ctypes to interface to a dll to a corresponding C extension program that
would compile to a drop in replacement extension module?

Given that the latter tends to be faster (as discovered/claimed by the
pygame folks), this might prove useful for more than the specific case.

Terry Jan Reedy

 

[Robert Kern]

that's ok. only the sanest and most careful of programmers are going
to use it. and all they're going to do is crash their application if
they get it wrong. or, on an OS which is _known_ to be so unstable
that it will fall over with the slightest provocation, crash the OS
and require a press of that little button which was moved to the front
_just_ to deal with that OS's instability, once again.

just because a library has a means for programmers to shoot
themselves in the foot doesn't mean that the programming language
should come with kevlar-reinforced bullet-proof vests.

That's exactly why it's *in* the standard library, but also exactly why it won't
be *used by* other parts of the standard library. If it's used by other parts of
the standard library, then it won't be the case that only the sanest and most
careful of programmers are going to use it.

as long as that's not an official policy statement that ctypes will,
at some point in the future, be removed from python, i'm happy.

the last thing i want to have to do is to have to include and
maintain, as part of the pyjamas download, a complex python-ctypes
library in order to get at the win32 functions "CreateWindowEx"; the
second last thing i want to have to do is rewrite pyjd's MSHTML port;
the third last thing i want to have to do is state that a 2nd and
_much_ larger library dependency/download is required: pywin32.

one of the really nice things about having chosen ctypes and a copy
of henk punkt's windows.py file is that the only dependency required
is one single 350k download: python-ctypes. last time i looked,
pywin32 was a whopping 6mb, and there's _nothing_ in pywin32 that pyjd
actually needs.

i deliberately bypassed python-win32com for exactly the same reason:
it turns out that direct ctypes access to Variant and all other OLE /
COM types is perfectly sufficient.

removal of ctypes would be a big, big mistake. i trust that i have
misinterpreted the implication of what you're saying, martin.

Yes.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Stephen Hansen]

as long as that's not an official policy statement that ctypes will,
at some point in the future, be removed from python, i'm happy.

I believe the point is that it must be possible for users/admins to
remove it, and that this removal will not cause any other part of the
standard library to fail to function.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJME8saAAoJEKcbwptVWx/lejoH/2qVe5hvPGvqOd1qNbogOM/l
hwpqHJrXYisCVEBuYyblTIaqFSsVWznqk7cxML8arZtw1G0IKJ/TCoUFUf1petix
dO0uuaBsEYPuosPGFGwjrpqa5RNqC4/UvCewEKUAEPCQt61knsiqIaavGI3vlvDc
8VTFAN180xmm/BKRhd28bQ03Nx3bEsQu53yy9OwJPCPkD5gfC0/S4hoeHLxKMVOH
v0iiCxm6WKorqg75Ewtt9wNk/l8QQ/DXbWAxXetoE7byMAW0jPARCysRQxkT+Tjn
txsdB+DGqYoUMMbXVeDy0FpS8c8XYtvhIw3+gVmI3s890yfMW30lORs7iuqTloA=
=REc1
-----END PGP SIGNATURE-----

 

[Stephen Hansen]

what's so bad about that? (this is a genuine, non-hostile, non-
rhetorical, non-sarcastic question).

(if the answer is "because you can't catch a segfault as a python
exception", then the question is repeated)

... ?!

Its not OK for code written in Python to cause a segfault; its not OK
for Python to error out in such a way that Python-level code can't catch
and deal with the error or situation (Or, at least, make note of the
traceback for later, in cases where there really isn't anything the
Python-level code could have done about it).

Its one of the reasons why we *like* Python at my day job. (Though it
applies to nearly any other high level language): its inherently safer.
A programming goof, oversight or unexpected event causes an exception.
It doesn't cause a buffer overflow.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

P.S. Yes, I do understand that ctypes invalidates those assumptions. And
that's OK. Every once in awhile, with great care and research to make
sure I know what I'm doing, I'll take the risk anyways. I do understand
the policy in terms of the stdlib though. I just wish it didn't apply to
win32 API's somehow. No, I know its not at all logical. Leave me alone.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJME8xcAAoJEKcbwptVWx/lSBAH/0Kn7HKZR/NHED/sFNJWDxqJ
mBDNCF3m5/xW8A1yQzw+okpgkon2qS5iRhRWeYcUxzpkjSRc/MkgdAHP+Y0w93mE
RTSwraLRm26+3876R81DJdUeauW7A5OgjjQunlXNfAi7aCgWT6NQW6aYAnvw1RPX
2+2LiP4wt/57ygUCxb/xd2+ZIirmDMWFq48CmYsGZxAUSBA8ADS/F3QiLcwl18W6
q7yzySu1PBM+gZ8/ysH54eGesCHtmdz9E00OAwum3+FA9aRn6FYHQgxGhNwGpKWJ
YhCHowcHXypL3e4hxi77pRRUvlAB3DG/4diP7ffPj4yLcI097iR6Pd/apfIVIi8=
=DHW+
-----END PGP SIGNATURE-----

 

[Stephen Hansen]

there are _lots_ other options that i know of. here are three of the
best:

Although I didn't state it or even hint at it, I thought it was implied
and obvious-- though obviously I was wrong ;-) Oops!

But my point and the discussion is grounded in, "and be cross platform",
because we're discussing GUI's in the context of Tkinter: which is
everywhere.

If someone doesn't need to target the Big Three with one code base, then
sure, the options you suggest may be very nice solutions for them.

I was more talking about an app which can run on windows, linux and OSX.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJME852AAoJEKcbwptVWx/lXFkH/iZTms/LkoRxSVcjh+jYqoz+
PUJQokO7E5lXQeDswgeQHHlovOMitv2OUNQBE4htBT6Ex33RKVqxw/8/T4LkvaWU
GW3gm/fnI8K2xYiq21hxdcvdeopLuLiVzZfX0NDjOw7BjS3xtEEGrQBrVQcALLSS
/rvq3q+hRUIQWHeJIJQGazQA5uNKCUpCjYnsZvkyo4BZhOsnzH+kgsJ3UVRAz/Jo
F0RiMX5yKrnP3uo6BZd9GWXMtkiPkUDbFN5BtxFxJC09JmgZcI3oMZiYZb91CFjZ
1DtmKZYuoorS1+gcLa6mLnBawnuXmh7bWWLxEUDFdRJbSGLNgWs2QdSC/P2cXaA=
=/epI
-----END PGP SIGNATURE-----

 

[Terry Reedy]

[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

 

[lkcl]

That's exactly why it's *in* the standard library, but also exactly why it won't
be *used by* other parts of the standard library. If it's used by other parts of
the standard library, then it won't be the case that only the sanest and most
careful of programmers are going to use it.

ack. understood. thank you.

Yes.

ok whew

 

[lkcl]

... ?!

Its not OK for code written in Python to cause a segfault; its not OK

[i knew this would be the / an / something-like-the answer, but i'm
just... "reading the script" so to speak]

Its one of the reasons why we *like* Python at my day job. (Though it
applies to nearly any other high level language): its inherently safer.
A programming goof, oversight or unexpected event causes an exception.
It doesn't cause a buffer overflow.

ok... analogy: when using g++ to compile c++ code, would you place
use of "asm" statements into the same sort of foot-shooting category?

P.S. Yes, I do understand that ctypes invalidates those assumptions. And
that's OK. Every once in awhile, with great care and research to make
sure I know what I'm doing, I'll take the risk anyways. I do understand
the policy in terms of the stdlib though. I just wish it didn't apply to
win32 API's somehow. No, I know its not at all logical. Leave me alone.

teehee