GUIs - A Modest Proposal

M

Mark Lawrence

Speaking for myself, PySide has resolved this issue for me. I used
PyQt for some things but didn't want to use it for everything because
of the license, but I'd be ok to use PySide for anything. It's
portable to the major systems and generally better (IMHO) than the
other toolkits.


Carl Banks

Carl,

Thanks for mentioning PySide, if I'd ever heard about it I'd forgotten.

To OP.

See the following link as to why you've got so many comments:)
http://www.symbian-freak.com/news/009/08/first_public_release_of_pyside_for_qt_and_maemo.htm

Kindest regards.

Mark Lawrence.
 
C

Carl Banks

I rather feel like I'm flogging a dead horse here, but time for
another mile...

First off, I'm not volunteering to lead this effort. I don't think
anyone should
even think about that until and unless the Python Powers That Be
actually
decide that it is worth doing. That is what I meant by 'strong
leadership'.

Second; 'A minor programming language'. According to

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Visual Basic is more popular than Python. That makes me feel that
there
is something wrong with the world.

Sloth and Envy are two of the seven deadly sins. Not really a healthy
attitude.


Carl Banks
 
L

Lie Ryan

But then I don't know any of the local Python devs who use IDLE; the
IDE landscape for Python is very fragmented, which disincentives that
happening.
I don't use IDLE either, but IDLE comes by default with standard
distribution of python.
.NET/C# has had preferred GUI APIs come and go and isn't exactly what
I'd call crossplatform,
Well, if you use Gtk# for your GUI it is probably one of the [if not
"the"] most cross-platform development solution for complex fat-clients.
Looking at the state of other languages and their GUI toolkit
landscape, someone might even come to the conclusion that having one
true GUI toolkit is potentially a bad thing for a language.
+1 In the end the relationships with GUI toolkits is far more about
tool-chain and documentation then it is about language. If there was an
awesome IDE that allowed RAD [of real complex applications] in toolkit X
then people will use toolkit X. [Monodevelop and it's awesome Gtk#
support for Mono/.NET is a good example; the tool makes the toolkit
east to use - people go with the toolkit].
The problem with the current GUI toolkits is their API is designed to be
cross-language (i18n). I'd say, keep the current GUI toolkits, make
their API easier to use (l10n).
Which is 'just' an implementation detail.
Why is a GUI toolkit *API* an *implementation detail*?

You are missing the point. PyQt, PyGtk, etc.. are wrappers/bindings
around Qt, Gtk, etc... respectively. So it *is* an implementation
detail of the wrapper/binding to make the API 'pythonic'. Changing
class names, rewriting method signatures, adding glue - is a binding
issue.

binding is part of the programmer-facing API, therefore it's not an
implementation detail.
Yea. Which is an implementation detail.


So... improve the binding. That is a really silly reason to develop a
new toolkit.

isn't that my whole point?
 
T

Terry Reedy

Ant
I agree that the current tk situation is not completely satisfactory. In
particular, the IO facilities are inadequate and have not, to my
knowledge, changed in a decade. Image input formats are limited. There
is no canvas output as an image. (Output of the canvase display list as
a dialect of postscript that not everything can read is not a substitute
for this.)

However...
I think it important that Python come with a minimal IDE that is
adequate for someone like me doing Python-only development. I thank the
programmers of IDLE. So merely deleting tk/tkinter is not an option.
Indeed, having something similar to and at least as good as IDLE for any
candidate gui replacememt should and I think would be a requirement for
consideration.

The problem with the big gui application frameworks are that they are
too big. The two I have glanced at -- wx... and qt -- have much more
than gui stuff and duplicate parts of the Python stdlib and other 3rd
party libs.

As for a small gui written in Python, you seem to have ignored the link
to pygui. Of course that has its own problems. Among others: it is
incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to 2.6),
which is the only place it could be added; the api sytle is not standard
in Python (get_xx and set_xx methods instead of direct access or
properties); and there is nothing yet like IDLE.

What would be required is a Python3 GUI project with multiple contributors.

Terry Jan Reedy
 
A

Arndt Roger Schneider

