Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Tkinter: The good, the bad, and the ugly!

Reply
Thread Tools

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

 
 
Adam Skutt
Guest
Posts: n/a
 
      01-18-2011
On Jan 18, 4:45*pm, Arndt Roger Schneider <(E-Mail Removed)>
wrote:
> Adam Skutt schrieb:
> > Until we have pixel-perfect touch sensors, toolkits for devices with
> > pointer interfaces (e.g., PCs) and toolkits for devices with touch
> > interfaces (e.g., phones and tablets) will necessarily be different.

>
> > You note this yourself: the UI paradigms that work well when you have
> > a pixel-perfect pointer do not work at all when you have a touch
> > screen, especially on a limited size and resolution display.

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

> > Because it's not cross-platform, I'd imagine. *The entire point of
> > wxWidgets was to provide a cross-platform "OOP" UI toolkit. *It
> > closely copies MFC since MFC and XView were the two "backends" it
> > supported.

>
> 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
 
Reply With Quote
 
 
 
 
rantingrick
Guest
Posts: n/a
 
      01-18-2011
On Jan 18, 4:57*pm, Adam Skutt <(E-Mail Removed)> wrote:
> On Jan 18, 4:45*pm, Arndt Roger Schneider <(E-Mail Removed)>


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


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*


> > --A widget is essentially a logical abstraction.

>
> 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.
 
Reply With Quote
 
 
 
 
Adam Skutt
Guest
Posts: n/a
 
      01-19-2011
On Jan 18, 6:36*pm, rantingrick <(E-Mail Removed)> wrote:
On Jan 18, 4:57 pm, Adam Skutt <(E-Mail Removed)> wrote:
> On Jan 18, 4:45 pm, Arndt Roger Schneider <(E-Mail Removed)>
> > > 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.



> 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.
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      01-19-2011
On Jan 18, 6:23*pm, Adam Skutt <(E-Mail Removed)> wrote:

> 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..?
 
Reply With Quote
 
Corey Richardson
Guest
Posts: n/a
 
      01-19-2011
On 01/18/2011 07:53 PM, rantingrick wrote:
> On Jan 18, 6:23 pm, Adam Skutt <(E-Mail Removed)> wrote:
>
> [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
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      01-19-2011
On Jan 18, 2:37*pm, Adam Skutt <(E-Mail Removed)> wrote:
> On Jan 18, 2:11*pm, rantingrick <(E-Mail Removed)> wrote:


> > The entropy in GUIs has
> > exploded exponentially and rendered them all useless.

>
> 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?
 
Reply With Quote
 
Patty
Guest
Posts: n/a
 
      01-19-2011

----- Original Message -----
From: "Corey Richardson" <(E-Mail Removed)>
To: <(E-Mail Removed)>
Sent: Tuesday, January 18, 2011 5:19 PM
Subject: Re: Tkinter: The good, the bad, and the ugly!


> On 01/18/2011 07:53 PM, rantingrick wrote:
>> On Jan 18, 6:23 pm, Adam Skutt <(E-Mail Removed)> wrote:
>>
>> [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
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>


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

 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      01-19-2011
On Jan 18, 7:19*pm, Corey Richardson <(E-Mail Removed)> wrote:

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

 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      01-19-2011
On Jan 18, 7:39*pm, "Patty" <(E-Mail Removed)> wrote:
> 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!
 
Reply With Quote
 
Corey Richardson
Guest
Posts: n/a
 
      01-19-2011
On 01/18/2011 08:41 PM, rantingrick wrote:
> On Jan 18, 7:19 pm, Corey Richardson <(E-Mail Removed)> wrote:
>
>> 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!


What out there is there that meets those requirements?
>
>
>> 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!


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
if and and vs if and,and titi VHDL 4 03-11-2007 05:23 AM



Advertisments