R
rantingrick
You know Adam some people could use that very same sarcastic argument
against you for claiming that Tkinter is "just as good" or *giggles*
"better" than wxPython.
You know Adam some people could use that very same sarcastic argument
against you for claiming that Tkinter is "just as good" or *giggles*
"better" than wxPython.
O
Octavian Rasnita
From: "rantingrick" <[email protected]>
Sent: Monday, January 17, 2011 8:53 PM
Subject: Re: Tkinter: The good, the bad, and the ugly!
These are very true statements Octavian! I had always believed that
Python should include a GUI AND and IDE even though Tkinter and IDLE
are severely dated. Now i am thinking that maybe we should judt dump
both and leave it that way.
Why did i previously think this way? Well my concern was to keep the
goals of GvR alive. That is that programming should be for everyone
and having a simplistic IDE and GUI in the stdlib help foster these
goals. However that was circa 1980's and we now find our selfs a
decade past the 21st century. We now have a huge amount of 3rd party
GUI's and IDE's. Do we even need to include them any more? Sure one
could always argue batteries included however with the plethera of 3rd
party downloads, the batteries may not be included, but they are
located witin reach at the reqister check out
Q. Do we need ANY GUI or ANY IDE in the stdlib anymore?
I say probably not considering the availability of 3rd party
downloads. What say you, Python community?
And one more thing. Not all the Python programmers create desktop apps so a GUI lib is useless. Some of them use Python only for web programming or only for system administration.
Octavian
Sent: Monday, January 17, 2011 8:53 PM
Subject: Re: Tkinter: The good, the bad, and the ugly!
These are very true statements Octavian! I had always believed that
Python should include a GUI AND and IDE even though Tkinter and IDLE
are severely dated. Now i am thinking that maybe we should judt dump
both and leave it that way.
Why did i previously think this way? Well my concern was to keep the
goals of GvR alive. That is that programming should be for everyone
and having a simplistic IDE and GUI in the stdlib help foster these
goals. However that was circa 1980's and we now find our selfs a
decade past the 21st century. We now have a huge amount of 3rd party
GUI's and IDE's. Do we even need to include them any more? Sure one
could always argue batteries included however with the plethera of 3rd
party downloads, the batteries may not be included, but they are
located witin reach at the reqister check out
Q. Do we need ANY GUI or ANY IDE in the stdlib anymore?
I say probably not considering the availability of 3rd party
downloads. What say you, Python community?
And one more thing. Not all the Python programmers create desktop apps so a GUI lib is useless. Some of them use Python only for web programming or only for system administration.
Octavian
O
Octavian Rasnita
From: "Adam Skutt" <[email protected]>
Subject: Re: Tkinter: The good, the bad, and the ugly!
And we're not discussing those languages, we're discussing Python,
which has an explicit policy of "batteries included". As such,
criticism of the standard library is perfectly acceptable under the
name "Python", whether you like it or not. Besides, it's inevitable
anyway.
"Batteries included"?
Python doesn't follow this policy at all. We can say that maybe PHP follows it, but not Python.
And if this is the wanted policy, why should it be "cheap batteries included" and not "strong batteries included"?
Octavian
Subject: Re: Tkinter: The good, the bad, and the ugly!
And we're not discussing those languages, we're discussing Python,
which has an explicit policy of "batteries included". As such,
criticism of the standard library is perfectly acceptable under the
name "Python", whether you like it or not. Besides, it's inevitable
anyway.
"Batteries included"?
Python doesn't follow this policy at all. We can say that maybe PHP follows it, but not Python.
And if this is the wanted policy, why should it be "cheap batteries included" and not "strong batteries included"?
Octavian
M
Martin P. Hellwig
On 01/17/11 19:39, rantingrick wrote:
<cut<
Some systems, like FreeBSD have Tkinter and IDLE as a separate package
which is not installed by default. Purely because those systems don't
assume that the user has X installed.
Though since this is a windows world, that argument is rather mood.
But then again the win32 extension modules aren't installed by default,
rather inconsistent in that perspective.
You could argue that there is some advantage especially for starters,
having at least something to start on (IDLE), but on the other hand
there are already a couple of special 'distribution packages' that aim
to include anything remotely python related.
I think that the ones that should make these decisions (if any) are
those how spend _their_ time integrating the dependencies and making the
builds for public download.
Perhaps for pythons 3 lifetime there should still be a 'python'
maintained tkinter integration. But I don't see any reason why this
should be continued for 4, fortunately it is not my call and I actually
quite like Tkinter.
<cut<
<cut>
Some systems, like FreeBSD have Tkinter and IDLE as a separate package
which is not installed by default. Purely because those systems don't
assume that the user has X installed.
Though since this is a windows world, that argument is rather mood.
But then again the win32 extension modules aren't installed by default,
rather inconsistent in that perspective.
You could argue that there is some advantage especially for starters,
having at least something to start on (IDLE), but on the other hand
there are already a couple of special 'distribution packages' that aim
to include anything remotely python related.
I think that the ones that should make these decisions (if any) are
those how spend _their_ time integrating the dependencies and making the
builds for public download.
Perhaps for pythons 3 lifetime there should still be a 'python'
maintained tkinter integration. But I don't see any reason why this
should be continued for 4, fortunately it is not my call and I actually
quite like Tkinter.
A
Adam Skutt
You'd have this same argument regardless of GUI toolkit you end up
picking, or even if you choose to not include one at all. This would
be because none of them are universal solutions, all of them have
deficiencies (actual or perceived) that make them unsuitable for
certain applications.
Adam
A
Alexander Kapps
Available as 3rd party downloads:
XML,HTML,...
HTTP,FTP,SMTP,POP,IMAP/...
MD5,SHA,...
zip,bzip,...
and so on and so on and so on.
Remove them all just because they are available as 3rd party downloads?
The "Batteries included" of Python is just *great* and I vote for
*more* not less batteries!
Not all Python programmers do web programming, so please remove the
useless HTML junk too.
Almost every beginner wants to do GUIs or at least some graphic
stuff. Removing the GUI module from the stdlib would be plain wrong
IMHO. But I don't understand the whole issue anyway. It isn't that
you need to fire up your torrent client and wait 48 hours for the
Python download to complete. Why remove useful (to many, not most)
stuff from the lib?
R
rantingrick
Are you sure about that Martin?
))hmm?
M
Martin P. Hellwig
Yep when I started looking much more at other toolkits, I started to
Are you sure about that Martin?
hmm?
like Tkinter more and more. Maybe it its simplicity, or that not every
thing starts with a bloody g or that it is actually cross platform
usable without jumping through hoops charted in a map where lat/long
references have been omitted because in the future a map of mars will
not cause confusion, even though it is totally irrelevant now.
Actually my favourite GUI toolkit at the moment is pyjamas.
T
Terry Reedy
Ok, wxwidgets can look at least as good as tk. Agreed that wxpython
might instead link to the excellent wxwidgets page.
R
rantingrick
Thanks for being honest. We need more people acting in this manner and
just think of the progress we could make, it would wonderful!
You know we Python programmers are professional debaters. This has
been my take on the Python community. However without the virtues of
compromise and community spirit all we are going to do is fight like
cats and dogs forever to the very detriment of the very community we
wish to muster
We need to look at these problems from a community perspective and
tone down the rhetoric. The layer of thick sarcasm that exists is so
viscous and putrid that any semblance of civility is completely
impervious to it's gelatinous all encompassing mass. We need to get
more folks involved in the decision process. We need more community
discussion and less community corruption. Currently we have a small
subset of the community making a large proportion of the decisions. We
did have a monarchy ruled by our beloved dictator however it has
degenerated into a banana republic! We need democracy and we need it
now!
R
rusi
Lehman Beladys entropy law http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution
says
The quality of ... systems will decline unless they are rigorously
maintained and adapted to operational environment changes.
Just look at emacs --once upon a time the best editor for alpha geeks,
today unable to get rid of 40 years of cruft.
Guido's 'benevolent dictatorship' has so far kept python the exception
because
- he give powerful batteries to start with
- does not introduce junk
- is not afraid of backward incompatibility for the sake of clarity
and cleanliness (python3)
Gui (and web) frameworks are two of his more visible failures
R
rantingrick
This is both eloquent and frightening at the same time when applied to
the current state of Python's stdlib. We have come so far and forged a
path of langauge innovation. However we have now entered a state of
limbo, we have solidified -- This collective static state has
manifested both in the tangible (stdlib) and more frighteningly the
intangible (community). Are we going to allow this slow decay to
wither away all the work that has been done because we cannot come to
a consensus on anything as a community? Heck i'll bet we could not
even agree on what punch to serve at the next Pycon much less makes
some real decisions that concern this community.
When does the slightly overweight spare tire become the morbidly
obese? When does losing a few hairs become que ball histeria , and
when does the slow creeping of time catch up to the blissful ignorants
and mortality slap you in the face *slap*. Sadly and most often-ly
when the missed opportunities are now but wishful fantasies and
stories of glory days unrealized! Are we in those days as a community?
Maybe?
Today emacs, tomorrow Python.
His initial intention were pure. However TclTk may turn out to be
GvR's Achilles heel. It seems Tkinter has metamorphosis into some ill
legitimate red-headed step child that the community both hates and
loves at the same time. Or is something more sinister at work here?
Could a high ranking TclTk "Guru" be within the "inner circle" of
Python dev? Or maybe even Guido's close friend? Could emotions and
back door politics be standing in the way of Tkinters graceful exit?
Is hurting one or two peoples feelings really that bad in face of what
is best for a community?
In any event we definitely need a mid life crisis to wake ourselves
from this slow decay of narcissism, sarcasm, pretentiousness, apathy,
and just outright laziness that is destroying everything we hold
dear.
Because the bell that tolls, may just be our own (as a community).
R
rantingrick
I have proposed this before and i shall propose it again. Most of the
naysayers parrot off about how many people use Tkinter. Maybe they are
right, and maybe they are wrong. Nobody, and i repeat NOBODY even GvR
himself can offer reliable evidence as to how important moduleX *is*
or *is not* to this community... However i can!
I propose a truly democratic method by which we can gather REAL data
about what is important, and what is not important to the average
Python programmer. I am not suggesting that this data be an official
vote. I am only suggesting that those who walk the halls of
"privilege" should listen carefully to the peasants when making
decisions that affect the peasants.
To make a long story short my proposal is to send out a warning in the
next official release of Python. The warning will be as follows...
"""
-------------------------------
ModuleRemovalWarning: Tkinter
-------------------------------
The GUI module "Tkinter" is being considered for removal from the
Python stdlib FOREVER. If you use Tkinter and wish for it to stay in
the stdlib you need to visit "www.savetkinter.com" and cast your vote
now. The voting will end on dd/mm/yyyy so make sure to cast your vote
or don't be complaining
about it later. Note: Simon Cowell WILL NOT be making a celebrity
appearance!
"""
If i need to create a PEP i will.
naysayers parrot off about how many people use Tkinter. Maybe they are
right, and maybe they are wrong. Nobody, and i repeat NOBODY even GvR
himself can offer reliable evidence as to how important moduleX *is*
or *is not* to this community... However i can!
I propose a truly democratic method by which we can gather REAL data
about what is important, and what is not important to the average
Python programmer. I am not suggesting that this data be an official
vote. I am only suggesting that those who walk the halls of
"privilege" should listen carefully to the peasants when making
decisions that affect the peasants.
To make a long story short my proposal is to send out a warning in the
next official release of Python. The warning will be as follows...
"""
-------------------------------
ModuleRemovalWarning: Tkinter
-------------------------------
The GUI module "Tkinter" is being considered for removal from the
Python stdlib FOREVER. If you use Tkinter and wish for it to stay in
the stdlib you need to visit "www.savetkinter.com" and cast your vote
now. The voting will end on dd/mm/yyyy so make sure to cast your vote
or don't be complaining
about it later. Note: Simon Cowell WILL NOT be making a celebrity
appearance!
"""
If i need to create a PEP i will.
O
Octavian Rasnita
From: "Adam Skutt" <[email protected]>
Subject: Re: Tkinter: The good, the bad, and the ugly!
http://lmgtfy.com/?q=python+"batteries+included"&l=1
Well, this doesn't mean anything because Perl can also say that includes
batteries, and PHP can say it also.
You'd have this same argument regardless of GUI toolkit you end up
picking, or even if you choose to not include one at all. This would
be because none of them are universal solutions, all of them have
deficiencies (actual or perceived) that make them unsuitable for
certain applications.
Adam
You are perfectly right. Then why favor Tkinter and not WxPython. Why not
strip the Python package and offer WxPython and Tkinter separately?
Octavian
Subject: Re: Tkinter: The good, the bad, and the ugly!
http://lmgtfy.com/?q=python+"batteries+included"&l=1
Well, this doesn't mean anything because Perl can also say that includes
batteries, and PHP can say it also.
You'd have this same argument regardless of GUI toolkit you end up
picking, or even if you choose to not include one at all. This would
be because none of them are universal solutions, all of them have
deficiencies (actual or perceived) that make them unsuitable for
certain applications.
Adam
You are perfectly right. Then why favor Tkinter and not WxPython. Why not
strip the Python package and offer WxPython and Tkinter separately?
Octavian
O
Octavian Rasnita
From: "Alexander Kapps said:
No, they should not be removed because they don't cause any damage, very bad
damage as Tkinter does.
Well, in that case, why don't you agree to also include WxPython in the
Python package?
Why do you call it "html junk"?
Yes it can be useful for some people, but why promote it instead of
promoting a better library for beginners?
Octavian
O
Octavian Rasnita
From: "rantingrick" <[email protected]>
You know we Python programmers are professional debaters. This has
been my take on the Python community. However without the virtues of
compromise and community spirit all we are going to do is fight like
cats and dogs forever to the very detriment of the very community we
wish to muster
We need to look at these problems from a community perspective and
tone down the rhetoric. The layer of thick sarcasm that exists is so
viscous and putrid that any semblance of civility is completely
impervious to it's gelatinous all encompassing mass. We need to get
more folks involved in the decision process. We need more community
discussion and less community corruption. Currently we have a small
subset of the community making a large proportion of the decisions. We
did have a monarchy ruled by our beloved dictator however it has
degenerated into a banana republic! We need democracy and we need it
now!
Well, those who work have the latest word and they will decide what they
will want to do. We can just show our opinions and hope that they will care
and take the best decision.
The problem is that some people don't care and want to demonstrate that this
is very normal and that they are right, which is not good at all.
Octavian
You know we Python programmers are professional debaters. This has
been my take on the Python community. However without the virtues of
compromise and community spirit all we are going to do is fight like
cats and dogs forever to the very detriment of the very community we
wish to muster
We need to look at these problems from a community perspective and
tone down the rhetoric. The layer of thick sarcasm that exists is so
viscous and putrid that any semblance of civility is completely
impervious to it's gelatinous all encompassing mass. We need to get
more folks involved in the decision process. We need more community
discussion and less community corruption. Currently we have a small
subset of the community making a large proportion of the decisions. We
did have a monarchy ruled by our beloved dictator however it has
degenerated into a banana republic! We need democracy and we need it
now!
Well, those who work have the latest word and they will decide what they
will want to do. We can just show our opinions and hope that they will care
and take the best decision.
The problem is that some people don't care and want to demonstrate that this
is very normal and that they are right, which is not good at all.
Octavian
O
Octavian Rasnita
From: "rusi" <[email protected]>
Lehman Beladys entropy law
http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution
says
The quality of ... systems will decline unless they are rigorously
maintained and adapted to operational environment changes.
Yes. Pretty right. Tkinter -> WxPython change would be a very good one.
Guido's 'benevolent dictatorship' has so far kept python the exception
because
- he give powerful batteries to start with
With the exception of Tkinter.)
- does not introduce junk
- is not afraid of backward incompatibility for the sake of clarity
and cleanliness (python3)
Well, on the long term this could be a very big disadvantage also. Of
course, the beginners won't care, but the old users and the companies that
would need to adapt the old code that might not work with newer versions of
Python won't like this incompatibility.
Gui (and web) frameworks are two of his more visible failures
Well, Python has good GUI libs , at least WxPython, however it is not one of
its included batteries.
Yes, for web programming Python is not as great as Perl, but I don't think
this has something to do with the core Python.
Octavian
Lehman Beladys entropy law
http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution
says
The quality of ... systems will decline unless they are rigorously
maintained and adapted to operational environment changes.
Yes. Pretty right. Tkinter -> WxPython change would be a very good one.
Guido's 'benevolent dictatorship' has so far kept python the exception
because
- he give powerful batteries to start with
With the exception of Tkinter.
)- does not introduce junk
- is not afraid of backward incompatibility for the sake of clarity
and cleanliness (python3)
Well, on the long term this could be a very big disadvantage also. Of
course, the beginners won't care, but the old users and the companies that
would need to adapt the old code that might not work with newer versions of
Python won't like this incompatibility.
Gui (and web) frameworks are two of his more visible failures
Well, Python has good GUI libs , at least WxPython, however it is not one of
its included batteries.
Yes, for web programming Python is not as great as Perl, but I don't think
this has something to do with the core Python.
Octavian
A
Adam Skutt
It means that Python intentionally endeavorer to include some sort of
rich and useful standard library as part of the language, ergo
criticisms of the language may include criticisms of its library, like
it or not. I'm not sure what makes you believe Perl or PHP are
relevant here.
As of now? There's no reason to remove what's there already as long as
carrying it as a dependency isn't creating problems for building and
distributing Python.
But I already mentioned an important reason earlier: the dependencies
of Tk are much, much smaller than the dependencies of WxWidgets
(though eventually this may change with the X11 port getting
complete). Another is that the scope and scale of WxWidgets is
problematic: since it's a cross-platform C++ solution it provides a
lot of things that it needs, but that Pyhton doesn't especially need
or want. It creates incompatibility issues because you end up with a
bunch of libraries that become useless when writing a GUI. This
problem is minimized with Tk when compared to WxWidgets, and most
other toolkits (certainly all the ones I've ever used).
Adam
A
Arndt Roger Schneider
Terry said:
Well, tosssing screenshots around doesn't prove wether
a framwork/toolkit is good or not;
It only displays the developers commitment to create
a work of art.
Lets examine one of your examples:
http://juicereceiver.sourceforge.net/screenshots/index.php#mac
Overall impression:
The software was designed for windows; more or less
following the windows hci-guidelines,
The windows version is resonable good.
About the Aqua screenshots:
1. Negative actions are located on the falling diagonale.
2-3. The select background and foreground inside the multi-column
listbox have the wrong color--the used color originates from text fields.
4. The multi-column listbox should have vertical gridlines.
5-6. Too much top and bottom padding inside the column header.
7. The column texture is wrong --there is a visible line in the bottom.
8. There are white boxess around the input fields.
9. Header column label and lisstbox content are not aligned.
10. There is separator line between the status bar and the
brusshed dialog.
11. Last picture: there is a single page inside the tabet
control.
12. Last picture: The text "Select radio ..." is trucated,
the dialog isn't large enough.
13. The Scheduler activation should come before
customizing the scheduler.
14. The dialog uses sunken group boxes for some sections,
these group should be 2% darker than their surrounding
container.
15. The spacing rules from the aqua hci guidlines are
violated. The inner tabset should have 20px distance from
both sides, 20px from the bottom, 14px from top.
16. Second last picture: The button lables are truncated.
17. Tree: Uses the wrong folder symbols--from windows--,
select background and foreground are wrong, too.
- The Aqua hci-guidlines discourage group boxes,
the same with the windows guidlines, too. Get rid
off group boxes.
- second last picture: There should be more top
padding for the checkbutton inside the white rectangle;
best the same as left-padding.
- There no focus frames visilbe inside these screenshots,
it would be interessting to see how those are realised.
- The icon buttons should be brushed, likewise shoud the
column header have brushed background.
- Aqua hci guidelines: All dialogs should
have a centered appearance.
Back to rantingrick 21st century toolkit/framwork:
Let's have a look at the numbers:
Worlwide pc market are 300 Million pcs per year,
this number includes desktops(2/3) and servers(1/3).
Your gui app is not relevant on servers.
Quite a good deal of the remaining pc's are sold in
countries with rampant ilict software copies;
Since there are no software cost for these copies
the people tend to install the big, bloated software
pieces from named computer companies
--you wont sell linux there, because it is more
expensive than an ilict windows+office++.
~ 100 Million potential new desktop users for you.
Apple's projection for the ipad in 2011 are 65 Million pieces,
iphone and ipod touch will be roughly the same.
130 Million ios pieces.
~ 130 Million new ios users for you.
The android market is still unclear, but I do suppose
it will rival ios, lets say 100 Million in 2011.
~ 100 Million new android users for you.
Microsoft mobile and blueberry are wildcards;
no serious forecast is possible for these devices.
Lets assume:
~ 50 Million blueberry, windows mobile.
Total is: 380 Million potential new user for your application.
wxWidgets: 36000000 LOC, python: 1400000 LOC
--these are very old numbers, but from the same time period.
wxWidgets on desktop, present for windows, Aqua and X11.
wxWidgets on ios, possible but unlikely, the thing is way to big
for any ios device.
wxWidgets on android not realistic.
wxWidgets on blueberry not possible.
wxWidgets on windows mobile; development is
silverlight with .net, so wxWidgets would have to be
ported to .net; not realistic.
python on desktop, present.
python on ios, possible --if not yet present.
python on android, present.
python on blueberry, possible.
python on windows mobile, present--but .net support deprecated by ms.
The smartphone and table market has only started, yet.
In 2011 the mobile market is already larger than the desktop pc,
almost 3 times largerv.
The desktop pc market is in decline; there is
however a shift toward pc-servers, instead.
It is anybodies guess how far the pc-desktop decline will go.
Every 21st century toolkit or framework must run on
mobile platforms!
wxWidgets was written ~1992, it is a copy of
mfc, which in turn is a copy of MacApp. MacApp
is also OSS, maintained through an industrie consortium.
Why do you not use the original framework?
Looking into wxWidgets:
The treeview: Trees do not work well with touchscreens.
Mutli-column-listbox: Doesn't work at all with touchscreens,
instead use simple lists with multi-line entries.
Interactivity: keyboard focus, shortcuts, function keys,
active foreground, active background are obsolete.
hovering tooltips obsolete, status bar to large, obsolete.
scrolled dialogs, obsolete. OK, Cancel, Retry, Abort
buttons, obsolete, file dialogs obsolete, old style printing
obsolete, drag-and-drop obsolete...
Screen resolution:
The time of 72ppi CRT monitors is over. A GUI
framework/toolkit must be resolution independent,
including all icons and indicators;
it should use decluttering (newspeak:ZUI).
Summary wxWidgets:
wxWidgets is large scale C++ library from the 20th century,
solemnly dedicated toward desktop computers.
wxWidgets originates from a time before templates
were used in C++ and thus duplicates many of
today's C++ features.
wxWidgets is not suitable for a modern type
GUI ad thus clearly not the toolkit/framework
of the 21st century.
-roger
O
Octavian Rasnita
From: "Arndt Roger Schneider said:
This is the most important thing, because most users use Windows. Those who
have other preferences are not forced to choose Windows, so it's their
choice, and if the interface doesn't look so nice, that's it.
Python is an open source software and the programmers that use Python might
also prefer to offer open source software for free so this is not important.
And "not legal" is not a very correct term, because somebody from Iran or
North Corea must respect the laws from his/her country and in her/his
country some things might not be forbidden by law, so it may be perfectly
legal.
This is a bad comparison because the programs targetted to the mobile phones
are in most cases very different than the programs that need to be used on
the desktop.
Do you want to say that WxPython is not good just because it doesn't work
well on mobile phones?
Those numbers show that only the mobile phones are important, because there
are more mobile phones than computers.
Well, Python needs a better GUI lib for using them on desktop computers, not
on mobile phones.
What do you mean by declining? Are there fewer desktop PCs today than a year
ago?
Who says that they are obsolete?
A good GUI interface should offer keyboard accessibility. Otherwise it is
broken.
Yes, Python should promote a good GUI lib for desktop computers, and not a
poor GUI lib for desktop computers that might also work on other platforms.
Why do you think that everything what's modern is better?
Octavian