From: Arndt Roger Schneider on
Terry Reedy schrieb:

> 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
From: Michael Torrie on
On 06/06/2010 02:13 AM, Gabriele Lanaro wrote:
> 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.
From: Michael Torrie on
On 06/06/2010 04:55 PM, ant wrote:
> 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.
From: Grant Edwards on
On 2010-06-06, ant <shimbo(a)uklinux.net> wrote:
> On Jun 6, 2:22?pm, ant <shi...(a)uklinux.net> wrote:
>> I get the strong feeling that nobody is really happy with the state of
>> Python GUIs.
><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?

--
Grant Edwards grant.b.edwards Yow! How do I get HOME?
at
gmail.com
From: Terry Reedy on
On 6/7/2010 5:25 PM, Arndt Roger Schneider wrote:
> 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