Future standard GUI library

[Beinan Li]

Thanks for the clarification, Kevin.
It's nice to have a tk dev standing out :-)
This more or less convinced me about the trend.

I also agree that it would be probably a simpler and more maintainable way
to write my own tk(inter) code than using any existing 3rd-party designers.


Beinan

On Sat, May 18, 2013 at 1:40 PM, <python-list-request at python.org> wrote:

>
>
> ---------- Forwarded message ----------
> From: Kevin Walzer <kw at codebykevin.com>
> To: python-list at python.org
> Cc:
> Date: Sat, 18 May 2013 11:32:04 -0400
> Subject: Re: Future standard GUI library
> Hello,
>
> On 5/18/13 10:03 AM, Beinan Li wrote:
>
>  I know this may sound a silly question because no one can see the
>> future. But ...
>> Do you think tkinter is going to be the standard python built-in gui
>> solution as long as python exists?
>>
>
> I don't see any significant clamoring among the Python core developers to
> make a change.
>
>
>> I couldn't help but wonder if wx or PySide receives better py2 and py3
>> support, or anything else that prevent
>> them from getting into the standard python distributions, whether or not
>> this scene could start to shift ...
>>
>
> I am not going to engage in the old UI toolkit flame ware; I will limit
> myself to factual observations and a few opinions about Tkinter without
> placing it against other toolkits.
>
> Python has the PEP process for suggesting changes to the core language and
> libraries. Changing the default UI toolkit would require someone to submit
> a proposal, get it approved, provide the implementation, and commit to
> maintaining the implementation over the long term. You propose it, you own
> it.
>
> Thus far no one has done this. I would think the only person who would be
> in a position to propose wxPython would be Robin Dunn since he is the
> primary copyright holder, and to my knowledge he has never done so. As for
> Pyside, it was not part of the transition of Qt from Nokia to Digia, and so
> it appears to be orphaned. PyQt might be an alternative, but I don't think
> Phil Thompson would ever submit it, as it would likely affect his
> livelihood.
>
> Given these facts, it's safe to say that Tkinter will remain the default
> GUI toolkit in the stdlib for some years to come.
>
>
>> I believe this "which one of tkinter, wx, qt, is the best gui toolkit
>> for python" flame war has been going on
>> for ages. I love the fact that python ships a built-in gui solution
>> which makes shipping a pure-python desktop
>> application a viable choice. But tkinter does not appear to be the most
>> time-saving way to write a gui app.
>> The layout designer support, for one, is next to zero. I tried many
>> 3rd-party designers
>> and loved PAGE (http://page.sourceforge.net) for a few minutes, then
>> came the author's comment:
>>
>
> PAGE strikes me as an odd choice for a Python developer to develop a Tk
> UI. It's a descendent of the old Visual Tcl tool, and is run from Tcl and
> not Python. VTcl was always famous for producing a huge pot of spaghetti UI
> code that couldn't be easily modified outside the tool. I have also tried
> many Tk UI tools including VTcl, SpecTcl, and the orphaned tool from
> ActiveState, and have concluded that writing my own code is both simpler
> and faster. As always, your mileage may vary.
>
>
>> "For release 4.0, I spent about two months working with the “Theme” part
>> of Ttk and have had only partial success. I now believe that the “Theme”
>> part of Ttk is really a very poor piece of software at all levels -
>> concept, implementation, and especially documentation. My guess is if it
>> had been well documented it would have been recognized by even the
>> author as junk. I find it hard to believe that the people who control
>> Tcl/Tk allowed it in the code base. I continue to support ttk because of
>> the paned window, notebook and treeview widgets."
>>
>
> The implementation of the ttk widgets is quite complex--that, in turn,
> makes their documentation complex, and the complexity is a drawback. It's
> hard to customize the ttk themes, especially compared to customizing
> standard Tk widgets. I'm one of the core Tk developers, and I don't fully
> understand the themed widgets' internals or how to customize them. But it's
> not fair to say that they are "junk." The author of PAGE may think so, but
> many would disagree. I think the widgets work quite well, especially if
> used in their default mode. It's difficult to overstate the improvement in
> the look and feel of my Tk apps on the Mac when I switched to using the
> themed widgets.
>
>
>> And ttk seems to be a major attraction that keeps people coming back to
>> tk for the looks. This worries me very much
>> about whether I should start a gui app using python. Because if ttk is
>> not a "mature" technology, I'd avoid premature adoption.
>> If ttk is out of the question, tkinter will be too. I'd then be forced
>> to use a 3rd-party solution like wx or qt, which I really don't want to
>> see.
>>
>
> ttk is a mature technology. The initial specification, code, and docs were
> developed by Joe English nearly a decade ago (see
> http://tktable.sourceforge.**net/tile/tile-tcl2004.pdf<http://tktable.sourceforge.net/tile/tile-tcl2004.pdf>),
> and they had been accepted into Tcl/Tk's core in version 8.5 (released in
> 2007). The earliest work on integrating these widgets into Python began in
> 2008, and they were formally released in 2010.  I would say that ttk is
> mature, stable, and unlikely to undergo radical change in the future.
>
> Guilherme Polo has done superb work in integrating the themed widgets into
> Python--it's the most significant UI advance in Python's stdlib in years.
> You are quite safe in developing against this API, unless your taste simply
> does not run to using the ttk widgets.
>
> Hope this helps,
> Kevin
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.**com <http://www.wtmobilesoftware.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130518/1e098d72/attachment.html>