Modernizing IDLE

[Mark Roseman]

Wanted to pass along a case study of some work being done to improve the look 
and feel of IDLE. This is a work-in-progress, gradually being integrated into 
the Python codebase. Given that, it's a great opportunity to get involved, 
provide some feedback, and make it even better!

http://www.tkdocs.com/tutorial/idle.html

As you can tell from the URL, it's part of a broader tutorial on modernizing 
the appearance of Tkinter based programs.

Mark
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic cross-platform GUI desingers � la Interface Builder (Re: what gui designer is everyone using)

[Mark Roseman]

 Dietmar Schwertberger  wrote:
> But the fact that Tkinter is still the standard GUI toolkit tells a lot
> about the situation...
>  ...
> Sure, I know how to code GUIs. But the learning curve is too steep
> for new users wanting to implement simple GUIs.


As is obvious to everybody, the massive interest in web-based 
applications in recent years has certainly not helped advance the state 
of the art in desktop GUI's, nor enlarged the developer population 
actively engaged in maintaining and improving desktop GUI toolkits.  

Given that, we're likely "stuck" with more or less what we have now, so 
let's make the best of it.

On the Tkinter front, I just want to reiterate two important points that 
are not nearly as well known as they should be.

First, it is possible and in fact easy to do decent looking GUI's in 
Tkinter, with the caveat that you do in fact have to do things very 
slightly differently than you would have 15 years ago. Shocking, I know.

Second, there does exist at least one fairly good source of 
documentation for new users wishing to do exactly this (according to 
many, many comments I have received), though that documentation is 
admittedly buried in a sea of out-of-date information that is still all 
too easy to find.

Please see http://www.tkdocs.com and in particular the tutorial there.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: converting from tcl/tkl to python

[Mark Roseman]

Hi Richard,

I would strongly second the advice that Kevin provided: rewriting is a 
substantial step not to be taken lightly. If a mere facelift is desired, 
migrating to the more modern tools provided in recent versions of Tcl/Tk 
may well meet your needs at a fraction of the cost/effort.

For additional information, you can point your technical people at 
http://www.tkdocs.com.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it necessary to call Tk() when writing a GUI app with Tkinter?

[Mark Roseman]

 Rick Johnson  wrote:
> Book authors and Doc authors are not always the most well informed; as
> we have witnessed by this very thread! Obviously these tutorials are more 
> like: "What NOT to do when coding Tkinter GUIs!" No wonder everyone hates 
> Tkinter.  :-)

Indeed. One of the things that motivated me to write the tutorial at 
http://www.tkdocs.com is the rather poor state (in terms of being out of 
date, incorrect, or demonstrating poor practices) of most Tkinter 
documentation.

Call it self-serving, but I think the Tkinter world would be a happier 
place if everyone just pointed to TkDocs. ;-)

To your point about explicit root, etc. I'll make the general 
observation that lots of different things work in a given situation, 
which is just fine for quick little hacky things. If people are doing 
anything more than a throwaway however, they'd be better served by 
spending a bit of time learning the conceptual underpinnings (e.g. 
http://www.tkdocs.com/tutorial/concepts.html) after which the "right" 
thing to do will be more obvious.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: WxPython versus Tkinter.

[Mark Roseman]

 Terry Reedy  wrote:
> > 1. The performance issues of having Tk use Tcl are negligible; the bulk
> > of Tk (code-wise and time-wise) are spent in C.  Tcl itself is also very
> > fast nowadays, using all the usual techniques that modern dynamic
> > languages use.
> 
> I have the impression that tcl is mostly used in initial setup and 
> configuration, as opposed to repetitive drawing to the screen. But I do 
> not really know.


Tcl as a scripting language is used during some initialization things, 
used to invoke callbacks, and a few other non-performance critical areas.

It sometimes helps to think of Tcl as a very powerful C library that 
happens to have a scripting language on top. :-)  For example, there are 
C functions in the Tcl library that do things like string management, 
cross platform I/O, very efficient hash tables, dynamic lists, etc. that 
are used everywhere inside Tk.  But none of those calls mean a trip 
through the Tcl interpreter per se.

Every dynamic language would have similar internals of course, though 
with slight differences and different API's. 

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: WxPython versus Tkinter.

[Mark Roseman]

 Terry Reedy  wrote:
> Tk itself is purely a gui package -- abstract widgits, geometry placers 
> to make them visible, and an event system to make them active. But it 
> does have the baggage of needing tcl included. About a decade ago, some 
> people had the idea of removing the tcl dependency, but nothing seems to 
> have come of that. For some people, the tcl baggage is reason enough to 
> be rid of tk.


