From: lkcl on 12 Jun 2010 11:42
> 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
there are foools who aren't confident and know it;
there are foools who _are_ confident, and experienced enough to not
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 :)
From: lkcl on 12 Jun 2010 13:11
On Jun 12, 3:07 pm, Kevin Walzer <k...(a)codebykevin.com> wrote:
> On 6/12/10 9:44 AM, lkcl wrote:
> > 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).
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:
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.
From: Terry Reedy on 12 Jun 2010 13:32
On 6/12/2010 3:21 AM, Martin v. Loewis wrote:
>> Yeah. I get the policy in general, a proliferation of ctypes stuff could
>> be very bad -- but if code is very careful with type-checking and stuff,
>> it should be possible to get an exception, I'd hope.
> 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
> 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.
>> Otherwise it makes certain windows-workarounds very problematic. You
>> basically /have/ to write a C extension :|
> 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
From: Terry Reedy on 12 Jun 2010 15:29
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-
> * 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:
The latter has a link to http://pyjd.sourceforge.net/controls/
which is currently a 403 Error.
It also has a link to
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.
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",
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
From: geremy condra on 12 Jun 2010 18:23
On Sat, Jun 12, 2010 at 10:32 AM, Terry Reedy <tjreedy(a)udel.edu> wrote:
> On 6/12/2010 3:21 AM, Martin v. Loewis wrote:
>>> Yeah. I get the policy in general, a proliferation of ctypes stuff could
>>> be very bad -- but if code is very careful with type-checking and stuff,
>>> it should be possible to get an exception, I'd hope.
>> 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
>> 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.
>>> Otherwise it makes certain windows-workarounds very problematic. You
>>> basically /have/ to write a C extension :|
>> 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?
I did a similar thing using Java and the JNI, so this seems pretty plausible
to me. Having said that, it turned into a time sink very quickly, and there
were cases that I never got ironed out- I suspect the same would be true