Terry said:
Ant
I agree that the current tk situation is not completely satisfactory.
In particular, the IO facilities are inadequate and have not, to my
knowledge, changed in a decade. Image input formats are limited. There
is no canvas output as an image. (Output of the canvase display list
as a dialect of postscript that not everything can read is not a
substitute for this.)

Hah, You are ill-informed.
tkpath 0.3 contains a surface element, which renders vector graphics
elements
in an off-screen tk image.

Forget postscript!
Generate SVG from a tk canvas or --better-- from tkpath.
Jeszra (from me) generates SVG. There is also a SVG export
package available in python/tkinter, search the tkinter wiki.
However...
I think it important that Python come with a minimal IDE that is
adequate for someone like me doing Python-only development. I thank
the programmers of IDLE. So merely deleting tk/tkinter is not an
option. Indeed, having something similar to and at least as good as
IDLE for any candidate gui replacememt should and I think would be a
requirement for consideration.
Yes, use emacs or vim, without any GUI.
The problem with the big gui application frameworks are that they are
too big. The two I have glanced at -- wx... and qt -- have much more
than gui stuff and duplicate parts of the Python stdlib and other 3rd
party libs.


The question is:
What sort of devices are being used by
*normal* computer owners in the near future?

My guess: It wont be a Desktop Computer.

Will any big GUI-Framework work on those devises?

No!

Will a light-weight GUI-toolkit being ported to these
devices ?

Perhaps, but not likely.

Will any scripting language run on such devices?

Perhaps, but not likely, if then it will be
Ecmascript or a 4GL.

Will SVG run on thoses devices?

Yes, it must, because SVG is an integral part
of OEBPS, and the tiny implementation is already
part most mobile phones. Take a look at SVG for
BlackBerry for instance.
As for a small gui written in Python, you seem to have ignored the
link to pygui. Of course that has its own problems. Among others: it
is incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to
2.6), which is the only place it could be added; the api sytle is not
standard in Python (get_xx and set_xx methods instead of direct access
or properties); and there is nothing yet like IDLE.
What would be required is a Python3 GUI project with multiple
contributors.

Terry Jan Reedy
What sort of GUI project?


On the initial proposition:
Grapical design is art and art requires an artist.
A community cannot work like an artist. The best a
community of top-class *graphical designers* could produce
would be of mediocre quality.

-roger
 
M

Michael Torrie

I'd really like to s/tkinter/WxWidgets/g, the multiplatformness is (almost)
the same but wx looks infinitely better. IMHO a good intention is to best
the API of wx.

Does WX still do weird things like use event message maps instead of a
sane signals and slots mechanism? Last I used it, the API wasn't very
pythonic either (PyQt isn't really pythonic either; PyGTK seems to be
much better).

WX may look better than Tkinter on the screen, but it still has problems
fitting in everywhere. Certainly wx apps on OS X are pretty bad, though
that's mostly a developer issue. Qt makes it a bit easier to fit in by
providing a nice API to change button orders and integrate with native
dialog boxes.

At least with Tkinter, it doesn't quite fit in anywhere so a user is
alerted to the fact that it probably won't behave as other Windows apps
do. Then again, the Windows world is so full of inconsistent UIs and
custom widget sets that it probably doesn't matter either way. On OS X,
though it will matter greatly.
 
M

Michael Torrie

What an interesting set of responses I got!
And - even more interesting - how few of them actually seem to think
there is a problem, let
alone make any attempt to move the situation forward.

You simply haven't made a case that there is a problem to be solved.
Why should a language be integrated with and married to a GUI toolkit
anyway? Python was born in the Unix world, and the Unix philosophy of
using the tools that make sense in a modular and pipelined way is very
applicable to GUI development.

There is a case to be made for a widely portable, lowest-common
denominator UI toolkit, but that will always only fulfill limited needs
and always will be subjected to the limitations that have been specified
by several posters.

Thus for Python to really be successful in a broader sense, we need
good, solid, bindings for Cocoa, or Windows forms (whatever they are
using these days), as well as the most popular windows toolkits. We
don't need another Swing. As someone else mentioned, web-based
interfaces are increasingly important. That means you have to write
your apps in a modular way that separates the GUI from the business
logic. That way you can develop a nice GUI app and then, when there is
demand, give it a web front end.
 