Thanks for raising this point.  While I don't want to exhaustively 
respond to this, I would like to raise a few important points.

1. The performance issues of having Tk use Tcl are negligible; the bulk 
of Tk (code-wise and time-wise) are spent in C.  Tcl itself is also very 
fast nowadays, using all the usual techniques that modern dynamic 
languages use.

2. Some people do have moral/purity objections to including Tcl, and 
while I understand where the sentiment comes from, I think there are few 
solid engineering reasons for this.

3. Removing Tcl from Tk makes keeping up with changes in Tk very 
difficult.  The Perl people found this out; Perl/Tk extracted Tcl, and 
as a result remained using a 10 year old version of Tk because upgrading 
would have been too painful.  The newer Perl binding (Tkx) is in fact a 
ridiculously thin binding over the Tcl API, and makes keeping up to date 
with the newest Tk changes trivial, often requiring no code changes in 
the Perl binding. 

If anyone does have questions, comments or concerns about Python 
including a Tcl interpreter to use Tk, I'd be happy to try to explain or 
address them.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: WxPython versus Tkinter.

[Mark Roseman]

"Littlefield, Tyler"  wrote:
> Rather, I believe 
> those pushing accessibility should concentrate on the root cause; that 
> of fixing TKInter, and not forcing everyone else to use a different library.


Here, here.  From my queries to some of the Tcl/Tk folks, it seems that 
while the knowledge and expertise is not present in the core developer 
community, they would be more than happy to help people who do have some 
knowledge in this area so that Tk could be made to be more accessible.

Grand conspiracies aside, I think the development communities behind 
most GUI toolkits would be very receptive to people who could help make 
developing accessible applications with their toolkits feasible.

(And if/when this does get done for Tk, I promise at least to make sure 
that the tutorial at http:///www.tkdocs.com covers this topic).

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: WxPython versus Tkinter.

[Mark Roseman]

 "Octavian Rasnita"  wrote:
> But unfortunately it is not accessible for screen readers and it 
> discriminates many potential users.



Octavian, thank you for very clearly making and repeating your point 
about screen readers.  It is very obvious that at this point in time Tk 
(and hence Tkinter) is not a suitable candidate if screen readers are an 
important concern.

In an ideal world, every GUI would be fully accessible.  The reality is 
that sometimes, competing requirements will lead to accessibility being 
lower in the priority list than other things.  So with different 
requirements and priorities, the "best" solution will be different.

I don't object and in fact commend you for advocating for accessibility.  
I do feel you are not acknowledging and fully respecting that others may 
be in situations where accessibility may not be the primary concern.  

Thanks again
Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Mark Roseman]

Octavian,

Thank you for clearly articulating your concern that Tk does not provide 
any support for screen readers.

While I believe that people can have legitimate differences of opinion 
as to whether this merits its removal/replacement from stdlib, there is 
no question that this is a serious and significant limitation of Tk.

I will attempt to find out if there has been any work done in this area 
with Tk, and what it would take to address this important issue.

Thanks again
Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Mark Roseman]

If you guys spent 1/10th as much time articulating the problems you see 
with Tkinter (and being willing to listen when people offer solutions) 
as you do trying to convince everyone else you're right, you'd probably 
have ... well, anyway, no sense in being practical.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Mark Roseman]

> So let me hear of ANY improvements and/or suggestions for Tkinter/IDLE
> docs, code, or whatever.

Why don't you modify the IDLE code to use the newer ttk widget set, 
rather than what its using now?  You'd be surprised at how much 
difference you'll see.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Mark Roseman]

rantingrick  wrote:
> As is evidenced by the lack of
> development for Tkinter. But with Tkinter there is a larger problem,
> TclTk! Even Tk is not a full featured GUI library

Please, enough of this nonsense rant already! :-)

Discounting completely and without evidence or reason the considerable 
amount of volunteer work that continues to go into Tkinter (and Tk) and 
the people who use both does not help you advance your case.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Mark Roseman]

 "Martin v. Loewis"  wrote:
> > To quote from the first section of the tutorial at http://www.tkdocs.com
> 
> Unfortunately, neither that tutorial nor your postings are really 
> specific on what those changes might be. So I'm skeptical that they 
> actually exist, or, if they exist, that Tkinter needs to change at all 
> to accomodate them.


