Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

Yes I did and that's how it is.

And then you go and advocate a single toolkit! Do you not see the
inherent contradiction there? While it's certainly not impossible,
the case is hardly obvious for one GUI toolkit for all possible UIs.
You certainly have not presented it, and rantingrick never will.

Think about all the programmers earning their butter and bread .
Forget toolkits and widgets for awhile.
What remains are specific types of human/computer interactions,
a visual representation on a screen and a predefined behaviour
for said human action.

Also known as "toolkits and widgets". Talking about such things are
inescapable.

E.g. a button is:
A function gets asychnronously performed in response to
a finger/mouse click and release inside a certain screen area.

No, that is not the definition of a 'button', not even when we choose
to ignore how it is rendered, which you cannot ignore even if you wish
to pretend you can. Otherwise, I could always treat hyperlinks and
buttons as equivalent and even interchangeable. Unfortunately, they
are no such things.

--A widget is essentially a logical abstraction.

No, as much as we try we cannot divorce presentation from behavior
fully.

MacApp is/was cross-platform, Apple pulled the plug
on the non-mac platforms; the industrie
consortium took charge of the other platforms.

MacApp didn't even see the start of cross-platform development until
1996, four years after wxWidgets. It was not cross-platform from the
start and only became cross-platform when all of Apple's other cross-
platform endeavours failed.

Adam

 

[rantingrick]

On Jan 18, 4:45 pm, Arndt Roger Schneider <[email protected]>

No, that is not the definition of a 'button', not even when we choose
to ignore how it is rendered, which you cannot ignore even if you wish
to pretend you can.  Otherwise, I could always treat hyperlinks and
buttons as equivalent and even interchangeable.  Unfortunately, they
are no such things.

What! YES it is Adam! And you just exposed yourself as an
argumentative moron!

A hyperlink and a button are EXACTLY the same thing "functionality"
wise. The fact that they look different has nothing to do with the
argument. Would you say that a Ford Escort and a Dodge Viper do not
function in basically the same way. Sure one looks much prettier and
goes much faster however they both have four wheels, and engine, a
drivetrain, an outer shell, burn gasoline, and are basically people
movers. In other words they are both cars! *slap*

No, as much as we try we cannot divorce presentation from behavior
fully.

More argumentative crap. Adam you are incapable of compromise or
reason... or maybe both. Try more facts next time.

 

[Adam Skutt]

What! YES it is Adam! And you just exposed yourself as an
argumentative moron!

A hyperlink and a button are EXACTLY the same thing "functionality"
wise.

:active, :visited:, :hover, and the concept of "onhover" all would
like to have a word with you. They have different presentation which
yields to different functionality: if it's important to tell a user
"Hey, you've been there before", then a button is entirely unsuitable,
while a hyperlink is designed precisely for that situation.
Hyperlinks change their presentation to indicate mouse focus
(nevermind the mouse cursor itself normally), buttons don't
necessarily do either[1]. Hyperlinks can certainly decay to become
button-like, but buttons cannot do everything hyperlinks can do.

Checkboxes and radio buttons are a much better rebuttal, as they
usually present "almost" the same API and expect the same model on
part of the application programmer. It's the "almost" that kills us:
radio buttons only behave in the desired way when part of a button
group, forcing us to be cognizant of the fact we're creating radio
buttons (since we must create button groups as well). Checkboxes
support tri-state functionality, and sometimes radiobuttons do as
well. Pushbuttons do no such thing[2].

It'd be nice to be able to support the abstract notion of a "button"
and get what I wanted, but that requires guessing at intent and
computers are notoriously lousy at that.

The fact that they look different has nothing to do with the
argument.

Actually it does, but they not only look different, they /behave/
differently. Both in terms of how a user interacts with them, and in
terms of how we interact with them in code.

More argumentative crap. Adam you are incapable of compromise or
reason... or maybe both. Try more facts next time.

I'm not the one suggesting that the only difference between a
hyperlink and a button is how they are rendered, FFS man, have you
ever even used a modern GUI? Are you posting from tin?

Adam

[1] Even when they do, it's not intended to be controlled by the
application. Native button widgets have no real built-in support for
user-controlled styling on mouse focus, you'd have to do the drawing
yourself (at which point you might as well write a custom widget).
[2] I'm ignoring the UI problems with radio buttons and checkboxes, of
course. Point is, even among things where the differences are subtle,
the differences have inescapable ramifications on the code I write.

 