G

Grant Edwards

<snip...>

What an interesting set of responses I got! And - even more
interesting - how few of them actually seem to think there is a
problem,

I rarely write programs with GUIs. When I do, wxPython seems to work
fine. So you're right: I don't see a problem.
[...]

My concern is simple: I think that Python is doomed to remain a minor
language unless we crack this problem.

How is being a "minor language" a problem?
 
T

Terry Reedy

Terry Reedy schrieb: ....

Hah, You are ill-informed.

How about 'under-informed'? That I readily admit ;-)
tkpath 0.3 contains a surface element, which renders vector graphics
elements in an off-screen tk image.

As far as I know, tkpath is either not part of the tk that comes with
python, or not accessible via tkinter, or not documented.
Forget postscript!
Gladly!

Generate SVG from a tk canvas or --better-- from tkpath.
Jeszra (from me) generates SVG.

I found http://jeszra.sourceforge.net/
It looks interesting but not quite what I need, which is to export a tk
canvas that I draw on with Python in a form I can import into OpenOffice.

There is also a SVG export
package available in python/tkinter, search the tkinter wiki.

I presume you mean there is a 3rd party python add-on package that
exports from a tk canvas. Can you be more specific as to what you meant?

Googling 'tkinter wiki' got me to http://tkinter.unpythonic.net/wiki/
wiki.python.org/moin/TkInter has a link to the same.
Searching there for 'svg' title or text has no hits.
Searching PyPI also turns up nothing obvious.

Googling further, I found canvasvg.py at
http://wm.ite.pl/proj/canvas2svg/index.html
via an answer to a question at
http://bytes.com/topic/python/answers/629332-saving-output-turtle-graphics
I will give it a try.

Terry Jan Reedy
 
G

Gregory Ewing

Terry said:
pygui ... has its own problems. ... the api sytle is not standard
in Python (get_xx and set_xx methods instead of direct access or
properties);

That was only true in a very early version of PyGUI. Properties
are used very extensively now.

(It uses get_xxx and set_xxx methods to *implement* properties,
but you don't call those from outside, you use normal attribute
access.)
 
R

rantingrick

Ant
I agree that the current tk situation is not completely satisfactory. In
particular, the IO facilities are inadequate and have not, to my
knowledge, changed in a decade. Image input formats are limited. There
is no canvas output as an image. (Output of the canvase display list as
a dialect of postscript that not everything can read is not a substitute
for this.)

However...
I think it important that Python come with a minimal IDE that is
adequate for someone like me doing Python-only development. I thank the
programmers of IDLE. So merely deleting tk/tkinter is not an option.
Indeed, having something similar to and at least as good as IDLE for any
candidate gui replacememt should and I think would be a requirement for
consideration.

The problem with the big gui application frameworks are that they are
too big. The two I have glanced at -- wx... and qt -- have much more
than gui stuff and duplicate parts of the Python stdlib and other 3rd
party libs.

As for a small gui written in Python, you seem to have ignored the link
to pygui. Of course that has its own problems. Among others: it is
incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to 2.6),
which is the only place it could be added; the api sytle is not standard
in Python (get_xx and set_xx methods instead of direct access or
properties); and there is nothing yet like IDLE.

What would be required is a Python3 GUI project with multiple contributors.

Terry Jan Reedy

I STRONGLY agree with Terry here! We need a very lightweight GUI in
the stdlib that is NOT Tkinter but IS roughly the very same basic
widget set, only better!. Yes this is 2010 and any GUI should support
all the major image types out-of-the-box!! But we damn sure don't want
100mb of bloated wx killing download times of Python either!

Improving Tkinter IMO is a lost cause. We need to find a better base
and build from it. Maybe a stripped down version of wx, or something
else...? But we sure don't need an embedded TCL interpretor packaged
with Python either *YUCK*!!!