Ok, take a look at the last section on this page then: 
http://www.tkdocs.com/resources/backgrounder.html

The change is the new so-called 'themed' widget set (ttk), which 
complements but does not replace the standard widgets.  And yes, Tkinter 
would have to change a bit to use that widget set.  

Luckily enough, that work has also long been done (thanks to Guilherme 
Polo) and is a standard part of Tkinter as bundled with Python.

As for the changes that need to be made to Python application programs 
to use these 'ttk' widgets instead of the classic Tk ones, the TkDocs 
tutorial describes that in detail.

I trust that spending a few additional minutes with this material (or 
doing a Google search on 'ttk widgets') will help address your 
skepticism that changes were in fact made, and that these changes are 
being used everyday by developers working with Tk in Python, Ruby, Perl, 
Tcl and more.  

No question that awareness of these significant changes is far too low, 
and that perhaps some of the energy devoted to anxiety about Tkinter's 
shortcomings could be better spent learning about or communicating this 
information to developers who might easily benefit.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Mark Roseman]

 "Martin v. Loewis"  wrote:
> For the record, Python *does* include newer versions of Tk all the time.


Martin, just to reinforce the point... developers using Tkinter need to 
make some fairly minor changes to their application code to truly take 
advantage of the improvements in recent versions of Tk.  Without those 
app changes, they're not going to see any difference.

To quote from the first section of the tutorial at http://www.tkdocs.com

> This tutorial is designed to help people get up to speed quickly with 
> building mainstream desktop graphical user interfaces with Tk, and in 
> particular Tk 8.5, which is an incredibly significant milestone release.
> 
> The downside is that unless you know one or two particular things, it's 
> actually not that significant a release; For backwards compatibility reasons, 
> unless existing programs make a few simple changes, they won't look all that 
> much different. So while this tutorial will certainly benefit newcomers to 
> Tk, it will also help existing Tk developers bring their knowledge right up 
> to date. 

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Mark Roseman]

 "bart.c"  wrote:
> "Grant Edwards"  wrote in message 
> >> 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 ?
 

The Tk library was not built as a straight C/C++ library that interfaces 
to Xlib (or the Windows or Mac libraries), with a Tcl binding on top of 
that.

Tk was built expressly as a GUI toolkit for Tcl, and it uses Tcl very 
extensively throughout its implementation.  While there is a C API, it 
does not expose anywhere close to everything you'd need without making 
calls to the Tcl interpreter.  Whether you consider this a good or bad 
thing, that's the way it is.

So removing Tcl from the Tk library is not by any means practical.  Of 
the dozens of dynamic languages with Tk bindings, almost all interface 
to Tk through the Tcl interface.

The one notable exception is PerlTk, which went out of its way to 
extract Tcl from Tk, a herculean effort.  Though they managed, 
maintaining it was virtually impossible, so they are stuck with a 15+ 
year old version of Tk, taking into account none of the improvements 
made during that time.  The preferred Perl interface to Tk is a newer 
one called pTk, which wraps Tk's Tcl API, meaning it can easily keep up 
to date with improvements in Tk.  And the wrapper code itself is 
frighteningly small, what amounts to an exceedingly clever but minor 
engineering effort.

I hope this explains why trying to have Tkinter work without Tcl would 
be a non-starter.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Mark Roseman]

I'll venture to say that the path of least resistance (which includes 
little or modest development effort) would be for Python to retain 
Tkinter in the way it does now, but have Tkinter GUI's magically appear 
less horrid.

Guess what?  That's already happened.  Newer versions of Tk (which 
Tkinter uses internally of course) do look much better.

But, there are a few small API changes you'd need to make to Tkinter 
programs to see that improvement.

You can find these changes and improvements talked about at 
http://www.tkdocs.com

I can pretty much guarantee that continuing to share information about 
these new things in Tkinter, and keeping up with modern versions of Tk, 
is a whole lot less work than the massive engineering efforts people are 
talking about as alternatives.

(Not to say the end results, if they were ever completed, wouldn't be 
better going a different way...)

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Tkinter Programming by John Grayson

[Mark Roseman]

 Peter  wrote:
> Besides, the book is mainly about using Python with Tkinter - and
> Tkinter hasn't changed that much since 2000, so I believe it is just
> as relevant today as it was back then. 

I'd say that Tkinter has substantially changed - with the introduction 
of the 'ttk' themed widgets.  I cover these in my tutorial at 
http://www.tkdocs.com

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An assessment of Tkinter and IDLE

