From: rantingrick on
On Jun 7, 11:51 pm, alex23 <wuwe...(a)gmail.com> wrote:

<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.

From: Ben Finney on
alex23 <wuwei23(a)gmail.com> writes:

> 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.

When deciding what code is valuable and what's not, I proudly declare a
bias toward actually existing code.

--
\ “Contentment is a pearl of great price, and whosoever procures |
`\ it at the expense of ten thousand desires makes a wise and |
_o__) happy purchase.” —J. Balguy |
Ben Finney
From: Martin P. Hellwig on
On 06/06/10 03:22, ant wrote:
> 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?

--
mph
From: rantingrick on
On Jun 8, 1:39 am, "Martin P. Hellwig" <martin.hell...(a)dcuktec.org>
wrote:
> On 06/06/10 03:22, ant wrote:
>
> > 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.

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.
From: Arndt Roger Schneider on
Terry Reedy schrieb:

> 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.
>


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.


>> 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.
>
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
>
>> 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
>
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