The problem is getting a large enough group of Python users to agree
on anything about GUIs. I don't think the numbers will ever be big
enough because people are only worried about getting "their preferred"
GUI into Python. But the focus should not be on getting the most
cutting edge GUI into Python --size and maintainability issues forbid
that-- no the focus should be on these qualities...

- cross platform
- lightweight
- simple to use
- not an antiquity
- no embedded interpretors

However as i have mentioned before there will NEVER be a crowd of us
marching in the streets behind one GUI. People are just too busy to
get involved. This has to be an executive decision. The powers that be
must make the change themselves or it will never happen -- i can
guarantee that! And if this change is made python will be better off
in the end. You have my vote for change but unless someone with more
influence steps up then our laments will be but in vain.

psst, hey Guido, it's time to make your triumphant comeback to c.l.p.
We are waiting...
 
R

rantingrick

Thus for Python to really be successful in a broader sense, we need
good, solid, bindings for Cocoa, or Windows forms (whatever they are
using these days), as well as the most popular windows toolkits.  We
don't need another Swing.  As someone else mentioned, web-based
interfaces are increasingly important.  That means you have to write
your apps in a modular way that separates the GUI from the business
logic.  That way you can develop a nice GUI app and then, when there is
demand, give it a web front end.

Micheal makes a good point about the future web based interfaces. The
momentum is building fast for this type of thing and GUI may be
obsolete very soon. What options do we have in this arena? If were
going to move forward we should at least move in the right direction.
Seems that web based would help to satisfy the size requirement at
least. Pythoninic API, hmm, ain't seen one yet? Anybody have
suggestions...?
 
M

Michael Torrie

Micheal makes a good point about the future web based interfaces. The
momentum is building fast for this type of thing and GUI may be
obsolete very soon. What options do we have in this arena? If were
going to move forward we should at least move in the right direction.
Seems that web based would help to satisfy the size requirement at
least. Pythoninic API, hmm, ain't seen one yet? Anybody have
suggestions...?

What I do is to make the bulk of my code in modules that I can import
into a web-based front end (say in Django), or in a GTK-based front-end
or what have you. In other words everything is abstracted as best I can
to be independent of the GUI. If I was writing a file manager, for
example, I'd abstract all the operations that read and wrote
directories, performed file ops, etc, so that the frontend code just
simply calls my high-level functions and methods. Then it becomes much
easier to build a PyGTK front end, or PyQt frontend. There's obviously
a certain amount of work that goes into the frontend, but not quite as
much as if I'd glommed everything together.

Another tactic we're trying at my work is to build web apps in Django
and then ensure that all of our apps export business logic over XMLRPC,
so we can write non-web frontends to our apps, or even scripts. I think
RPC-like mechanisms are the key to an agile app, at least if the app is
a network-oriented app to begin with.
 
A

alex23

rantingrick said:
The problem is getting a large enough group of Python users to agree
on anything about GUIs.

No, the problem is it's a lot easier to find fault than it is to
provide a solution. And that maybe, just maybe, other people don't
want to have to do your dirty work for you.
I don't think the numbers will ever be big
enough because people are only worried about getting "their preferred"
GUI into Python.

And in what way is that different from _your_ preference for not-
Tkinter?
People are just too busy to
get involved. This has to be an executive decision. The powers that be
must make the change themselves or it will never happen -- i can
guarantee that!

No. That is _not_ how open source works. This has to be _your_
decision to _do something_. It's your itch, no one else is under any
obligation to scratch it. If it's so obvious to you what is wrong
here, it should be very clear to you how to fix it. Of course, someone
who wasn't labouring under the Dunning-Kruger effect might think that
perhaps the very fact that there are so many GUI libs out there might
indicate that this isn't a readily solved problem space...

Alternatively: how much is this change worth to you? How much are you
willing to pay to see it happen?
psst, hey Guido, it's time to make your triumphant comeback to c.l.p.
We are waiting...

You know, you _could_ drop the incessant cult of personality obsession
and rely on yourself to resolve the problems you see....

What gets me is the implicit attitude in some of these posts that it's
just so _obvious_ that something needs to be done and it's simply that
_everyone else_ is either stupid, lazy or biased towards actually
existing code.
 