[Mark Roseman]

r  wrote:
> On Aug 28, 11:12 am, Mark Roseman  wrote:
> > Would it be useful to link to this from the main Python Tkinter
> > documentation?
> 
> Thanks Mark, but i would hate to see more links to TCL code in the
> python docs. Whats the use of Tkinter if the docs are in TCL. 

The www.tkdocs.com site is 'language neutral' - currently the tutorial 
covers Tcl, Perl, Ruby and yes Python, and allows you to switch between 
any of those languages (or show all of them).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An assessment of Tkinter and IDLE

[Mark Roseman]

With regard to Tkinter documentation, and in particular the newer, more 
modern aspects thereof (e.g. ttk, styles, etc.) please have a look at 
the tutorial at http://www.tkdocs.com

Would it be useful to link to this from the main Python Tkinter 
documentation?

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: need help using Tkinter

[Mark Roseman]

 MRAB  wrote:
> Manzur Ahmed wrote:
> > i wanted to ask you if one of you could help me to use Tkinter. i'm 
> > trying to just create a simple GUI for which I have provided the code 
> > for below.
> There are some differences between Python 3.x and Python 2.x. In Python
> 3.1 the module is called "tkinter", not "Tkinter" (names are
> case-sensitive).


Further to the above, you can find my Tkinter tutorial (which uses 
Python 3.x) at http://www.tkdocs.com -- I hope this will provide some 
help in getting up to speed.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UI toolkits for Python

[Mark Roseman]

> You elided the paragraph where I pointed out the third alternative:
> provide a better experience for the 95%, and an ok experience for the
> 5%. WWW technologies are designed to degrade gracefully - it's easy to
> take advantage of that.

What I'm suggesting is taking the effort you'd put to the 5%, and 
applying that effort instead to making the 95% even better.  If that 
extra effort would affect conversion rates, it's a justifiable option.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UI toolkits for Python

[Mark Roseman]

Mike Meyer <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Alex Martelli) writes:
> > Maybe that's the key difference between the mindset of a
> > mathematician and that of an engineer -- I consider reaching over
> > 95% of visitors to be _quite good indeed_,
>> What surprises me is that marketing types will accept turning away -
> what's the current internet user base? 200 million? - 10 million
> potential customers without a complaint. Or maybe they just don't get
> told that that's what's going on.

Obviously we all agree the effort to support both is significant.  The 
question is not so much "do we turn away 5%" as "do we use the effort we 
do have to provide a better experience for the 95%, or to provide a 
slightly worse experience for the 95%, and an ok experience for the 5%".

If you're a business, the question then becomes, does the incrementally 
better experience produce a higher conversion rate (i.e. more sales), in 
which case it may well be a better investment to focus there and ignore 
the 5%.  It's but one perspective, but depending on your goals, can be a 
reasonable choice to make.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UI toolkits for Python

[Mark Roseman]

 Paul Rubin  wrote:
> However, Tkinter not most people's favorite, because the widgets look
> crude, they don't resemble the native widgets of any popular platform,
> and the widget set is somewhat limited.


People should probably be more aware of work that has been going on with 
Tk recently (after a fairly long hiatus) in terms of greatly improving 
its appearance, adding theming, and more.  It's worth checking out, and 
of course, if there's a way to help get some of these changes into 
Tkinter, the Tk folks would I'm sure be helpful. 

Here's a portion of a note that Jeff Hobbs posted to the Ruby group 
recently, on a similar topic:


> From: Jeff Hobbs <[EMAIL PROTECTED]>
> Subject: Re: The definitive GUI for Ruby
> Date: Wed, 05 Oct 2005 11:02:46 -0700
> Newsgroups: comp.lang.ruby
> Message-ID: <[EMAIL PROTECTED]>
>
> Eustaquio Rangel de Oliveira J wrote:
> > Tk is still too ugly for make programmers that are
> > migrating. :-)
>
> Tk is only ugly if that's the way you like it.  You have a
> full set of themed widgets available now that give you
> native look and feel, with all the same dynamic control and
> general ease of use that Tk has always provided.  All this
> on Aqua, Win32 and X11 (even Windows/CE).  Some screenshots
> of Tk apps that try not to be ugly:
>
> The Perl Dev Kit and Tcl Dev Kit UIs:
> http://aspn.activestate.com/ASPN/docs/PDK/6.0/PerlApp_gui.html#perlapp_gui_configuring_perlapp_build_parameters
> http://aspn.activestate.com/ASPN/docs/Tcl_Dev_Kit/3.2/TclVFSE.html
>
> Tk on Win/CE (I know that the Perl/Tcl::Tk use this too):
> http://wiki.tcl.tk/8442
>
> Coccinella:
> http://hem.fyristorg.com/matben/
> http://hem.fyristorg.com/matben/examples/index.html
>
> An installer builder:
> http://installbase.sourceforge.net/screenshots.shtml
>
> An example of improving a Tk app by "going native":
> http://wiki.tcl.tk/14522
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wheel-reinvention with Python

