GUIs - A Modest Proposal
ant
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.
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).
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.
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
If so, what are the next steps?
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.
But don't we owe it to the community?
geremy condra
Benjamin Peterson
Adam Tauno Williams
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
> WxPython and PyGtk are both powerful, but quirky in different ways.
All widget libraries are quirky - because sophisticated user interfaces
are complicated. If you make a new one that is sophisticated enough to
be really useful - it will be "quirky".
> PyQt is tied to one platform.
No it isn't.
> 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).
>
> Fragmentation is our enemy.
So fragment some more? And at least PyGtk is a wrapper around Gtk, so
in a sense that is anti-fragmentation. It is reusing Gtk which is also
reused as Gtk# by Mono/.NET and other bindings.
> Our resources are being dissipated. Is it not time to start again?
No.
> 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
Good luck. Seems pointless to me.
> But don't we owe it to the community?
Seems like there are already several very mature options.
Michael Torrie
> WxPython and PyGtk are both powerful, but quirky in different ways.
> PyQt is tied to one platform. And there are dozens more.
In what way is PyQt (or the new PySide bindings) tied to one platform?
PyQt is "native" on Win32, Mac, and Linux. Would your universal GUI be
any less quirky?
> I ask the group; should we try to create a new GUI for Python, with
> the following properties?:
> <snip>
> - Comprehensive, for complicated things - Cross-platform
Most GUI toolkits currently are, to some degree or another. Qt is the
most comprehensive cross-platform toolkit that I know of. You can
pretty much do any application operation using its API.
> - Looks good (to be defined)
Does that mean it looks native? Should it be native? Does not the
Tkinter gui look "good?"
I can think of at least the following reasons why a new universal GUI
for Python will have acceptance issues:
- stuck with the lowest common denominator of functionality on each
platform if you thunk to native widgets (a la wxWidgets)
- often look and feel is not quite native even when using native themes
(GTK on windows, for example)
- if you take the Java Swing approach, you'll look out of place
everywhere, which is kind of where tkinter is now.
Lie Ryan
Pick any two:
- Simple
- Beautiful
- Cross-platform
Stef Mientki
And if so, wouldn't it be better to hook to GWT or something like that
(I can't oversee all the conesquences)?
cheers,
Stef Mientki
Steven D'Aprano
> Aren't all programms going webbased in the near future ?
Yes, just wait until somebody builds a web-browser that runs in your web-
browser!
--
Steven
Petite Abeille
On Jun 6, 2010, at 12:52 PM, Steven D'Aprano wrote:
> Yes, just wait until somebody builds a web-browser that runs in your web-
> browser!
There you go:
"A good browser should be able to reproduce itself. Safari 4, built entirely with valid HTML5 and CSS3."
Lie Ryan
>
> On Jun 6, 2010, at 12:52 PM, Steven D'Aprano wrote:
>
>> Yes, just wait until somebody builds a web-browser that runs in your web-
>> browser!
>
> There you go:
>
> "A good browser should be able to reproduce itself. Safari 4, built entirely with valid HTML5 and CSS3."
>
Can't wait to see "Download Firefox for Chrome OS"
Irmen de Jong
That would mean that Chrome OS *is* Firefox, because Firefox is written in itself...
Just open the following URL in Firefox to see proof of that:
chrome://browser/content/browser.xul
Irmen
Colin J. Williams
>
>
>
>
>
This is the latest stable version of PyQt4.
PyQt-x11-gpl-4.7.3.tar.gz Linux, UNIX source
PyQt-win-gpl-4.7.3.zip Windows source
PyQt-mac-gpl-4.7.3.tar.gz MacOS/X source
Colin W.
Joshua Kordani
so you can browse while you browse!" -- Xibit
pyt...@bdurham.com
To paraphrase another poster and to borrow from SQLite:
Pick any *THREE*:
- Simple
- Beautiful
- Cross-platform
Malcolm
pyt...@bdurham.com
<iframe> ?
Malcolm
Alf P. Steinbach
I'm not sure what this discussion is about, but anyway, modern GUI frameworks
/are/ based on XML, CSS and some code behind, which may be JavaScript or other
language.
In particular Mozilla's XUL is based on XML, CSS and JavaScript, and Microsoft's
whatever-its-name is based on XML, CSS and, as I understand it, your choice of
programming language for the code behind.
I have done some XUL programming (a few Thunderbird extensions) but I haven't
tried the Microsoft stuff since even their XML text editor, when I first looked
at it, required minimum 512 MiB of RAM, and that was years ago; presumably the
modern version of that MS XML text editor now requires 16 GiB or more RAM...
Cheers,
- Alf
--
blog at <url: http://alfps.wordpress.com>
Petite Abeille
On Jun 6, 2010, at 7:36 PM, rantingrick wrote:
> Oh Please lets not help user in the age of "take-over-my-puter--all-my-
> data, and-my-freedoms, and-then-force-me-to-be-a-slave-to-you-just-so-
> i-can-use-my-data, with-your-permission, master!" era. Yes i have seen
> these GUI, HTML, CSS, Javascript freaks of nature and lament them
> daily! What a nightmare! Give me a good ole GUI and get the hell outta
> my way!
Resistance is futile. You will be assimilated.
Mark Lawrence
> On Jun 5, 9:22 pm, ant<shi...@uklinux.net> wrote:
>
>> 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
>
> one! Good luck finding others to climb into this boat. From the
> beginning there has has been this really weird love-hate relationship
> with Tkinter in the Python community. I myself experience this
> emotional attachment every day as i wish for Tkinter to be more
> "pretty" and "feature-rich" whilst at the same time loving it's
> simplicity. Tkinter seems to be Python's whipping boy and nobody wants
> to whip another, so we are stuck in limbo with a lobotomy.
>
> Heres an idea though, why not expand Tkinter with some new really cool
> widgets...? Hmmm...? That TIX package is a real PITA and could use a
> re-write. Can you believe it took until py3.0 for Tkinter to get a
> combobox :-O! Yea i know! :'-(
>
Patches are welcome at any time. I look forward to seeing your first
contribution.
Kindest regards.
Mark Lawrence.
Kevin Walzer
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
Says who?
> Tkinter is not widely liked, but is widely distributed.
I'm a strong advocate of Tkinter--there is very little that it cannot do.
WxPython and
> PyGtk are both
> powerful, but quirky in different ways. PyQt is tied to one platform.
> And there are
> dozens more.
Each has its strengths and weaknesses. They reflect the diversity of GUI
programming in general.
>
> 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).
That's debatable. These other toolkits have a decade or more of
development behind them. How are you going to improve on them?
>
> 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.
I'd say no. I used to be frustrated with the range of GUI options for
Python, but the issue was just to get started. I found Tkinter to be
useful for me, I was productive in it, and I have stayed with that.
>
> 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
>
>
These goals are not all complementary. In fact, some of them, such as
"small" and "comprehensive," are mutually exclusive. Tkinter is pretty
small; people complain it lacks things. PyQt and wxPython are pretty
comprehensive; people complain about their learning curve.
The very diversity of GUI toolkits came into effect because Python is
very easy to extend and integrate with other C/C++ libraries. Writing a
GUI toolkit from scratch is much, much harder. Even a simple toolkit
like Tk has twenty years of developer-hours behind it. Do you really
think the Python community will be able to a) agree on the design of a
new toolkit to replace Tkinter and b) implement the code in a timely
fashion across multiple platforms? It sounds like an impossible goal to me.
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
ant
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
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.
I appreciate that there are proponents of many different GUIs. I am
asking that all step back
from their particular interests and - for example - try to see the
situation from the viewpoint of
- say - a Python newbie, or an organisation that is thinking of
switching from (example only!) Visual Basic.
I obviously didn't make my main point clearly enough; I'll restate it
with a different emphasis:
The default GUI shipped with Python is Tkinter.
Few people seem to like it much. This has several consequences.
- It has not blossomed, like Python has.
- There are not hundreds of talented programmers making rapid and
impressive improvements to it.
- Books about Python use it in examples (because it IS the default),
but imply that one should move on.
The result that our hypothetical new recruit has to make a choice for
the new, big project. Remember that
GUIs have hundreds (sometimes thousands) of classes, functions and
constants. Let alone idioms and design
patterns. That is what I meant by 'Our resources are being
dissipated'; the effort of learning, remembering
and relearning a workable subset of these is substantial.
So it would be good to be able to use One Right Way, not try several
(as I have - I will admit I didn't try PyQt;
GUI fatigue was setting in by then).
If we are to make progress, I can see two obvious approaches:
1) Improve Tkinter to the point where it is supportable and supported
by a good fraction of Python programmers
or
2) Drop Tkinter as the default and use something else.
If we choose 2) then we have a new set of possibilities:
2a) Use one of the 'major' GUIs, pretty much as is, but presumably
with a lot more people supporting it if it is the default.
2b) Use one of the 'minor' GUIs, and get a lot of people working on it
to make it really good.
2c) Start from scratch. With a project supported by the Community as a
whole, with the agreed objective of being the default.
None of these is easy. All require strong leadership and great
committment.
What surprises me is the apparent willingness of the Python community
to let this issue slide.
I can see that many people have committed to one GUI and want to use
that forever. Fair enough. For the reasons I stated
originally, I've not found one. I think a lot of people deep down are
uneasy about this.
My concern is simple: I think that Python is doomed to remain a minor
language unless we crack this problem.
geremy condra
I take it you're volunteering?
Geremy Condra
AD.
> My concern is simple: I think that Python is doomed to remain a minor
> language unless we crack this problem.
I'm curious why you think fragmented GUI choices is a particular
problem for Python compared to other languages? Or why this is the
main issue holding Python back?
As far as I can tell, most of the other cross platform dynamic open
source languages (eg Perl, Ruby, PHP, Javascript) face the same
problem or don't even include a GUI toolkit. The one exception I can
think of that has a non-fragmented native GUI option is Tcl (which
being Tk is slightly ironic here), but it hasn't stopped Tcl being
doomed to be a much more minor language than Python is.
.NET/C# has had preferred GUI APIs come and go and isn't exactly what
I'd call crossplatform, Java has had (and still does?) multiple
toolkits, C/C++ never included any to begin with.
Objective C has an obvious native GUI choice, but it's not at all
crossplatform and is about as 'minor' a language as Python is anyway.
Legacy VB and Delphi had built in GUIs but they weren't really cross
platform and seem to be slipping out of relevance.
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.
I don't do any GUI coding so I don't have any toolkit preferences
myself, but I think the only sane way to address your concerns is to
incrementally improve Tkinter. Coming up with a new toolkit from
scratch is insanity, and switching the toolkit to something else
doesn't actually help much (ie you don't think any are currently
suitable anyway) and is just as likely to annoy other people.
--
Cheers
Anton
Adam Tauno Williams
> On Jun 7, 10:55 am, ant <shi...@uklinux.net> wrote:
> > My concern is simple: I think that Python is doomed to remain a minor
> > language unless we crack this problem.
> I'm curious why you think fragmented GUI choices is a particular
> problem for Python compared to other languages? Or why this is the
> main issue holding Python back?
The base assumption is: there is some core issue holding Python back?
Nah.
> .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].
--
Adam Tauno Williams <awil...@whitemice.org> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
Adam Tauno Williams
> On Jun 6, 2:22 pm, ant <shi...@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, let
> alone make any attempt to move the situation forward.
> I appreciate that there are proponents of many different GUIs. I am
> asking that all step back
> from their particular interests and - for example - try to see the
> situation from the viewpoint of
> - say - a Python newbie, or an organisation that is thinking of
> switching from (example only!) Visual Basic.
Taking a step back ^H ... Hmmmm... yep, no issue here.
> The result that our hypothetical new recruit has to make a choice for
> the new, big project. Remember that
> GUIs have hundreds (sometimes thousands) of classes, functions and
> constants. Let alone idioms and design
> patterns.
Yes - this is the natural and *unavoidable* consequence of
"comprehensive".
"Those who do not reuse, are doomed to reinvent." And reinvention
includes rediscovering the exact same problems.
> That is what I meant by 'Our resources are being
> dissipated'; the effort of learning, remembering
> and relearning a workable subset of these is substantial.
> So it would be good to be able to use One Right Way, not try several
> (as I have - I will admit I didn't try PyQt;
> GUI fatigue was setting in by then).
This isn't a language issue; it is a tool-chain issue. Get a better
IDE.
Lie Ryan
> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
>> On Jun 7, 10:55 am, ant <shi...@uklinux.net> wrote:
>>> My concern is simple: I think that Python is doomed to remain a minor
>>> language unless we crack this problem.
>> I'm curious why you think fragmented GUI choices is a particular
>> problem for Python compared to other languages? Or why this is the
>> main issue holding Python back?
>
> The base assumption is: there is some core issue holding Python back?
>
> Nah.
Any thought about drag-and-drop GUI builder in IDLE?
>> .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).
In other words, current GUI API can be used everywhere (IOW, their API
works well accross many languages); but all those GUI API also feels
foreign everywhere (IOW, their API always feels like borrowed from
another language).
To abuse the language, i18n goal is already achieved, l10n is not met yet.
Adam Tauno Williams
> On 06/07/10 10:48, Adam Tauno Williams wrote:
> > On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
> >> On Jun 7, 10:55 am, ant <shi...@uklinux.net> wrote:
> >>> My concern is simple: I think that Python is doomed to remain a minor
> >>> language unless we crack this problem.
> >> I'm curious why you think fragmented GUI choices is a particular
> >> problem for Python compared to other languages? Or why this is the
> >> main issue holding Python back?
> > The base assumption is: there is some core issue holding Python back?
> > Nah.
> Any thought about drag-and-drop GUI builder in IDLE?
Sure; someone should write one, or several. That isn't a toolkit issue.
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.
> >> .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. Comparing early Gtk#
implementations with current ones - they did a significant amount of
work to make Gtk# more .NET-ish, without rewriting Gtk. [And PyGtk is
hardly neglected; significant features of GNOME 3 such as Zeitgeist are
Python apps <http://live.gnome.org/Zeitgeist>]. I haven't had a chance
to play with it but
<http://python-forum.org/pythonforum/viewtopic.php?f=2&t=9415> looks
encouraging. But that is still far from the depth of functionality
available in .NET and Java toolchains [which, again, has nothing to do
with the specific widget set].
Lie Ryan
> On Mon, 2010-06-07 at 11:11 +1000, Lie Ryan wrote:
>> On 06/07/10 10:48, Adam Tauno Williams wrote:
>>> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
>>>> On Jun 7, 10:55 am, ant <shi...@uklinux.net> wrote:
>>>>> My concern is simple: I think that Python is doomed to remain a minor
>>>>> language unless we crack this problem.
>>>> I'm curious why you think fragmented GUI choices is a particular
>>>> problem for Python compared to other languages? Or why this is the
>>>> main issue holding Python back?
>>> The base assumption is: there is some core issue holding Python back?
>>> Nah.
>> Any thought about drag-and-drop GUI builder in IDLE?
>
> Sure; someone should write one, or several. That isn't a toolkit issue.
Sure it is, if it's concerning ease of writing a GUI-based program using
that particular toolkit.
> 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*? They seems to be
contradictory to me. The simplicity and ease of use of a library depends
on how well-designed their API is, and how "pythonic" the API appears to
a python programmer (unittest, for example, looks more Java-ish than
pythonic).
Carl Banks
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
> PyGtk are both
> powerful, but quirky in different ways. PyQt is tied to one platform.
> And there are
> dozens more.
>
> 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).
>
> not time to
> start again? We have shown that it is possible to do the right thing,
> by creating Python3.
>
> 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
>
>
> 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.
>
> But don't we owe it to the community?
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
Aahz
ant <shi...@uklinux.net> wrote:
>
>My concern is simple: I think that Python is doomed to remain a minor
>language unless we crack this problem.
Where's your proof that Python is a minor language?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Carl Banks
> I obviously didn't make my main point clearly enough;
I think you did make your point clearly enough, it's just that not
many agreed with you. But I'll play along.
> I'll restate it
> with a different emphasis:
> The default GUI shipped with Python is Tkinter.
> Few people seem to like it much. This has several consequences.
> - It has not blossomed, like Python has.
> - There are not hundreds of talented programmers making rapid and
> impressive improvements to it.
> - Books about Python use it in examples (because it IS the default),
> but imply that one should move on.
>
> The result that our hypothetical new recruit has to make a choice for
> the new, big project. Remember that
> GUIs have hundreds (sometimes thousands) of classes, functions and
> constants. Let alone idioms and design
> patterns. That is what I meant by 'Our resources are being
> dissipated'; the effort of learning, remembering
> and relearning a workable subset of these is substantial.
> So it would be good to be able to use One Right Way, not try several
> (as I have - I will admit I didn't try PyQt;
> GUI fatigue was setting in by then).
GUI programming is too complex for us (i.e., mankind) to have reached
any condition where One Obvious Way makes sense, we just don't know
enough, and there might not ever be one.
So it would be foolish for Python to go out and say "this is the One
Obvious Way"--it'd be like claiming to be smarter than mankind.
Right now the best way is to let GUI toolkits be toolkits and to
compete with each other.
> If we are to make progress, I can see two obvious approaches:
> 1) Improve Tkinter to the point where it is supportable and supported
> by a good fraction of Python programmers
> or
> 2) Drop Tkinter as the default and use something else.
>
> If we choose 2) then we have a new set of possibilities:
> 2a) Use one of the 'major' GUIs, pretty much as is, but presumably
> with a lot more people supporting it if it is the default.
> 2b) Use one of the 'minor' GUIs, and get a lot of people working on it
> to make it really good.
> 2c) Start from scratch. With a project supported by the Community as a
> whole, with the agreed objective of being the default.
I believe choosing any one of these options would do far more harm
than good.
The bureaucracy of the standard library works to keep Python headed
down the straight path for stable, mature tasks like basic
networking. But for dynamic, complex, cutting-edge tasks like GUI
programming it would bog everything down. Only straightforward,
simple GUIs like Tkinter are suitable for the standard library.
> None of these is easy. All require strong leadership and great
> committment.
Strong leaders in GUI programming are best left unhindered by the
constraints of Python's standard library process.
BTW, what's your plan for producing such a leader? Because if we
don't have a leader it's kind of a moot point. (I know some people
asked you to volunteer, but I suspect you would agree that you're not
up to the task, so I assume you are merely a visionary and have
someone lined up that you've somehow convince to do the dirty work of
leadership.)
> What surprises me is the apparent willingness of the Python community
> to let this issue slide.
It's not a willingness to let the issue slide; it's disagreement that
it's an issue at all.
> I can see that many people have committed to one GUI and want to use
> that forever. Fair enough. For the reasons I stated
> originally, I've not found one. I think a lot of people deep down are
> uneasy about this.
I haven't noticed much of that. The main objection seems to be that
Python carries around the dead weight of Tkinter, or at least that
it's basic GUI isn't actually written in Python.
I've seen a lot more people clamoring for a web framework a la Ruby on
Rails, mostly, I suspect, out of greed for exposure. Same issue,
though.
Notice that Ruby got typecast as a web language. Then people started
jumping off the RoR bandwagon, so now it's a web language with few
users. You want that for Python? I don't.
> My concern is simple: I think that Python is doomed to remain a minor
> language unless we crack this problem.
Well, if Python is considered a "minor language" now, I'd happy to
welcome that particular damnation.
-1
Carl Banks
ant
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.
Third: "I'm curious why you think fragmented GUI choices is a
particular
problem for Python compared to other languages? Or why this is the
main issue holding Python back? "
It's not a particular problem for Python compared to other languages.
It's a general problem for all programming languages. But I presume
that you read this newgroup because you think Python is in some sense
'better' than other programming languages. And I think we can make it
better still.
Fourth: " BTW, what's your plan for producing such a leader? Because
if we
don't have a leader it's kind of a moot point. (I know some people
asked you to volunteer, but I suspect you would agree that you're
not
up to the task, so I assume you are merely a visionary and have
someone lined up that you've somehow convince to do the dirty work
of
leadership.) "
I'm not a visionary and I don't have someone lined up. And I am
certainly
not up to the task myself. But I have watched with interest the
process of
turning Python2.x into Python3.x. Does that give any hints about who
I
think should be considering this topic (see first point)?
Nobody
> If we are to make progress, I can see two obvious approaches:
> 1) Improve Tkinter to the point where it is supportable and supported
> by a good fraction of Python programmers
> or
> 2) Drop Tkinter as the default and use something else.
You forgot:
3) Drop Tkinter and don't provide any GUI toolkit as part of the standard
library.
It seems to have worked out okay for C and C++.
Adam Tauno Williams
> On 06/07/10 12:18, Adam Tauno Williams wrote:
> > On Mon, 2010-06-07 at 11:11 +1000, Lie Ryan wrote:
> >> On 06/07/10 10:48, Adam Tauno Williams wrote:
> >>> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
> >>>> On Jun 7, 10:55 am, ant <shi...@uklinux.net> wrote:
> >>>>> My concern is simple: I think that Python is doomed to remain a minor
> >>>>> language unless we crack this problem.
> >>>> I'm curious why you think fragmented GUI choices is a particular
> >>>> problem for Python compared to other languages? Or why this is the
> >>>> main issue holding Python back?
> >>> The base assumption is: there is some core issue holding Python back?
> >>> Nah.
> >> Any thought about drag-and-drop GUI builder in IDLE?
> > Sure; someone should write one, or several. That isn't a toolkit issue.
> Sure it is, if it's concerning ease of writing a GUI-based program using
> that particular toolkit.
Yes, because the IDE (toolchain) is lacking. Which isn't about the
underlying toolkit - both Qt and Gtk provide the ability to load a UI
from an XML file. Then the IDE needs to understand relating GUI events
to signal handlers in the code. AFAIK, that doesn't exist for Python.
However the underlying functionality *does* exist, and work, and has for
some time. I can assign a method to an event in Glade - but it is still
entirely up to the programmer to create a method with the same name and
the correct signature in the correct class - which is entirely automated
in Java / .NET IDEs. That is a big deal as applications become larger
and more sophisticated, it removes an enormous amount of tedium.
<http://www.pygtk.org/articles/pygtk-glade-gui/Creating_a_GUI_using_PyGTK_and_Glade.htm>
NOTE: Glade is obsolete, GtkBuilder is the replacement, but I can't find
anything on GtkBuilder + Python.
> > 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.
> They seems to be
> contradictory to me. The simplicity and ease of use of a library depends
> on how well-designed their API is,
Yea. Which is an implementation detail.
> and how "pythonic" the API appears to
> a python programmer (unittest, for example, looks more Java-ish than
> pythonic).
So... improve the binding. That is a really silly reason to develop a
new toolkit.
Simon Hibbs
>If we are to make progress, I can see two obvious approaches:
>1) Improve Tkinter to the point where it is supportable and supported
>by a good fraction of Python programmers
>or
>2) Drop Tkinter as the default and use something else.
IIRC Guido has ruled out officialy adopting a full-bore GUI toolkit
such as WxPython or PyQT, or even a supercharged verison of Tkinter,
into the standard library. There are two main reasons. One is that
doing so would more than double the standard Python distribution's
disk footprint, to no advantage for non-graphical target systems or
developers wanting to use native GUI APIs. Another is that it wouldn't
make any of the other options go away, so e.g. if PyQT were chosen,
anyone wanting to use WxPython would have to install it as well,
creating even more bloat.
GUI toolkits are major projects with their own development cycles and
roadmaps that may not match with that of the standard library. They
are also still rapidly evolving. The standard library should only
contain stable, mature code bases. Furthermore the core Python dev
team have limited resources. Increasing the officialy maintained code
base by 2x or more just isn't supportable.
Tkinter is perfectly adequate for basic GUIs. If you want something
more sophisticated there are plently of high quality, well documented
alternatives to match your platform or functionality requirements.
Simon Hibbs
Ben Finney
> 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'.
In that case, you have rather a misconception about how these things
progress. The PtB in Python won't be saying anything normative on the
matter unless there is an established code base to inspect, preferably
with an established user base of that code.
There's not a lot of point in pronouncing either way on vapourware. If
you claim it would be a useful thing to have, let's see the tangible
demonstration of that claim in the form of Python libraries.
--
\ “The most common way people give up their power is by thinking |
`\ they don't have any.” —Alice Walker |
_o__) |
Ben Finney
Steven D'Aprano
> 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'.
You have the process backwards there. The Python-Dev team isn't going to
push one GUI toolkit as the One True Toolkit unless the wider community
standardises on it first.
Consider the plight of the Python developers. They're an all-volunteer
effort, and although a handful of them are partially funded by the PSF or
other companies like Google, they're still chronically undermanned and
overworked. Just go and look at the bug tracker and see how many bugs
languish for want of somebody to work on them. The last thing they're
going to do is take on a project of the magnitude of creating a new GUI
toolkit. A full-featured toolkit is a project at least as big as the rest
of Python plus the standard library, and probably bigger. You're asking
them to double their work load to suit your aesthetic judgement that none
of the existing toolkits are good enough.
[...]
> Third: "I'm curious why you think fragmented GUI choices is a particular
> problem for Python compared to other languages? Or why this is the main
> issue holding Python back? "
> It's not a particular problem for Python compared to other languages.
> It's a general problem for all programming languages.
I don't see why you think so. Well, Apple believes so, and twenty years
ago I agreed with them, but having looked at how Macintosh and it's
consistent look-and-feel has repeatedly failed to set the world alight
against Windows and its multitude of inconsistent GUIs, I'm no longer
convinced by Steve Jobs' argument.
It's 2010 and despite all of Apple's marketing, design excellence and
consumer mindshare, their share of the PC market is still about the same
as it was in the mid-80s and well under their peak of 12% in 1993.
(Depending on who is doing the reporting and how they calculate the
numbers, Apple Macintosh has anything from 3% to 8% market share, not
that much better than Linux at 1-2%. And the Linux figure is for sales,
not installations).
It seems to me that a consistent, best-of-breed look-and-feel is good for
creating a brand, but flexibility and choice is good for capturing a
market.
Consistency carries it's own dangers, and what you call "fragmentation"
simply means that GUI toolkits exist in a free market of ideas rather
than a centrally-planned monopoly. For idiots^W those who like Gnome,
there is PyGTK; for those who prefer their window manager to be
perpetually in pre-beta, there is PyKDE; if you like QT, there is PyQt;
if you have no aesthetic sense at all, there is tkinter; if you have a
hankering for the Good Old Days programming in Hypercard on a Mac SE,
there is Pythoncard; if you've drunk the corporate Koolaid, there are
Jython and IronPython with their own GUI widgets; if you want the choice
of developing for the desktop or the web, you might choose Pyjamas; and
so on.
There is, hopefully, a GUI toolkit for everyone, and no best-of-breed
because people will never agree on what best-of-breed would mean. You
call this fragmentation -- I call it freedom of choice.
--
Steven
Mark Lawrence
>
> Are you maintaining Tkinter or Tix or both? There is a nagging issue
> with Tix that needs fixing. Upon subbclassing some widgets and when
> using the import Tix and import Tix as *. Maybe it is already fixed in
> 3.0 (i have not checked) but we need to fix it.
>
> I am still currently rewriting Tkinter Tix and IDLE in my spare time
> but got a bit busy lately. Anyhoo, i would really like to bring some
> patches, upgrades, and just a general spit shining to the entire three-
> plexx so let me know.
I don't maintain either, I'm looking forward to seeing you do it.
Regards.
Mark Lawrence.
pyt...@bdurham.com
Have you checked out the Dabo framework? Dabo provides a set of tools
and underlying framework that makes VB style GUI development possible
using Python.
Dabo is designed to be GUI framework independent however it currently
only supports wxPython.
Dabo has a very friendly and helpful mailing list if you want to give it
a try.
Dabo can be found here:
http://dabodev.org
Malcolm
Mark Lawrence
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.
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
Lie Ryan
binding is part of the programmer-facing API, therefore it's not an
implementation detail.
>> They seems to be
>> contradictory to me. The simplicity and ease of use of a library depends
>> on how well-designed their API is,
>
> Yea. Which is an implementation detail.
>
>> and how "pythonic" the API appears to
>> a python programmer (unittest, for example, looks more Java-ish than
>> pythonic).
>
> So... improve the binding. That is a really silly reason to develop a
> new toolkit.
isn't that my whole point?
Terry Reedy
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
Arndt Roger Schneider
> 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
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.
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.
Grant Edwards
> On Jun 6, 2:22?pm, ant <shi...@uklinux.net> wrote:
>> I get the strong feeling that nobody is really happy with the state of
>> Python GUIs.
>
> 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
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
Gregory Ewing
> pygui ... has its own problems. ... the api sytle is not standard
> 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.)
--
Greg
Michael Torrie
> On Jun 7, 5:05 pm, Michael Torrie <torr...@gmail.com> wrote:
>
>> 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.
>
> 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.
alex23
> 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.
Ben Finney
> 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
Martin P. Hellwig
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
> 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
Arndt Roger Schneider
> 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
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"?
--
Steven
Martin P. Hellwig
> On Jun 8, 1:39 am, "Martin P. Hellwig"<martin.hell...@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.
>
> 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.
--
mph
Kevin Walzer
> On Jun 7, 11:51 pm, alex23<wuwe...@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.
>
I have no opinion on the merits of PyGUI itself, but after taking a
quick look at the site and the docs, it seems to be an abstraction API
over three different, platform-specific GUI toolkits--PyObjC (Mac),
PyGtk (X11) and Windows (pywin32). That means that, whatever its other
virtues, it certainly is *not* a lightweight GUI toolkit that could
easily be incorporated into the Python core library--it instead has
rather complex dependencies on both other GUI toolkits and Python
wrappers of those toolkits. (A wrapper of a wrapper of a wrapper....)
In my view, any original, Python-native implementation of a GUI toolkit
that is small enough to be included in the standard library will wind up
looking much like Tk. Tk implements its own API on each of the major
platforms, interfacing directly with the platform primitives at a low
level (Xlib, Carbon or Cocoa, and win32); it uses native widgets if they
map to its API and implements its own widgets in other cases. Because it
sticks to a limited widget set, it's able to to be small.
Since Tk already provides a basic GUI toolset, and Python can interface
with it more directly than it can with other toolkits (PyGui -> PyGtk ->
Gtk -> Xlib), it's not clear to me what is gained by starting from
scratch here. (Is it the presence of the Tcl interpreter? I know Tcl is
not to everyone's taste, but it is an amazing language...)
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Adam Tauno Williams
> Since Tk already provides a basic GUI toolset, and Python can interface
> with it more directly than it can with other toolkits (PyGui -> PyGtk ->
> Gtk -> Xlib),
"Python can interface with it more directly"
This statement is devoid of meaning.
--
Adam Tauno Williams <awil...@whitemice.org> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
Grant Edwards
> Since Tk already provides a basic GUI toolset, and Python can interface
> with it more directly than it can with other toolkits
>(PyGui -> PyGtk -> Gtk -> Xlib),
Compare that to this:
TkInter -> Tcl -> Tk -> Xlib
> it's not clear to me what is gained by starting from scratch here.
> (Is it the presence of the Tcl interpreter? I know Tcl is not to
> everyone's taste, but it is an amazing language...)
It's not clear to me that Tk is any more "direct" than any of the
other options.
--
Grant Edwards grant.b.edwards Yow! Are we laid back yet?
at
gmail.com
bart.c
"Grant Edwards" <inv...@invalid.invalid> wrote in message
news:hullf3$hl4$1...@reader1.panix.com...
> On 2010-06-08, Kevin Walzer <k...@codebykevin.com> wrote:
>
>> Since Tk already provides a basic GUI toolset, and Python can interface
>> with it more directly than it can with other toolkits
>>(PyGui -> PyGtk -> Gtk -> Xlib),
>
> Compare that to this:
>
> TkInter -> Tcl -> Tk -> Xlib
Is the Tcl intepreter really need to use this GUI? Why not:
(Pyton ->) Tkinter-API -> Xlib ?
Most of the work of designing a GUI is, well, designing it. That's already
been done for Tkinter so why not just implement the same spec in Python
(with whatever lower-level code is needed). Then extending it should be
simpler.
>> it's not clear to me what is gained by starting from scratch here.
>> (Is it the presence of the Tcl interpreter? I know Tcl is not to
>> everyone's taste, but it is an amazing language...)
Some people aren't interested in the amazing language. Only the graphics API
that goes with it.
--
Bartc
Terry Reedy
> Terry Reedy schrieb:
>> 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
> That was it! Be aware only tk canvas elements are exported to SVG by this
> package.
That is all I need at the moment, with no embedded controls, just lines,
fills, and a few text labels.
> Jeszra on the other hand converts an entire GUI into SVG.
I had the impression, without diving deeply into the doc, that jeszra is
not something I can call from a Python program but is a stand-alone app
for designing guis, with one of the output possibilities being svg and
another tkinter-based classes that could be used in a Python program.
I will look into it further when I need that.
> 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.
Thanks for the hint.
Terry Jan Reedy
Grant Edwards
>
> "Grant Edwards" <inv...@invalid.invalid> wrote in message
> news:hullf3$hl4$1...@reader1.panix.com...
>> On 2010-06-08, Kevin Walzer <k...@codebykevin.com> wrote:
>>
>>> Since Tk already provides a basic GUI toolset, and Python can interface
>>> with it more directly than it can with other toolkits
>>>(PyGui -> PyGtk -> Gtk -> Xlib),
>>
>> Compare that to this:
>>
>> TkInter -> Tcl -> Tk -> Xlib
>
> Is the Tcl intepreter really need to use this GUI?
Technically, no. But, that's what the maintainers have chosen to do
in order to reduce the amount of work needed.
> Why not: (Pyton ->) Tkinter-API -> Xlib ?
Because maintain a set of Python bindings for Tk would be a lot more
work.
> Most of the work of designing a GUI is, well, designing it. That's
> already been done for Tkinter so why not just implement the same spec
> in Python (with whatever lower-level code is needed). Then extending
> it should be simpler.
I'm not sure what you're asking. Are you asking why not develop
Python bindings for the Tk library the way other languages (e.g.
Scheme) did instead of having Tcl as a glue layer?
>
>>> it's not clear to me what is gained by starting from scratch here.
>>> (Is it the presence of the Tcl interpreter? I know Tcl is not to
>>> everyone's taste, but it is an amazing language...)
>
> Some people aren't interested in the amazing language. Only the
> graphics API that goes with it.
Some of us think is a crappy language. I wrote one small app in Tcl.
When I tried to write something a bit more sophistacated it was quite
clear that Tcl is a glue language, not a real application development
language. I switched to Scheme (which had Tk bindings) and later to
Python.
--
Grant Edwards grant.b.edwards Yow! Do you guys know we
at just passed thru a BLACK
gmail.com HOLE in space?
David King
> language unless we crack this problem.
But making *another* "one true GUI library" just fragments it further.
Nobody designs a GUI library intending it to suck.
Carl Banks
> On 2010-06-08, bart.c <ba...@freeuk.com> wrote:
> > Why not: (Pyton ->) Tkinter-API -> Xlib ?
>
> Because maintain a set of Python bindings for Tk would be a lot more
> work.
That would be Tk-API.
Tkinter-API means write a GUI toolkit that has the same API as
Tkinter, which is s Python module. So he suggests a native Python
toolkit (written as Python code or a C extension or both), that can
serve as a drop-in replacement for Tk-inter, that bypasses Tcl and Tk
altogether.
In the absense of other factors, it probably is better for an
interpreter for a language that claims to be a powerful for general-
purpose applications not to run another general-purpose interpreter to
do a common task like GUI. Those other factors aren't absent though.
Carl Banks
Martin v. Loewis
>
> Is the Tcl intepreter really need to use this GUI? Why not:
>
> (Pyton ->) Tkinter-API -> Xlib ?
Even if this was possible (which it is not), then you still would need
the Tcl interpreter: significant parts of Tk are written in Tcl, so
Tk won't work without the Tcl interpreter.
However, the Tk API doesn't provide all functionality that Tkinter
exposes; many features can only be invoked through Tcl.
Regards,
Martin
Grant Edwards
>> TkInter -> Tcl -> Tk -> Xlib
>>
>> Is the Tcl intepreter really need to use this GUI? Why not:
>>
>> (Pyton ->) Tkinter-API -> Xlib ?
>
> Even if this was possible (which it is not)
Why is it not possible? It seems to have been done for other
languages.
> then you still would need the Tcl interpreter: significant parts of
> Tk are written in Tcl, so Tk won't work without the Tcl interpreter.
>
> However, the Tk API doesn't provide all functionality that Tkinter
> exposes; many features can only be invoked through Tcl.
True. Were Tcl removed from the equation, then some feautures would
have to be re-implemented in Python.
--
Grant Edwards grant.b.edwards Yow! I've read SEVEN
at MILLION books!!
gmail.com
Ethan Furman
> On 2010-06-08, Martin v. Loewis <mar...@v.loewis.de> wrote:
>>> TkInter -> Tcl -> Tk -> Xlib
>>>
>>> Is the Tcl intepreter really need to use this GUI? Why not:
>>>
>>> (Pyton ->) Tkinter-API -> Xlib ?
>> Even if this was possible (which it is not)
>
> Why is it not possible? It seems to have been done for other
> languages.
>
>> then you still would need the Tcl interpreter: significant parts of
>> Tk are written in Tcl, so Tk won't work without the Tcl interpreter.
>>
>> However, the Tk API doesn't provide all functionality that Tkinter
>> exposes; many features can only be invoked through Tcl.
>
> True. Were Tcl removed from the equation, then some feautures would
> have to be re-implemented in Python.
>
So what functionality is available from Tk alone? From the very cursory
glance at the source files (mostly the readmes), it seems pretty
entwined with Tcl.
~Ethan~
Kevin Walzer
> Some people aren't interested in the amazing language. Only the graphics
> API that goes with it.
>
The Perl folks have stripped the Tk API away from Tcl with the Perl-Tk
GUI package: the result is no embedded Tcl interpreter, but it's also
hard to maintain. In fact, Perl-Tk has never been updated to run
natively on the Mac because of this. There are other Perl/Tk bindings
that do integrate the Tcl interpreter, and it makes it much easier for
the Perl/Tk bindings to evolve as Tk itself evolves.
Lie Ryan
How about shifting the viewpoint a little bit. Tcl is like regular
expression engine and the Tk is like the re API.
Much like regex a DSL for matching text, Tcl/Tk is pretty much a DSL for
creating GUI (anyone knows any real program fully written in
non-embedded Tcl?).
Nobody complains that python included a regular expression engine in its
standard distribution; so why complain that python included a Tcl
expression engine in its standard distribution.
Martin P. Hellwig
> Grant Edwards wrote:
>> On 2010-06-08, Martin v. Loewis <mar...@v.loewis.de> wrote:
>>>> TkInter -> Tcl -> Tk -> Xlib
>>>>
>>>> Is the Tcl intepreter really need to use this GUI? Why not:
>>>>
>>>> (Pyton ->) Tkinter-API -> Xlib ?
>>> Even if this was possible (which it is not)
>>
>> Why is it not possible? It seems to have been done for other
>> languages.
>>
Yes indeed, however gp forgot another step:
tkinter > tcl > tk > xlib/xcb > x server
There are already some more or less usable (though they look abandoned)
experiments that do this:
https://launchpad.net/twisted-x11
http://python-xlib.sourceforge.net/
However I don't think that x11 represents that majority (just a gut
feeling I have no data to back this claim up) of gui users, so an equal
solution should be found for windows and macs.
I do think it is technically possible to have your own window manager in
python on x11 but I have no idea if you have equal possibilities on mac
and windows (for example to define your own window decoration).
Though considering tk does just that I would guess this to be the case.
--
mph
geremy condra
This is a silly argument.
REs are not full programming languages, even from a theoretical point
of view, aMSN is written in Tcl, as wikipedia would have told you, and
having to depend on the tools of another language to get commonly
desired functionality is not a good thing for a programming language.
Geremy Condra
Martin v. Loewis
> On 2010-06-08, Martin v. Loewis<mar...@v.loewis.de> wrote:
>>> TkInter -> Tcl -> Tk -> Xlib
>>>
>>> Is the Tcl intepreter really need to use this GUI? Why not:
>>>
>>> (Pyton ->) Tkinter-API -> Xlib ?
>>
>> Even if this was possible (which it is not)
>
> Why is it not possible? It seems to have been done for other
> languages.
So you don't know for sure? Which implementation specifically
do you think of?
>
>> then you still would need the Tcl interpreter: significant parts of
>> Tk are written in Tcl, so Tk won't work without the Tcl interpreter.
>>
>> However, the Tk API doesn't provide all functionality that Tkinter
>> exposes; many features can only be invoked through Tcl.
>
> True. Were Tcl removed from the equation, then some feautures would
> have to be re-implemented in Python.
You mean, like the key bindings of all the widgets, and the ttk widget
set.
Regards,
Martin
Kevin Walzer
> Much like regex a DSL for matching text, Tcl/Tk is pretty much a DSL for
> creating GUI (anyone knows any real program fully written in
> non-embedded Tcl?).
http://www.amsn-project.net/
http://snackamp.sourceforge.net/
http://www.svi.nl/
http://installbuilder.bitrock.com/
http://www.gidhome.com/
http://www.ellogon.org/
etc.
Steven D'Aprano
> On Tue, Jun 8, 2010 at 3:09 PM, Lie Ryan <lie....@gmail.com> wrote:
>> Nobody complains that python included a regular expression engine in
>> its standard distribution; so why complain that python included a Tcl
>> expression engine in its standard distribution.
>
> This is a silly argument.
>
> REs are not full programming languages, even from a theoretical point of
> view,
True, but some theoretical extension to REs could be. If I've understood
correctly, Perl's regexes aren't actually regular expressions any more
(they're a superset) and might even be Turing Complete.
In any case, the point is not that you can or can't write your entire
application using a RE. The point is that regexes are a mini-language, a
DSL, not written directly in Python.
> aMSN is written in Tcl, as wikipedia would have told you, and
> having to depend on the tools of another language to get commonly
> desired functionality is not a good thing for a programming language.
I don't see why you think so. Python is specifically designed to be a
glue language, to bring together functionality from disparate components
written in other languages and provide a user-friendly language around
them. Fundamentally, what's the difference between these?
* CPython relies on Tk/Tcl for a GUI
* CPython relies on a C library for regular expressions
* IronPython relies on the .Net environment for everything
* Jython relies on Java libraries for many things
I don't see why that first one is so much worse than the others. Sure, it
adds an extra dependency to installing Python for GUI programming, but
that's no different to any other GUI toolkit: PyQt has Qt as a
dependency, PyGtk has Gtk as a dependency, etc. (I trust you're not
suggesting that every language needs to create its own fully-independent
GUI toolkit that talks directly to the hardware!)
What does it matter that Tk is Turing Complete and Qt or Gtk aren't?
In any case, if you consider Tkinter is harmful, don't use it. It isn't
like GUI programming in Python relies on it, there are alternatives.
--
Steven
Grant Edwards
> Am 08.06.2010 20:15, schrieb Grant Edwards:
>> On 2010-06-08, Martin v. Loewis<mar...@v.loewis.de> wrote:
>>>> TkInter -> Tcl -> Tk -> Xlib
>>>>
>>>> Is the Tcl intepreter really need to use this GUI? Why not:
>>>>
>>>> (Pyton ->) Tkinter-API -> Xlib ?
>>>
>>> Even if this was possible (which it is not)
>>
>> Why is it not possible? It seems to have been done for other
>> languages.
>
> So you don't know for sure? Which implementation specifically
> do you think of?
There was a Scheme implementation called STk that didn't use Tcl.
There was also a Perl implementation that didn't use Tcl.
--
Grant
Kevin Walzer
> On 6/8/10 6:09 PM, Lie Ryan wrote:
>> Much like regex a DSL for matching text, Tcl/Tk is pretty much a DSL for
>> creating GUI (anyone knows any real program fully written in
>> non-embedded Tcl?).
>
> http://www.amsn-project.net/
> http://snackamp.sourceforge.net/
> http://www.svi.nl/
> http://installbuilder.bitrock.com/
> http://www.gidhome.com/
> http://www.ellogon.org/
>
> etc.
>
and:
http://www.courseforum.com/
http://www.installjammer.com/
http://www.muonics.com/
http://moodss.sourceforge.net/
http://www.inivis.com/
http://www.codebykevin.com/portauthority.html
Kevin Walzer
> The same people who would fight
> to the death to protect Tkinter's existence in the stdlib never use
> the library anyway and personally hate it!
I want to keep it in the stdlib because I use it for all my apps, and
personally prefer it to any other GUI toolkit out there.
Mark Lawrence
> On Jun 8, 5:40 pm, geremy condra<debat...@gmail.com> wrote:
>> On Tue, Jun 8, 2010 at 3:09 PM, Lie Ryan<lie.1...@gmail.com> wrote:
>>> On 06/09/10 01:17, bart.c wrote:
>>
> the real problem. It blows my mind... The same people who would fight
> to the death to protect Tkinter's existence in the stdlib never use
> anyone with normal brain function? Not to me. It perplexes me to no
> end! Why do you protect that which you hate? But the even better
> question is why do you also fight against any attempt to make it
> better? hmm...? Talk about ironic!
>
> We have a problem and we need some good community discussion to bring
> about a solution. If all you have to say is...
>
> """I don't use Tkinter so i don't care!""""
> or
> """I don't even use GUI's so i don't give a flying fig!"""
> or
> """I can't get the GUI i want so screw all of you and the GUI you're
> pushing!"""
> or
> """I'm just trolling for the sake of trolling because i like to read
> my own press"""
>
> ... well just keep your negativity to yourself. When you have real
> solutions or real ideas that could foster real solutions then for
> Pete's sake bring them forth and let them be weighed in the balances
> of truth. But i can tell you right now, everyone will have to
> sacrifice something to get the perfect GUI for Python. Yes you heard
> me correctly, the perfect GUI for Python! Not the perfect GUI for you,
> me, or even xah lee!
>
> There is a bright side, this is the best discussion i have witnessed
> on this subject in two years (Probably due to fact that i did not
> instigate the discussion). So the question is what should we do and
> how should we do it?
>
> - We can fix Tkinter by making it lean and mean.
> - We can start fresh and really create something very Pythonic.
> - We can do nothing and sit around for another two years complaining
> like premenstrual Prima donna's.
>
> So keep the ideas rolling in people. We need to hear from every side
> of this forum.
Please be so kind as to stop using the term we when you (singular) mean
you (singular). Frankly I wouldn't consider writing a single line of
code along these lines as it's a complete non starter. My preference is
for the good old command line, mainly because research I read,
admittedly years ago, stated that using said beast was far more
efficient for experienced users than a GUI. If more recent research
suggests that this has changed then great, I'll just sit back and wait
until you (singular) write the code to provide the perfect GUI for
Python. I look forward to seeing the 0.01 release on 31/12/2015, if I'm
lucky.
Kindest regards.
Mark Lawrence.
p.s. as Stephen D'Aprano asked r u r?
geremy condra
<st...@remove-this-cybersource.com.au> wrote:
> On Tue, 08 Jun 2010 15:40:51 -0700, geremy condra wrote:
>
>> On Tue, Jun 8, 2010 at 3:09 PM, Lie Ryan <lie....@gmail.com> wrote:
>
>>> Nobody complains that python included a regular expression engine in
>>> its standard distribution; so why complain that python included a Tcl
>>> expression engine in its standard distribution.
>>
>> This is a silly argument.
>>
>> REs are not full programming languages, even from a theoretical point of
>> view,
>
> True, but some theoretical extension to REs could be. If I've understood
> correctly, Perl's regexes aren't actually regular expressions any more
> (they're a superset) and might even be Turing Complete.
I hereby theorize an extension to python that allows it to cook toast.
Therefore, python is a toaster.
> In any case, the point is not that you can or can't write your entire
> application using a RE. The point is that regexes are a mini-language, a
> DSL, not written directly in Python.
So is the string formatting mini-language. I wouldn't get all wrapped
up in the idea that its ok to include anything that can be called a
language just because we have RE support.
>> aMSN is written in Tcl, as wikipedia would have told you, and
>> having to depend on the tools of another language to get commonly
>> desired functionality is not a good thing for a programming language.
>
> I don't see why you think so. Python is specifically designed to be a
> glue language, to bring together functionality from disparate components
> written in other languages and provide a user-friendly language around
> them. Fundamentally, what's the difference between these?
I didn't argue that Tcl is bad. I argued that a dependency on it is
bad for python. Would you argue that Python should ship with
Perl and Java because there are best-of-breed tools in those
languages and python could leverage that? Of course not.
> * CPython relies on Tk/Tcl for a GUI
Unfortunately true.
> * CPython relies on a C library for regular expressions
Irrelevantly true.
> * IronPython relies on the .Net environment for everything
Since .Net (effectively) depends on Windows, I suggest that
IronPython should ship with Windows as well. After all, many
languages depend on the operating system- why should it be
so much worse to ship with one?
> * Jython relies on Java libraries for many things
See above.
> I don't see why that first one is so much worse than the others. Sure, it
> adds an extra dependency to installing Python for GUI programming, but
> that's no different to any other GUI toolkit: PyQt has Qt as a
> dependency, PyGtk has Gtk as a dependency, etc. (I trust you're not
> suggesting that every language needs to create its own fully-independent
> GUI toolkit that talks directly to the hardware!)
But we don't have any of those in the standard library.
> What does it matter that Tk is Turing Complete and Qt or Gtk aren't?
I wouldn't support including either of the above either, but it matters
because it's a top-ten programming language that has to bootstrap
its way into usefulness in a common part of the field in a pretty
unclean way.
> In any case, if you consider Tkinter is harmful, don't use it. It isn't
> like GUI programming in Python relies on it, there are alternatives.
You won't hear an argument out of me about pulling it out or leaving
it in- I think it was a bad decision to depend on it, but that it's too
late now and that's that.
Geremy Condra
Adam Tauno Williams
> > * IronPython relies on the .Net environment for everything
100% False; not "effectively" true at all. I run [and develop] .NET
applications on LINUX every day. IL and the CLR are standards.
> > I don't see why that first one is so much worse than the others. Sure, it
> > adds an extra dependency to installing Python for GUI programming, but
> > that's no different to any other GUI toolkit: PyQt has Qt as a
> > dependency, PyGtk has Gtk as a dependency, etc. (I trust you're not
> > suggesting that every language needs to create its own fully-independent
> > GUI toolkit that talks directly to the hardware!)
> But we don't have any of those in the standard library.
I just don't see why this is an issue? Every, or pretty darn close,
significant Python application depends on 3rd party
modules/component/libraries.
Adam Tauno Williams
> We have a problem
No, we don't. Or at least, I don't.
> """I don't use Tkinter so i don't care!""""
+1
> ... well just keep your negativity to yourself. When you have real
> solutions or real ideas that could foster real solutions then for
> Pete's sake bring them forth and let them be weighed in the balances
> of truth. But i can tell you right now, everyone will have to
> sacrifice something to get the perfect GUI for Python.
And I'll be riding winged Unicorn's in New York's Time Square tomorrow.
That's as likely as a "perfect GUI" (whatever that means).
> Yes you heard
> me correctly, the perfect GUI for Python! Not the perfect GUI for you,
> me, or even xah lee!
A "perfect GUI for Python" is just a nebulous fantasy.
> There is a bright side, this is the best discussion i have witnessed
> on this subject in two years (Probably due to fact that i did not
> instigate the discussion). So the question is what should we do and
> how should we do it?
> - We can fix Tkinter by making it lean and mean.
> - We can start fresh and really create something very Pythonic.
> - We can do nothing and sit around for another two years complaining
> like premenstrual Prima donna's.
Option #4 - we can continue to very effectively develop solutions with
the situation as it is. Witness the awesome Zeitgeist application in
GNOME 3 - a GUI, developed in *gasp* Python. A real working solution
that is part of a major project... Hmmmm.
> So keep the ideas rolling in people. We need to hear from every side
> of this forum.
Meanwhile everyone who disagrees with you will be told "well just keep
your negativity to yourself". So much for "every side".
Signing out of this thread.
Ben Finney
> On Jun 8, 5:38 am, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>
> > 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"?
>
> Steven, i've always thought of you as one of the more intelligent
> readers of this list and again you have proven me correct.
Yes, thank you, Steven, for identifying this irritant. I'll add
identity-hopping to the list of offenses, and add this new identity to
my kill-file.
--
\ “The difference between religions and cults is determined by |
`\ how much real estate is owned.” —Frank Zappa |
_o__) |
Ben Finney
geremy condra
<awil...@whitemice.org> wrote:
> On Tue, 2010-06-08 at 18:12 -0700, geremy condra wrote:
>
> 100% False; not "effectively" true at all. I run [and develop] .NET
> applications on LINUX every day. IL and the CLR are standards.
Fine, then they can ship it with Linux too, just for you. My point
stands.
>> > I don't see why that first one is so much worse than the others. Sure, it
>> > adds an extra dependency to installing Python for GUI programming, but
>> > that's no different to any other GUI toolkit: PyQt has Qt as a
>> > dependency, PyGtk has Gtk as a dependency, etc. (I trust you're not
>> > suggesting that every language needs to create its own fully-independent
>> > GUI toolkit that talks directly to the hardware!)
>> But we don't have any of those in the standard library.
>
> I just don't see why this is an issue? Every, or pretty darn close,
> significant Python application depends on 3rd party
> modules/component/libraries.
What does that have to do with the python itself?
Geremy Condra
Robert Kern
> On Jun 8, 8:35 pm, Ben Finney<ben+pyt...@benfinney.id.au> wrote:
>
>> Yes, thank you, Steven, for identifying this irritant. I'll add
>> identity-hopping to the list of offenses, and add this new identity to
>> my kill-file.
>
> identity. So now i am somehow so annoying as to require a plonking.
> NEWS FLASH! I am the same person i was 1 minute ago, 1 hour ago, 1 day
> ago, 1 week ago... the only thing that has changed is your perception
> of me.
It means that he, very charitably, gives new irritants the benefit of the doubt.
By changing identities, you are abusing this good behavior. By connecting your
identity to the previous one, his doubt is removed.
> Now i ask of you Ben, who is flawed?
Still you.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Steven D'Aprano
> I didn't argue that Tcl is bad. I argued that a dependency on it is bad
> for python. Would you argue that Python should ship with Perl and Java
> because there are best-of-breed tools in those languages and python
> could leverage that? Of course not.
Surely that depends on the tool, how difficult it would be for Python to
duplicate the functionality, and how important it is to provide the tool
as a standard product.
In any case, Python doesn't ship with Tcl and Tk. They are dependencies
*only if you use Tkinter*. It's not compulsory.
[steve@sylar ~]$ python2.6
Python 2.6.4 (r264:75706, Feb 1 2010, 13:33:07)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.6/lib-tk/Tkinter.py", line 39, in <module>
import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named _tkinter
Now, we might argue that the Python standard library "must" have a GUI
toolkit, in which case it's going to have some non-trivial dependency. I
don't see why it's so much worse to depend on Tcl/Tk compared to some
other external toolkit.
And even if it were undesirable to rely on any external toolkit, I don't
think it's terribly likely that with the resources available to the PSF
anyone is going to create Yet Another GUI Toolkit specifically for
Python. We might agree that, in a perfect world, it would be nice if
Python had no external dependencies at all (well, apart from the OS of
course), but it isn't going to happen anytime soon. Not unless you're
volunteering? :)
--
Steven
geremy condra
<steve-RE...@cybersource.com.au> wrote:
> On Tue, 08 Jun 2010 18:12:05 -0700, geremy condra wrote:
>
>> I didn't argue that Tcl is bad. I argued that a dependency on it is bad
>> for python. Would you argue that Python should ship with Perl and Java
>> because there are best-of-breed tools in those languages and python
>> could leverage that? Of course not.
>
> Surely that depends on the tool, how difficult it would be for Python to
> duplicate the functionality, and how important it is to provide the tool
> as a standard product.
Well, I guess that's where we more or less differ. If I felt like there
were a piece of infrastructure for my language so critical that I
simply had to drag java along to have it, I would seriously question
whether it was worth my time to pursue the project at all.
> In any case, Python doesn't ship with Tcl and Tk. They are dependencies
> *only if you use Tkinter*. It's not compulsory.
<snip>
Tkinter- its not only capable of making terrible-looking UIs, its also
capable of not being there when you need it! This is not a point in
its favor.
> Now, we might argue that the Python standard library "must" have a GUI
> toolkit, in which case it's going to have some non-trivial dependency. I
> don't see why it's so much worse to depend on Tcl/Tk compared to some
> other external toolkit.
I don't argue that. I don't think it or any other GUI toolkit belong in the
stdlib, although if I had to pick one I'm pretty sure Tkinter wouldn't be
it.
> And even if it were undesirable to rely on any external toolkit, I don't
> think it's terribly likely that with the resources available to the PSF
> anyone is going to create Yet Another GUI Toolkit specifically for
> Python. We might agree that, in a perfect world, it would be nice if
> Python had no external dependencies at all (well, apart from the OS of
> course), but it isn't going to happen anytime soon. Not unless you're
> volunteering? :)
Actually, I've had to do pretty much this on two separate occasions,
and its not fun. Part of the reason why I like the idea of a sumo
distribution- you can keep the core trim and low-dependency, while
making sure that platforms where bits are cheap have the goodies
that developers want.
Geremy Condra
Steven D'Aprano
> We have a problem
You keep saying that, but you've given no good reasons for why we should
believe you, or what the nature of this problem supposedly is.
The current situation has broad community support: there's a relatively
lightweight GUI toolkit that ships with Python (Tkinter), even if it's
not beloved by all neither is it especially hated, and an extremely
healthy ecosystem of many alternative GUIs built on top of Qt, wxWindows,
GTK+, and others. Where's the problem?
> So keep the ideas rolling in people. We need to hear from every side of
> this forum.
I think the only way to end this pointless discussion is this:
"Hitler would have loved Tkinter!"
Now that we've run into Godwin's Law, can we get back to something more
productive? No need to thank me.
--
Steven
Robert Kern
> On Jun 8, 10:09 pm, Robert Kern<robert.k...@gmail.com> wrote:
>
>> It means that he, very charitably, gives new irritants the benefit of the doubt.
>> By changing identities, you are abusing this good behavior. By connecting your
>> identity to the previous one, his doubt is removed.
>
> Ben you're so blinded by animosity that you cannot see. He kill-filed
> me because he is so vehemently against me on a personal level.
You can read minds?
> So much
> against me that even the sight of the very words i write send him into
> fits of uncontrollable rage.
And clairvoyance! Such wonders!
> This must be the case or why would he
> need to hide his eyes completely from my words. Could he not just
> exercise a bit of self restraint and skip my posts if they start to
> annoy too much?
Yes, he is. He happens to be using a technological aid in order to do so
efficiently. You misunderstand the purpose of a kill-file.
> Apparently not. He is unable to control his actions so
> he must go to the extreme of kill-file.
>
> But you know i think it boils down to fear really. He is comfortable
> in his life and wishes to keep it as cookie cutter as he can. Any
> outside influence must be quashed before these meddling forces can
> take hold of him. He is so fearful of seeing the light in an opposing
> argument that blinding himself from reality is easier than facing
> reality.
Ah, so you are a psychoanalyst, too? Amazing!
Gregory Ewing
> PyGUI ... certainly is *not* a lightweight GUI toolkit that could
> easily be incorporated into the Python core library--it instead has
> rather complex dependencies on both other GUI toolkits and Python
> wrappers of those toolkits.
I don't see how the dependencies could be regarded as "complex".
There's more or less only one on each platform, and they're
pretty standard accessories for the platform concerned. You could
say there are two on Linux if you count gtk itself, but you almost
certainly already have it these days if you're running any
kind of desktop at all.
It's true that just having PyGUI itself in the standard library
wouldn't be sufficient, but that's also true of Tkinter today --
you need Tcl/Tk installed in order to use it, and that doesn't
come bundled with Python on all platforms. The same thing
applies to some other stdlib modules, such as sqlite. So just
having a dependency doesn't necessarily preclude a package from
being included in the stdlib.
Having said all that, I would like to eliminate some of the
depedencie. At some point I'll probably re-do the Windows
implementation using ctypes, because pywin32/mfc is hindering
more than helping in some areas. I'm also thinking about ways
to interface directly with Cocoa without going through pyobjc.
But all that is some way off in the future after I get the API
nailed down more.
--
Greg