[rantingrick]

I'm not the one suggesting that the only difference between a
hyperlink and a button is how they are rendered, FFS man, have you
ever even used a modern GUI?

Yes i have logged many hours building GUI's... and from the comments
you've made so far... obviously more that you have! But your defiance
intrigues me. You still argue in the face of undeniable fact.

Ok, i will lower the bar a bit this time. They (the buttons) are
exactly the same thing except for a few superficial differences. Both
"buttons" wait for activity (either by pointer, or touch) and then
execute a linked block of code. The fact that hyper-link displays a
visual clue that it has been "activated" before is just superficial.
Heck a "button" displays a visual clue that it is a button and you are
not arguing that point? And this moronic argument of "nhover"
":visited", and ":active" is completely unfounded as buttons have
mouse events such as "Enter" and "Leave", just to name a few.

Adam, it is now evident that your view of the world is, at best, a
superficial one. You are shallow and incapable of any coherent
abstract reasoning abilities. I genuinely hope this is due to some
emotional distress you are suffering and not a chronic condition,
because if not, you need to give some deep mediative thoughts to how
you are perceiving the world around you to heal your mind of this
improper processing. Being argumentative just for the sake of being
argumentative is a never ending cycle of foolishness. Now, at some
point earlier you had begin to display some coherency and insights. I
sure hope that behavior will return soon..?

 

[Corey Richardson]

[snip]

Adam, it is now evident that your view of the world is, at best, a
superficial one. You are shallow and incapable of any coherent
abstract reasoning abilities. I genuinely hope this is due to some
emotional distress you are suffering and not a chronic condition,
because if not, you need to give some deep mediative thoughts to how
you are perceiving the world around you to heal your mind of this
improper processing. Being argumentative just for the sake of being
argumentative is a never ending cycle of foolishness. Now, at some
point earlier you had begin to display some coherency and insights. I
sure hope that behavior will return soon..?

Because insulting others is completely how things get done. As to the
button/hyperlink, they may both share some common functionality and even
a common ancestor, they are different beings, otherwise they wouldn't be
two separate things. It may even be that a hyperlink is a type of
button, but that doesn't make a button a hyperlink. (Plant/tree,
rectangle/square type deal).

I for one am quite pleased with Tkinter up to this point. It allowed me
to come in with extremely minimal GUI experience, and make something
that worked with minimal effort. It was simple to understand, no
concepts of slots and signals to learn. A project I'm working on
requires PyQt, so I use PyQt. Is the fact that it's not in the stdlib a
detriment? No. I think Tkinter _should_ be in the stdlib because it's
simple. If something else were to take it's place I would hope that it
is as easy to learn/use as Tkinter is.

But I think this whole thread has gotten off topic. Why should Tkinter
be replaced? Why was it added there in the first place? What should
replace it, and why? Instead of arguing about little piddly details like
the difference between a button and a hyperlink, just stick to the task
at hand that you yourself presented.

My two cents,
~Corey

 

[rantingrick]

Only if you have no clue what you're talking about whatsoever.  You
perceive them as useless because you're apparently incapable of
understanding the simplest GUI precepts, nevermind APIs, which is why
you've gone from Pure Python GUI to wxWidgets to this OpenGUI bullshit
you're now espousing.  Desperately clinging to a position doesn't make
you look intelligent.

Plus, I'm not sure what entropy you're talking about, but I'm not
seeing it.  MS continues to innovate, Apple continues to innovate,
some portions of the Linux community do innovative things.  Though
most people just want to put something together and call it a day, and
the functionality provided by a lot of toolkits is beyond adequate for
that.

Adam, i am speaking specifically about how multiplicity is ruining
everything. The multiplicity is "entropy incarnate". And selfishness
is the heathen prodigy of multiplicity. What we have today is a zig
saw puzzle of GUI libraries. Not one of them can solve all the GUI
problems we have before us because of selfishness and lack of true
cooperation between the diverse parties. And to add insult to injury
none of the pieces where ever made so that they could mate correctly.
We have been the victims of you own selfishness and vanity begotten
directly from our fostering of multiplicity. Once you understand what
i am talking about, you will see how it applies to almost every system
we humans have ever created. And more disturbingly, how difficult it
will be to undo this backward facing inertia we have set in motion.
Years, decades, centuries have been lost due to nothing more than
selfishness. When will we see the light?

 

