What does Guido want in a GUI toolkit for Python?

L

laplacian42

I just read a blog post of Guido's
http://neopythonic.blogspot.com/2009/06/ironpython-in-action-and-decline-of.html
and notice that he doesn't comment on what he wants in a GUI toolkit
for Python.

I sorta' wish he'd just come out and say, "This is what I think would
be suitable for a GUI toolkit for Python: ...". That way, someone
could then just come along and implement it. (Or maybe he's said this
and I missed it?)

So, what *does* Guido want in a GUI toolkit for Python?
 
C

Casey Hawthorne

So, what *does* Guido want in a GUI toolkit for Python?

I saw a talk by a school teacher on pyFLTK: GUI programming made easy.

On another note: I#: Groovy makes it easy to tie into the Java Swing
GUI, so if Python could do that, with the added complication being the
user would need a JVM.
 
T

Terry Reedy

I just read a blog post of Guido's
http://neopythonic.blogspot.com/2009/06/ironpython-in-action-and-decline-of.html
and notice that he doesn't comment on what he wants in a GUI toolkit
for Python.

I sorta' wish he'd just come out and say, "This is what I think would
be suitable for a GUI toolkit for Python: ...". That way, someone
could then just come along and implement it. (Or maybe he's said this
and I missed it?)

So, what *does* Guido want in a GUI toolkit for Python?

What he did say is "But it hasn't really gotten any less complex to
create the simplest of simple UIs. And that's a shame. When is Microsoft
going to learn the real lesson about simplicity of HTML?"
 
L

laplacian42

What he did say is "But it hasn't really gotten any less complex to
create the simplest of simple UIs. And that's a shame. When is Microsoft
going to learn the real lesson about simplicity of HTML?"

Long ago I did some Java programming and tried out Swing. I think the
complaints about it are that it's a very large toolkit that requires a
lot of inheritance to use. However, the underlying premise used by the
layout managers seemed sound:

1. Choose a layout manager.

2. Put one or more containers in it.

3. Fill the containers with widgets (or other containers), letting
them decide how to lay out the widgets.

That aspect, I liked. Seems a lot like nested elements in an html
page. Perhaps this was what Guido was alluding to?
 
M

Martin v. Löwis

I sorta' wish he'd just come out and say, "This is what I think would
be suitable for a GUI toolkit for Python: ...".

He is not in the business of designing GUI toolkits, but in the business
of designing programming languages. So he abstains from specifying
(or even recommending) a GUI library.

What he makes clear is the point that Terry cites: no matter what the
GUI toolkit is or what features it has - it should be simple to create
GUIs, as simple as creating HTML.
So, what *does* Guido want in a GUI toolkit for Python?

His concern really isn't what is in the toolkit, but what isn't.
It must not require lots of lines of code to produce a simple
GUI, it must not require specification of absolute coordinates,
.... - you should be able to continue the list yourself.

Regards,
Martin
 
D

Dennis Lee Bieber

What he makes clear is the point that Terry cites: no matter what the
GUI toolkit is or what features it has - it should be simple to create
GUIs, as simple as creating HTML.


His concern really isn't what is in the toolkit, but what isn't.
It must not require lots of lines of code to produce a simple
GUI, it must not require specification of absolute coordinates,
... - you should be able to continue the list yourself.

Sounds a bit like a return of DECWindows on Xt... Which had a
textual design language to define the widgets in use, names for
callbacks, etc. and only required the application to load the file and
map the callbacks to actual code...