R

rantingrick

<snip>

Of course i was just being theatrical alex, i hope your last post was
in the same manner. However your right about everything you said
except your accusations that i am not willing to help bring this into
reality -- i just need to find the right base... and i may have just
found it in PyGUI!!

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

My first impression of PyGUI is very good because it looks promising,
and of course has a native look and feel. Just grazing over the docs i
was very impressed. Greg has outlined some simple and clear goals
which are exactly what Python needs in a GUI. He has the vision and
quite a bit a code already written. Heck he even has an OpenGL hashed
already. From what i can see so far the API very Pythonic. I think
it's love at first sight really. I encourage others to take a look at
PyGUI and see what they think. Judge for yourself.
 
M

Martin P. Hellwig

I get the strong feeling that nobody is really happy with the state of
Python GUIs.
Tkinter is not widely liked, but is widely distributed. WxPython and
PyGtk are both
powerful, but quirky in different ways. PyQt is tied to one platform.
And there are
dozens more.

Yeah I have the same problem with washing machines, I usually end up in
one setting that works for me. But then again if Apple would make a
washing mashing with only one button that says 'wash' everybody would be
upset again because their favourite fabric does not have a special
setting and users would be confused whether to put in washing powder
before of after they have pushed the button.
Whether or not we like graphics programming, it's not going to go
away. I get the
uneasy feeling whenever I start a new project that there should be a
'better' GUI
than the ones I currently use (WxPython and PyGtk).

Perhaps the problem is saying 'GUI', sure by definition they're all
graphical and ment for the user, but the interface is ambiguous,
something that works well for touchscreen devices fails completely for
voice control and is perhaps confusing for pointers or keyboard
interaction.
The next problem is integration, do I want to make it feel like it is
part of the overall GUI (if there is any) or do I define my own
'standard'. With so many variables and different angles, it is no wonder
that there are so many different toolkits. Though I have to say that
most toolkits seems to struggle to define their own purpose.
Fragmentation is our enemy. Our resources are being dissipated. Is it
not time to
start again? We have shown that it is possible to do the right thing,
by creating Python3.

That was not starting again (perhaps in coding terms) but in design
terms it was more or less glorified clean-up. Besides fragmentation is
the natural state if anything has multiple, equally right (or wrong),
interpretations.
I ask the group; should we try to create a new GUI for Python, with
the following
properties?:

- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form

Cross-platform for GUI is a female dog, I have no idea what the right
solution is, but being non native all the time might not be the worst of
all possibilities.
If so, what are the next steps?
World domination and making GUI's against the law, everybody back to the
command line, driven by either voice, virtual/real keyboard or a direct
brain interface :)
The Python SIG on GUIs closed years ago. Should that be revived?

This is "A Modest Proposal" (J. Swift). In a sense, I am suggesting
that
we eat our own babies.
All reasonable to me even if you don't build a new gui.
But don't we owe it to the community?
That is the same as saying 'Do I owe it to myself?', well do you?
 
R

rantingrick

Yeah I have the same problem with washing machines, I usually end up in
one setting that works for me. But then again if Apple would make a
washing mashing with only one button that says 'wash' everybody would be
upset again because their favourite fabric does not have a special
setting and users would be confused whether to put in washing powder
before of after they have pushed the button.

And thats exactly not what the argument is about here. Including any
GUI in any language that satisfies everyone's personal tastes is
impossible. We are not trying to please X,Y,and Z. Nor or we are
secretly scheming to win "GUI Builder of the year awards.

Should ANY GUI be included in Python's stdlib, well probably not.
However, if you DO include a GUI it should at least be the "lightest-
weight-up-to-date-save-the-download-rate" GUI it can be!
Perhaps the problem is saying 'GUI', sure by definition they're all
graphical and ment for the user, but the interface is ambiguous,
something that works well for touchscreen devices fails completely for
voice control and is perhaps confusing for pointers or keyboard
interaction.
The next problem is integration, do I want to make it feel like it is
part of the overall GUI (if there is any) or do I define my own
'standard'. With so many variables and different angles, it is no wonder
that there are so many different toolkits. Though I have to say that
most toolkits seems to struggle to define their own purpose.