[Patty]

----- Original Message -----
From: "Corey Richardson" <[email protected]>
To: <[email protected]>
Sent: Tuesday, January 18, 2011 5:19 PM
Subject: Re: Tkinter: The good, the bad, and the ugly!

[snip]

Adam, it is now evident that your view of the world is, at best, a
superficial one. You are shallow and incapable of any coherent
abstract reasoning abilities. I genuinely hope this is due to some
emotional distress you are suffering and not a chronic condition,
because if not, you need to give some deep mediative thoughts to how
you are perceiving the world around you to heal your mind of this
improper processing. Being argumentative just for the sake of being
argumentative is a never ending cycle of foolishness. Now, at some
point earlier you had begin to display some coherency and insights. I
sure hope that behavior will return soon..?

Because insulting others is completely how things get done. As to the
button/hyperlink, they may both share some common functionality and even
a common ancestor, they are different beings, otherwise they wouldn't be
two separate things. It may even be that a hyperlink is a type of
button, but that doesn't make a button a hyperlink. (Plant/tree,
rectangle/square type deal).

I for one am quite pleased with Tkinter up to this point. It allowed me
to come in with extremely minimal GUI experience, and make something
that worked with minimal effort. It was simple to understand, no
concepts of slots and signals to learn. A project I'm working on
requires PyQt, so I use PyQt. Is the fact that it's not in the stdlib a
detriment? No. I think Tkinter _should_ be in the stdlib because it's
simple. If something else were to take it's place I would hope that it
is as easy to learn/use as Tkinter is.

But I think this whole thread has gotten off topic. Why should Tkinter
be replaced? Why was it added there in the first place? What should
replace it, and why? Instead of arguing about little piddly details like
the difference between a button and a hyperlink, just stick to the task
at hand that you yourself presented.

My two cents,
~Corey

I agree with Corey - I also had very little experience with creating a GUI
and using Tkinter combined with PIL plus a little help from various docs
and getting a couple questions answered, I was pleased to find that it
required very few actual lines of code to create a basic small window and
display text and pictures that I am happy with and I am sure I can use this
small module as a base to expand on if I want to.

Regards,

Patty

 

[rantingrick]

I for one am quite pleased with Tkinter up to this point. It allowed me
to come in with extremely minimal GUI experience, and make something
that worked with minimal effort. It was simple to understand, no
concepts of slots and signals to learn.

I agree. I have written tons of code with Tkinter and i love both the
simplistic API and the geometry managers to name a few pros.

If something else were to take it's place (Tkinter) I would hope that it
is as easy to learn/use as Tkinter is.

I completely agree! And we should expect it to be even better!

But I think this whole thread has gotten off topic. Why should Tkinter
be replaced?

Well there are many good reasons and most are not apparent to those
with minimal to average Tkinter experience. My main beef with Tkinter
is that it is limited --both widget wise and extensible wise-- and
that we must recognize that web and mobile platforms are getting
bigger every day. We cannot ignore this fact. The GUI landscape is
changing fast and whilst desktop support will be needed for many years
to come, mobile and web must be addressed and addressed quickly!

Why was it added there in the first place?

Well from what i understand (and feel free to correct me anyone) Guido
wanted a GUI both for batteries included and for ease of introductory
GUI programming. So he choose Tkinter because it would be both easy to
integrate and easy to use. And i totally agree with these ideas.
However that was circa 1990's and we are now in 2011. I think Tkinter
(whilst still quite useful) is well pasted it's prime. We must
consider keeping Pythons stdlib up to date. And doing that might mean
we need to make some very tough decisions. Guido brought about
Python3000 and i think he's on the right track, however more must be
done. Change while painful is always necessary. "Change with the times
or get left behind."

What should
replace it, and why?

Well that seems to be the burning question. Now, after considering all
the options i can't see anything that truly moves us forward to were
we "should" be. I do think wx would be a move "forward" however only a
very *small* move in the larger scope of things. We need to think
bigger, we need to think of mobile and web interfaces if we want
Python to compete in the next 10 years. So when considering anything
we must consider all three.

Instead of arguing about little piddly details like
the difference between a button and a hyperlink, just stick to the task
at hand that you yourself presented.