You could change the layout without touching the application code
(as long as you weren't adding new widgets)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/
 
K

Kay Schluehr

He is not in the business of designing GUI toolkits, but in the business
of designing programming languages. So he abstains from specifying
(or even recommending) a GUI library.

.... which isn't all that different today. One might just take a look
at JavaFX and how gracefully it handles declarative data flow a.k.a.
data binding. The evolution of programming languages goes on, with or
rather without Python.
 
S

Simon Forman

I just read a blog post of Guido'shttp://neopythonic.blogspot.com/2009/06/ironpython-in-action-and-decl...
and notice that he doesn't comment on what he wants in a GUI toolkit
for Python.

I sorta' wish he'd just come out and say, "This is what I think would
be suitable for a GUI toolkit for Python: ...". That way, someone
could then just come along and implement it. (Or maybe he's said this
and I missed it?)

So, what *does* Guido want in a GUI toolkit for Python?

FWIW, I created a simple GUI builder module I call pygoo that lets you
create Tkinter GUIs from a simple text "specification".

http://www.pygoo.com/
http://code.google.com/p/pygoo/

Warm regards,
~Simon
 
N

Nobody

Sounds a bit like a return of DECWindows on Xt... Which had a
textual design language to define the widgets in use, names for
callbacks, etc. and only required the application to load the file and
map the callbacks to actual code...

You could change the layout without touching the application code
(as long as you weren't adding new widgets)

Xt itself provides some of that, the rest can be had through UIL (which is
part of Motif). GTK+ can do much of this using Glade.

The concept of separating code from data is sensible enough, and mirrors
the concept of stylesheets in HTML. It shouldn't be necessary to specify
size, position, labels, colours and the like via code. Code only needs to
be able to get a handle on a specific widget so that it can read and write
its state, dynamically register callbacks, etc.
 
S

Stef Mientki

Martin said:
He is not in the business of designing GUI toolkits, but in the business
of designing programming languages. So he abstains from specifying
(or even recommending) a GUI library.

What he makes clear is the point that Terry cites: no matter what the
GUI toolkit is or what features it has - it should be simple to create
GUIs, as simple as creating HTML.



His concern really isn't what is in the toolkit, but what isn't.
It must not require lots of lines of code to produce a simple
GUI, it must not require specification of absolute coordinates,
... - you should be able to continue the list yourself.
Gui_support obey the above 2 rules,
so I guess, 'm on the right way with GUI_support
http://mientki.ruhosting.nl/data_www/pylab_works/pw_gui_support.html
What are the other rules ?

cheers,
Stef
 
L

Lawson English

Martin said:
He is not in the business of designing GUI toolkits, but in the business
of designing programming languages. So he abstains from specifying
(or even recommending) a GUI library.

What he makes clear is the point that Terry cites: no matter what the
GUI toolkit is or what features it has - it should be simple to create
GUIs, as simple as creating HTML.

Tim Berners-Lee would laugh to hear html described as "simple." He was
very frustrated with
how long it took anyone to create a graphical toolkit to create webpages.
 
T

Terry Reedy

Having quoted Guido, I will note a few other things:

Python already comes with a GUI toolkit, so the question is really "What
would Guido want in a replacement for tk/tkinter?"

Obviously, it should be even better that the current (and even,
prospective) version of TK. 'Better' would need to be demonstrated. Part
of that would be a PEP written by or supported by the person in charge
of the replacement, with a detailed comparison and argument. Part of
that would also be a re-writing of IDLE with the new GUI, with some
visible advantage in the gui part of the code. I do not believe either
has been done.

The replacement should also have majority support. However, there are at
least 3 or 4 contenders. My impression is that most of the supporters of
each prefer (and rationally so) the status quo to having one of the
other contenders being chosen, and thereby shutting out their favorite.

The replacement would need to work with Py 3. TK does. I have not
noticed that anything else does, though that should change eventually.
(And I am sure someone will point of something I have not noticed.)

Guido is properly somewhat conservative about 'spending' BDFL points.
There is no need to decide anything at present.

Terry Jan Reedy
 
P

Phil Thompson

The replacement would need to work with Py 3. TK does. I have not
noticed that anything else does, though that should change eventually.
(And I am sure someone will point of something I have not noticed.)

PyQt does.

Phil
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top