Future standard GUI library
Not sure if this is the right place to talk about this. Even less sure if I can move this discussion to tkinter list, so here I am... 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 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 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: "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." 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. Anyways, this is just some concerns that I hope someone may give his/her opinions about. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
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, wrote: > > > -- Forwarded message -- > From: Kevin Walzer > 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. >
How to make a tkinter GUI work on top of a CUI program?
I know how to make a GUI program work on top of a console program like
"ls", which exits immediately.
But some console programs have their own shell or ncurse-like CUI, such as
cscope.
So I figured that I need to first subprocess.popen a bidirectional pipe and
send command through stdin and get results from stdout and stderr.
But in such a case I found that communicate('cmd') will freeze.
Am I in the right direction?
Here is my code, in which the application connects to cscope through pipe,
the GUI has only one button that tries to invoke a cscope search command
and get the result, the Enter key is represented as \n in the stdin
argument of communicate():
import sys, os, os.path, subprocess, shlex
if sys.version_info.major < 3:
import Tkinter as Tk
else:
import tkinter as Tk
class MyGUI(object):
'''
Frontend of the main command-line module.
'''
def __init__(self):
self.subProc = None
self.root = Tk.Tk()
self.frame = Tk.Frame(self.root)
self.btn = Tk.Button(self.frame, text='My Command')
self.btn.pack()
self.btn.bind('', self.OnClickBtn)
def MainLoop(self):
os.chdir('path/to/myfolder')
cmd = shlex.split('/usr/local/bin/cscope -d')
self.subProc = subprocess.Popen(cmd, shell=False, stdout=subprocess.PIPE,
stderr=subprocess.PIPE, bufsize=0)
self.root.mainloop()
def OnClickBtn(self, event):
print('OnClickBtn')
(stdOut, stdErr) = self.subProc.communicate('symbolName\n')
print(stdOut)
if __name__ == '__main__':
gui = MyGUI()
gui.MainLoop()
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to make a tkinter GUI work on top of a CUI program?
Thank you so much Jerry.
I should have read though the man page more carefully.
The available online cscope tutorials never mentioned the line-oriented
mode.
On Sat, Jan 4, 2014 at 1:35 AM, Jerry Hill wrote:
> On Fri, Jan 3, 2014 at 9:44 PM, Beinan Li wrote:
> > But some console programs have their own shell or ncurse-like CUI, such
> as
> > cscope.
> > So I figured that I need to first subprocess.popen a bidirectional pipe
> and
> > send command through stdin and get results from stdout and stderr.
> >
> > But in such a case I found that communicate('cmd') will freeze.
>
> Right. communicate() waits for the subprocess to end, and the
> subprocess is still waiting for you to do something. Instead, you'll
> need to read() and write() to the subprocess' stdin and stdout
> attributes, probably something like this (untested):
>
> def OnClickBtn(self, event):
> print('OnClickBtn')
> self.subProc.stdin.write('symbolName\n')
> print(self.subProc.stdout.read())
>
> It looks like cscope has both a screen-oriented mode and a line-based
> mode. When you're working with a subprocess like this, you're going
> to want to be in the line-based mode, so you'll probably want to add
> -l or -L to your command line.
>
> --
> Jerry
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to make a tkinter GUI work on top of a CUI program?
... and thanks to Chris too.
Now I got the better idea how the subprocess module works.
On Sat, Jan 4, 2014 at 11:29 AM, Beinan Li wrote:
> Thank you so much Jerry.
> I should have read though the man page more carefully.
> The available online cscope tutorials never mentioned the line-oriented
> mode.
>
>
>
> On Sat, Jan 4, 2014 at 1:35 AM, Jerry Hill wrote:
>
>> On Fri, Jan 3, 2014 at 9:44 PM, Beinan Li wrote:
>> > But some console programs have their own shell or ncurse-like CUI, such
>> as
>> > cscope.
>> > So I figured that I need to first subprocess.popen a bidirectional pipe
>> and
>> > send command through stdin and get results from stdout and stderr.
>> >
>> > But in such a case I found that communicate('cmd') will freeze.
>>
>> Right. communicate() waits for the subprocess to end, and the
>> subprocess is still waiting for you to do something. Instead, you'll
>> need to read() and write() to the subprocess' stdin and stdout
>> attributes, probably something like this (untested):
>>
>> def OnClickBtn(self, event):
>> print('OnClickBtn')
>> self.subProc.stdin.write('symbolName\n')
>> print(self.subProc.stdout.read())
>>
>> It looks like cscope has both a screen-oriented mode and a line-based
>> mode. When you're working with a subprocess like this, you're going
>> to want to be in the line-based mode, so you'll probably want to add
>> -l or -L to your command line.
>>
>> --
>> Jerry
>>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