You are absolutely correct Corey. Thanks for getting us back on topic!

 

[rantingrick]

I agree with Corey - I also had very little experience with creating a GUI
and using Tkinter combined with PIL plus a little help from various docs
and getting a couple questions answered, I was pleased to find that it
required very few actual lines of code to create a basic small window and
display text and pictures that  I am happy with and I am sure I can use this
small module as a base to expand on if I want to.

Hello Patty and welcome to the debate,

I am happy to see the simplicity of Tkinter has helped moved you into
the joys of GUI programming. I remember my initial days with Tkinter
and i remember the delight in achieving my first small GUI utilities.

Like you, i love the simplistic nature of Tkinter and if TclTk had as
large a widget base and maturity as wxWidgets then we would be closer
to the 21st century GUI library that Python desperately needs. However
as i know --and you will find out over time-- Tkinter is greatly
lacking in very important widgets. Widgets that are part of every
major GUI app you could imagine.

If all you do is create utilities for yourself or small apps you can
get by with Tkinter just fine. However if you try to go any further
you will then realize the limits of TclTk --and not Tkinter-- are
really the culprits behind the scenes.

But again, all this is moot because as this debate has evolved so too
has my understanding of where we need to be focusing or efforts -- and
*desktop only* is not going to cut it for the future of Python's std-
GUI-lib. We need to take a step back and see the larger picture.
Currently we have our heads stuck in the vacuum of python land,
however this GUI problem is much, much larger!

 

[Corey Richardson]

I agree. I have written tons of code with Tkinter and i love both the
simplistic API and the geometry managers to name a few pros.



I completely agree! And we should expect it to be even better!

What out there is there that meets those requirements?

Well there are many good reasons and most are not apparent to those
with minimal to average Tkinter experience. My main beef with Tkinter
is that it is limited --both widget wise and extensible wise-- and
that we must recognize that web and mobile platforms are getting
bigger every day. We cannot ignore this fact. The GUI landscape is
changing fast and whilst desktop support will be needed for many years
to come, mobile and web must be addressed and addressed quickly!

Mobile and web certainly have their place, but it Python the place for
it? Sure, Python can be used as the back-end of web sites, but not up
front like Java or Flash (aside from Jython). Especially mobile. Python
was not intended for a mobile platform not should it be made to fit that
niche. Python has its place, but your cell phone is not it.

[snip]

What should
replace it, and why?

Well that seems to be the burning question. Now, after considering all
the options i can't see anything that truly moves us forward to were
we "should" be. I do think wx would be a move "forward" however only a
very *small* move in the larger scope of things. We need to think
bigger, we need to think of mobile and web interfaces if we want
Python to compete in the next 10 years. So when considering anything
we must consider all three.

From that, it appears we need to:

1. Replace Tkinter with something more modern and feature-complete, but
just as easy to use.
2. Add a web framework/web-GUI

As a web interface are you thinking something like Java's Swing or
something like Django?

Given the above, what do you guys (python-list, not just rantingrick)
think fills the spot the best?

Would these items inclusion in the stdlib entail unnecessary cruft added
on to the size of the stdlib, are they completely cross-platform (as far
as Python itself is)?

Let's try not to get off track like this thing has been since it was
started. Either get things done or shut up ;-). I think this is almost
ready to split into a "real" thread, not just a giant cyclic argument
that this thread has been.

~Corey

 

[rantingrick]

On 01/18/2011 08:41 PM, rantingrick wrote:

1. Replace Tkinter with something more modern and feature-complete, but
just as easy to use.
2. Add a web framework/web-GUI

That would be a HUGE step in the correct direction. It would not solve
all our problems however its a start. Like i mentioned earlier with
Tkinter it is fact that sooner or later you will come up against the
glass ceiling. At that point your only alternative is to toss away
everything you have learned/written and re-learn another GUI library
like wxPython. This is what bothers me most about Tkinter. It just
sums to wasted time and energy. If we had a simplistic wxGUI in the
stdlib, when you hit the ceiling and need to go further you could then
scale nicely to the feature richness of wxPython as a 3rd party
download -- WITHOUT relearning/rewriting everything!

Given the above, what do you guys (python-list, not just rantingrick)
think fills the spot the best?

