GUIs - A Modest Proposal
in [Python]
|
From: Gregory Ewing on 10 Jun 2010 04:28 Brian Blais wrote: > In this whole discussion, I haven't seen anyone mention wax (http:// > zephyrfalcon.org/labs/wax_primer.html) Just had a quick look at that. In the third example code box: def Body(self): ^^^^ self.textbox = TextBox(self, multiline=1, wrap=0) self.AddComponent(self.textbox) ^^^^^^^^^^^^ Here's something unpythonic already: a couple of non-pep-8-compliant method names. And a bit further down: self.textbox.SetFont(FIXED_FONT) ^^^^^^^ Using a setter method instead of a property. So while it's quite likely better than raw wxPython, it fails the pythonicity test for me. -- Greg
From: Gregory Ewing on 10 Jun 2010 04:52 Martin v. Loewis wrote: > or PyGui would need to be implemented in terms of ctypes (which then > would prevent its inclusion, because there is a policy that ctypes must > not be used in the standard library). Is there? I wasn't aware of that. What's the reason? If it's because ctypes doesn't work on all platforms, then I don't think that applies in this case, because the only platform where it would be needed is Windows, where ctypes does work. > I think that the separation of pywin32 into modules is > somewhat arbitrary Pywin32 does seem to have grown rather haphazardly. Some functionality is wrapped in two different ways in different modules, for no apparently good reason, and some other things are wrapped incompletely or not at all. A well thought out replacement suitable for stdlib inclusion wouldn't go amiss. -- Greg
From: python on 10 Jun 2010 10:06 Brian, > Since many seem to be married to a particular GUI framework, I was just suggesting that a thin wrapper around the framework might be fruitful, The guys on the Dabo project have created such a wrapper. www.dabodev.org. Malcolm
From: rantingrick on 10 Jun 2010 12:06 On Jun 10, 3:28 am, Gregory Ewing <greg.ew...(a)canterbury.ac.nz> wrote: > Brian Blais wrote: > > In this whole discussion, I haven't seen anyone mention wax (http:// > > zephyrfalcon.org/labs/wax_primer.html) > > Just had a quick look at that. In the third example code box: > > def Body(self): > ^^^^ > self.textbox = TextBox(self, multiline=1, wrap=0) > self.AddComponent(self.textbox) > ^^^^^^^^^^^^ > > Here's something unpythonic already: a couple of non-pep-8-compliant > method names. > > And a bit further down: > > self.textbox.SetFont(FIXED_FONT) > ^^^^^^^ > > Using a setter method instead of a property. > > So while it's quite likely better than raw wxPython, it fails the > pythonicity test for me. > > -- > Greg Yes, i'll agree the syntax it not what we would want for Python. Although it could be re-written in a Pythonic fashion but then again scaling to the real Wx library would not be as "clean". However wax does have one very likable quality -- it "is" a small part of a well established GUI and very large library. But again, not what any of "us" would consider to be Pythonic "enough".
From: rantingrick on 10 Jun 2010 12:34
On Jun 10, 3:52 am, Gregory Ewing <greg.ew...(a)canterbury.ac.nz> wrote: > Pywin32 does seem to have grown rather haphazardly. Some > functionality is wrapped in two different ways in different > modules, for no apparently good reason, and some other > things are wrapped incompletely or not at all. A well > thought out replacement suitable for stdlib inclusion > wouldn't go amiss. You summed up in a most elegant way what i was unable to do earlier. But i want to add more... I think PyWin32, like Tkinter, was another gift we have failed to maintain on our end. The great Mark Hammond brought us the much need functionality of PyWin32 and even today it has not be seized upon and made better by the Python community? Do we expect Mark to just keep maintaining and supporting what REALLY should be a stdlib module forever? Like it not (And i'm talking directly to all the Unix hackers here!) Win32 is here to stay! You should have realized that years ago! And likewise, like it or not, GUI is here to stay. You should have also realized that years ago (although we may be supporting web interfaces soon...same thing really). If you wish to hide your head in the sand and ignore these facts hoping that the "old days" of command line and no windows platform will return, well thats not going to happen. The rest of us are going to move forward and hope that eventually you will see the light and tag along. Tkinter and TclTk are dead! I use Tkinter and i can happily say that. And the ONLY reason i even use Tkinter is the fact that it's there in the stdlib! Remove the module and i will move on to something better. Tkinter is legacy software built on legacy software. It was the best choice way back when Guido forged the path. But now Tkinter has fallen into obscurity. Sure it's useful, i use it all the time. But it's too large, too slow, and just too damn ugly to be part of "our" Python stdlib. Embedded interpretor, YUCK! If people want to use Tkinter they can download it as a 3rd party module, no harm done! But Tkinter is harming Python by disgracing Python's stdlib and slowing Python down. PyGUI is still the front runner and has my vote until someone can show me a better option. I think if PyGUI where around circa 1995 Guido would have pounced on it like a hungry tiger on a wildebeest. Ask yourself what a Python GUI should look like, and what it should feel like. Then go and use PyGUI. The choice will be obvious. |