Again all good arguments at next years "World Consortium GUI
Convention" but here nothing more than cannon fodder.
World domination and making GUI's against the law, everybody back to the
command line, driven by either voice, virtual/real keyboard or a direct
brain interface :)

Personally i wait with impatient optimism for the brain interfaces.
 
A

Arndt Roger Schneider

Terry said:
How about 'under-informed'? That I readily admit ;-)



As far as I know, tkpath is either not part of the tk that comes with
python, or not accessible via tkinter, or not documented.


3x Correct. Tkpath 0.2 is a plugin into tk canvas.
Tkpath 0.3 is a standalone replecement for tk canvas.
The tkpath interface is identical to tk canvas, but it features additional
objects: path, polyline, ppolygon, pline, ptext, circle, ellipse, radial
gradients,
linear gradients, groups and styles.


The original tk canvas elements are the same as with tkpath,
but the new elements are the tk counterpart to those elements listed inside
the svg 1.1 specification.

As for documentation;
Use the Jeszra book, the svg 1.1 specification and the
ascii text documentation distributed with tkpath.

tkpath bypasses the X-emulation layer for the new elements under Windows
and OSX. CAIRO is the backend under X11.

I found http://jeszra.sourceforge.net/
It looks interesting but not quite what I need, which is to export a
tk canvas that I draw on with Python in a form I can import into
OpenOffice.
OpenOffice does --not yet-- have an svg import filter.
You will have to convert SVG into another format.

For example: use a fo-wrapper around your SVG and convert this
fo-xml into pdf (fop / java).

Other options are: inkscape, adobe illustrator,
gimp--if you can life with a raster image.


I guess SVG import has highest priority within the OpenOffice project
--you wont need such workarounds for long.

There is also a SVG export



I presume you mean there is a 3rd party python add-on package that
exports from a tk canvas. Can you be more specific as to what you meant?

Googling 'tkinter wiki' got me to http://tkinter.unpythonic.net/wiki/
wiki.python.org/moin/TkInter has a link to the same.
Searching there for 'svg' title or text has no hits.
Searching PyPI also turns up nothing obvious.

Googling further, I found canvasvg.py at
http://wm.ite.pl/proj/canvas2svg/index.html
via an answer to a question at
http://bytes.com/topic/python/answers/629332-saving-output-turtle-graphics

I will give it a try.

Terry Jan Reedy
That was it! Be aware only tk canvas elements are exported to SVG by this
package. Jeszra on the other hand converts an entire GUI into SVG.
I don't have any experience with this python package--for obvious reasons.
What you should look after is how raster images are included in the
generated SVG; and try each of the 12 different arrow shapes for tk line.


If you have controls on your canvas:
You may use the screenshot facility of tkImg to create an
image from each control, then embed the screenshot base64 encoded
inside the generated SVG.-


-roger
 
S

Steven D'Aprano

However as i have mentioned before there will NEVER be a crowd of us
marching in the streets behind one GUI. People are just too busy to get
involved. This has to be an executive decision. The powers that be must
make the change themselves or it will never happen -- i can guarantee
that! And if this change is made python will be better off in the end.
You have my vote for change but unless someone with more influence steps
up then our laments will be but in vain.

psst, hey Guido, it's time to make your triumphant comeback to c.l.p. We
are waiting...


Hmmm... there's something terribly familiar about this style of speech...
rantingrick, did you used to post under the name "r" using an gmail
account starting with "rt8"?
 
M

Martin P. Hellwig

And thats exactly not what the argument is about here. Including any
GUI in any language that satisfies everyone's personal tastes is
impossible. We are not trying to please X,Y,and Z. Nor or we are
secretly scheming to win "GUI Builder of the year awards.

Should ANY GUI be included in Python's stdlib, well probably not.
However, if you DO include a GUI it should at least be the "lightest-
weight-up-to-date-save-the-download-rate" GUI it can be!

Well that is tkinter than, it is reasonably lightweight and disliked for
different reasons by everyone equally.
 

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

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top