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-requ...@python.org> wrote: > > > ---------- Forwarded message ---------- > From: Kevin Walzer <k...@codebykevin.com> > To: python-list@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> > >
-- http://mail.python.org/mailman/listinfo/python-list