Well i hope some heavy weights weigh in however i must tell you that
it don't happen very often.

 

[Corey Richardson]

That would be a HUGE step in the correct direction. It would not solve
all our problems however its a start. Like i mentioned earlier with
Tkinter it is fact that sooner or later you will come up against the
glass ceiling. At that point your only alternative is to toss away
everything you have learned/written and re-learn another GUI library
like wxPython. This is what bothers me most about Tkinter. It just
sums to wasted time and energy. If we had a simplistic wxGUI in the
stdlib, when you hit the ceiling and need to go further you could then
scale nicely to the feature richness of wxPython as a 3rd party
download -- WITHOUT relearning/rewriting everything!

You mentioned having a segment of wxPython in the stdlib earlier. If
this actually feasible from a legal standpoint, and would the
maintainers of wxPython be willing to put it in the stdlib? Not to
mention the wonderful people over at python-dev.

Why would you add in only a part of wxPython, instead of all of it? Is
the work to cut it down really an advantage over the size of the full
toolkit? From what I just checked, the source tarball is 40MB. Can that
much really be added to the Python stdlib? What other alternatives are
there, besides wxPython, that are perhaps a bit smaller.

 

[Adam Skutt]

What out there is there that meets those requirements?

Nothing, and I somewhat doubt there ever will be. Tk is somewhat of
an anomaly at this point. Most of the trend in GUI toolkits is to
become more HTML/JS/CSS like in nature, which isn't something I
personally agree with. I certainly don't think it makes life any
easier for the programmer, especially starting out. It might make
certain types of applications (e.g., CRUD) easier, but that's not a
laudable goal in the least.

Mobile and web certainly have their place, but it Python the place for
it? Sure, Python can be used as the back-end of web sites, but not up
front like Java or Flash (aside from Jython). Especially mobile. Python
was not intended for a mobile platform not should it be made to fit that
niche. Python has its place, but your cell phone is not it.

I don't think that's true per se, but I don't think it's relevant. A
single GUI toolkit for traditional computers, for web, and mobile is a
difficult task, one that no one has accomplished. MS has gotten
closest, and I'd hesitate to call Silverlight a success. Plus,
Silverlight is plugin-based rich applications (ala Flash), not HTML/
CSS/Javascript which is what most people mean/want for the web.

Adding HTML/CSS/Javascript to the mix takes the problem from bad to
awful, in my opinion. I'm sure the various Pyjamas users might take
issue with that, but what works best inside a web browser (with its
various enforced limitations) isn't what works best inside a client-
side application (be it web delivered or not).

As a web interface are you thinking something like Java's Swing or
something like Django?

You pretty clearly need both. There are times when web pages are what
I want, there are times when they are inadequate and I need more
functionality. You certainly don't want either Swing or Django,
though.

Given the above, what do you guys (python-list, not just rantingrick)
think fills the spot the best?

Nothing, but I'm not even convinced the spot needs to be filled.
Certainly no one's made an actual case for why, much less how.
Regardless, if it's really what you want, you'd have to write it
yourself. Personally, while Silverlight has some interesting ideas,
I'd recommend not using it as a base, especially if Python is your
target language.

Would these items inclusion in the stdlib entail unnecessary cruft added
on to the size of the stdlib, are they completely cross-platform (as far
as Python itself is)?

Depends on exactly what you do, but you'd likely end up no bigger
than .NET or Java. I'll leave it to others to decide whether that's a
good or bad thing.

Let's try not to get off track like this thing has been since it was
started.

That was and rantingrick's goal from the get go and still is his goal.
Otherwise, he wouldn't have changed his position three times now and
be overdue for a fourth. Otherwise, he would have answered my / your
question about why bother putting a minimized version of wxWidgets in
the standard library by now as opposed to the whole damn thing. He
dodges technical questions because he lacks even the most elementary
understanding. He'll do the same to you and only offer absurd
platitudes and insults in return, as opposed to actual working
technical solutions. Hell, he can't even offer up a consistent
problem to solve, and he's honestly over do for changing it
altogether..

Adam

 

[rantingrick]

You mentioned having a segment of wxPython in the stdlib earlier. If
this actually feasible from a legal standpoint, and would the
maintainers of wxPython be willing to put it in the stdlib? Not to
mention the wonderful people over at python-dev.