[Mark Roseman]

 Paul Rubin  wrote:
> Cliff Wells <[EMAIL PROTECTED]> writes:
> > Still, that leaves Linux and Mac out in the cold.  But I'll admit you
> > met my challenge.  Most likely you can actually do most of the things
> > with Tk you can with Wx, it's simply a matter of how much effort is
> > going to be (for instance, it's certainly quite possible to embed Gecko
> > in Tk, but I for one am not likely to be up to the task).
> 
> I actually misunderstood your question about embedding a browser and
> thought for a while about what it would take to write or port a
> serious browser to use tkinter as its graphics layer.  The resulting
> picture wasn't pretty.  I wonder whether it's feasible in wxpython.


I'll point out that this has been done (in fact, many times).  For 
example:
  http://tkhtml.hwaci.com

(Integrating Gecko in has also been done, as a side note).

I'll highlight a meta-point regarding this thread: there's a lot of 
stuff in Tk that is available but not built into the standard library, 
nor necessarily well documented or even easy to find.  While this is a 
sad state of affairs, and to my mind no excuse (even though this is a 
common situation with open source software), it emphasizes that a 
cursory look does not tell the whole story.  

While I certainly don't begrudge anyone their choice of tools, it's no 
surprise that someone who's become more familiar with wxPython would 
have an unduly low opinion of Tk.  They've obviously spent more time 
overcoming the warts in wxPython, and wouldn't have spent comparable 
effort learning what it would take to overcome the warts in Tk - it just 
looks hopelessly flawed in comparison.  

Switch "wxPython" and "Tk" around in the above argument and I think the 
statements equally hold of course.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wheel-reinvention with Python

[Mark Roseman]

> How can I embed a browser in Tk (I mean a real browser, like Mozilla,
> Safari, or even Exploder)?  At all?  On any platform?  This has always
> been the tradeoff for Tk.  

Try this as one example:
  http://wiki.tcl.tk/4094

> Tk is great for learning, easy to write small, basic interfaces, less
> great for deploying real world apps with sophisticated interfaces.  I've
> often felt that Tk was the VB of GUI toolkits: terrific for knocking out
> simple stuff, but starts to bite you in the *** when you try to do the
> hard stuff.  wxPython is the opposite: it has a steeper learning curve,
> but once you know it, you can do amazing things.  For me, the long term
> benefits are far more important to me than how low the startup costs
> are.

I'd respectfully disagree (having done large, real-world Tk apps).  
You're right that Tk has a slow learning curve, which makes it easy to 
knock out simple interfaces really quickly - and generally ones that are 
not too impressive looking.  You can do more sophisticated ones, and 
ones that blend properly into the platforms you're working on - however, 
the amount of effort and learning curve increase substantially.  This is 
because you end up needing to do a lot more fiddling, looking at or 
using any of a large number of add-on packages, etc.).

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wheel-reinvention with Python

[Mark Roseman]

 Ed Leafe <[EMAIL PROTECTED]> wrote:
> On Sunday 31 July 2005 12:03, Paul Rubin wrote:
>> > How on earth did you decide that, since tkinter actually runs out of
> > the box when you install Python on most platforms, and wxPython doesn't?
> 
>  Because Tkinter looked like crap on OS X. Sorry, but it's hard to sell an 
> application that looks bad. Our target for the framework is to build 
> cross-platform apps that look native on each platform. Tkinter didn't measure 
> up in that regard.

FWIW, some people may find this page interesting, which gives you an 
idea what "standard" Tk looks like on OS X, and then with adopting the 
"tile" extension to Tk and a few other tweaks, which is on its way to 
becoming a standard part of Tk:
  http://wiki.tcl.tk/14522

There's other info and various screenshots at:
  http://tktable.sourceforge.net/tile/index.html

I think the message is, Tk has been moving forward in a coherent and 
focused way (finally) in terms of look and feel, which will certainly be 
of great benefit to Tkinter.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list