This might come as a shock to you, but it really doesn't matter what
the wxPython folks think about the inclusion of wxPython into the
stdlib. If they are against it (or simply don't care) then they can
continue to focus their efforts on the full version. No harm done,
really. As far as python-dev is concerned -- it does matter! However
if the community wants change, and makes enough noise, they will have
no choice either.

Why would you add in only a part of wxPython, instead of all of it?

see my next answer for detail...

Is
the work to cut it down really an advantage over the size of the full
toolkit? From what I just checked, the source tarball is 40MB. Can that
much really be added to the Python stdlib?

40MB is far too big. Much of wxPython is thousands of widgets that
have no buisness in the stdlib. We only want a very limited set (much
like what Tkinter is composed of now) and then for the people who want
to create professional GUI's they can download the full 40MB. The
great advantage here is scalability. Tkinter cannot do this. And
anybody who alludes to this is a liar.

What other alternatives are
there, besides wxPython, that are perhaps a bit smaller.

Well i am open to any and all alternatives. However no many have been
brought forward. My dream would be to have something completely python
based, although i realize that the work involved is far too enormous.
So we must build from something that already exists. Nothing is really
perfect. WxPython IS NOT perfect however it is a step forward.

As far as alternative here is a list...

http://docs.python.org/faq/gui

 

[rantingrick]

That was and rantingrick's goal from the get go and still is his goal.
Otherwise, he wouldn't have changed his position three times now and
be overdue for a fourth.  Otherwise, he would have answered my / your
question about why bother putting a minimized version of wxWidgets in
the standard library by now as opposed to the whole damn thing.  

You know Adam i was just begining to like you again . I HAVE
answered that question a many, many times and if you actually take the
time to read my posts AND comprhend them you would have found that
answer by now. psst! Just recently i answered it again. And no, i will
not quote myself for your convince. Get off your lazy butt and find it
yourself!


[...snip: Character assassination ...]

 

[Corey Richardson]

This might come as a shock to you, but it really doesn't matter what
the wxPython folks think about the inclusion of wxPython into the
stdlib. If they are against it (or simply don't care) then they can
continue to focus their efforts on the full version. No harm done,
really. As far as python-dev is concerned -- it does matter! However
if the community wants change, and makes enough noise, they will have
no choice either.


see my next answer for detail...


40MB is far too big. Much of wxPython is thousands of widgets that
have no buisness in the stdlib. We only want a very limited set (much
like what Tkinter is composed of now) and then for the people who want
to create professional GUI's they can download the full 40MB. The
great advantage here is scalability. Tkinter cannot do this. And
anybody who alludes to this is a liar.


Well i am open to any and all alternatives. However no many have been
brought forward. My dream would be to have something completely python
based, although i realize that the work involved is far too enormous.
So we must build from something that already exists. Nothing is really
perfect. WxPython IS NOT perfect however it is a step forward.

As far as alternative here is a list...

http://docs.python.org/faq/gui

If that's what you believe, I don't think many (if any) here have an
issue with replacing Tkinter with something that has more features and
is just as easy to use. Write up a full-on proposal, including technical
feasibility of splitting up wxPython, and send it to python-ideas. After
they give some feedback, modify and send to python-dev. If it's well
written and makes sense, I'm sure they'll lend an ear. Just don't keep
getting off topic and I'm sure people will take you more seriously next
time. The insulting doesn't help either side.

</thread>

 

[rantingrick]

If that's what you believe, I don't think many (if any) here have an
issue with replacing Tkinter with something that has more features and
is just as easy to use.

Yea, and you're basing that on facts from where? If you haven't
noticed by now NEWSFLASH! nobody from Python-dev has weighed in. Where
is Steve Holden on the issue... who knows? Where is his subordinate on
this?

Write up a full-on proposal, including technical
feasibility of splitting up wxPython, and send it to python-ideas. After
they give some feedback, modify and send to python-dev. If it's well
written and makes sense, I'm sure they'll lend an ear.

Obviously you've never dealt with these folks before have you?

Just don't keep
getting off topic and I'm sure people will take you more seriously next
time. The insulting doesn't help either side.

Yea, thats all it takes Corey. Obviously you have not been around
here long and know that because your spirit is not broken yet. But
don't worry Corey, because if you hang around long enough these
monsters will crucify you. Then you will understand why i have to rant
so much, and why we find ourselves a full decade behind in GUI
libraries with no good solution in sight. They can find a thousand
reasons not to remove Tkinter and not one of them have an once of
vision or thought applied. These people live on emotion, one hand
washes the other, and back door politics. That is the current state of
Python-dev as it relates to the "peasents". We are nothing to them.

Python has lost all vision as a community. This is no doubt the
beginning of the end. Better check out GO...

 

[Corey Richardson]

Yea, and you're basing that on facts from where? If you haven't
noticed by now NEWSFLASH! nobody from Python-dev has weighed in. Where
is Steve Holden on the issue... who knows? Where is his subordinate on
this?


Obviously you've never dealt with these folks before have you?


Yea, thats all it takes Corey. Obviously you have not been around
here long and know that because your spirit is not broken yet. But
don't worry Corey, because if you hang around long enough these
monsters will crucify you. Then you will understand why i have to rant
so much, and why we find ourselves a full decade behind in GUI
libraries with no good solution in sight. They can find a thousand
reasons not to remove Tkinter and not one of them have an once of
vision or thought applied. These people live on emotion, one hand
washes the other, and back door politics. That is the current state of
Python-dev as it relates to the "peasents". We are nothing to them.

Python has lost all vision as a community. This is no doubt the
beginning of the end. Better check out GO...

Bye.

 

[Adam Skutt]

Why would you add in only a part of wxPython, instead of all of it? Is
the work to cut it down really an advantage over the size of the full
toolkit? From what I just checked, the source tarball is 40MB. Can that
much really be added to the Python stdlib? What other alternatives are
there, besides wxPython, that are perhaps a bit smaller.

The source tarball from the wxPython.org website contains a full
version of wxWidgets in addition to the actual wxPython
functionality. A python distribution would certainly contain solely
the latter and require the end user to already have wxWidgets
installed in a suitable fashion. The actual full wxPython binding is
~100 MiB uncompressed, ~15 MiB compressed BZIP2, but it also includes
a lot of stuff that could possibly be removed and/or reduced, like
full documentation, examples, etc. It can be shrunk even further by
taking a dependency on swig and regenerating the bindings at compile
time (they're shipped prebuilt). At which point, it's pretty damn
small. Not as small as all of the Tk functionality, I think, but well
under 10MiB compressed.

The problem to me isn't the size (though some might find it
objectionable), but the system dependencies you have to take:
wxWidgets requires GTK+ on UNIX, which requires a whole mess of crap
in term, plus swig, plus whatever else I may or may not be missing.
I'm also not 100% certain as to whether it's as portable as Tk is
today.

At any rate, if the size is an issue, culling widgets is a lot of an
effort for not much of a gain, especially when you look at the bigger
picture of, "Every file I have to download to build python from
scratch" Minimizing what's in the Python distribution does not change
the size of the dependency set one bit, and that dwarfs the python
code in any case. That is what you want to avoid in my opinion.

Adam

 

[Corey Richardson]

The source tarball from the wxPython.org website contains a full
version of wxWidgets in addition to the actual wxPython
functionality. A python distribution would certainly contain solely
the latter and require the end user to already have wxWidgets
installed in a suitable fashion. The actual full wxPython binding is
~100 MiB uncompressed, ~15 MiB compressed BZIP2, but it also includes
a lot of stuff that could possibly be removed and/or reduced, like
full documentation, examples, etc. It can be shrunk even further by
taking a dependency on swig and regenerating the bindings at compile
time (they're shipped prebuilt). At which point, it's pretty damn
small. Not as small as all of the Tk functionality, I think, but well
under 10MiB compressed.

The problem to me isn't the size (though some might find it
objectionable), but the system dependencies you have to take:
wxWidgets requires GTK+ on UNIX, which requires a whole mess of crap
in term, plus swig, plus whatever else I may or may not be missing.
I'm also not 100% certain as to whether it's as portable as Tk is
today.

At any rate, if the size is an issue, culling widgets is a lot of an
effort for not much of a gain, especially when you look at the bigger
picture of, "Every file I have to download to build python from
scratch" Minimizing what's in the Python distribution does not change
the size of the dependency set one bit, and that dwarfs the python
code in any case. That is what you want to avoid in my opinion.

Adam

That is a pretty large dependency to rely on, and it is rather
undesirable IMO.

~Corey