Re: I am fed up with Python GUI toolkits...
On 7/19/2011 7:34 PM, Andrew Berg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 There's PyGUI, which, at a glance, fits whit what you want. Looks like it uses OpenGL and native GUI facilities. http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ It has quite a few external dependencies, though (different dependencies for each platform, so it requires a lot to be cross-platform). It still uses Tcl/Tk stuff, which is un-Pythonic. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 20, 3:34 am, Terry Reedy tjre...@udel.edu wrote: On 7/19/2011 10:12 PM, sturlamolden wrote: What is wrong with them: 1. Designed for other languages, particularly C++, tcl and Java. 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. 4. They might look bad (Tkinter, Swing with Jython). 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) Greg Ewing's pygui project is still going and releasing new versions. How I would prefer the GUI library to be, if based on native widgets: 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable. 5. No particular GUI thread synchronization is needed -- Python has a GIL. 6. Expose the event loop to Python. 7. Preferably BSD-style license, not even LGPL. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. I think you described pygui. Is it worth the hassle to start a new GUI toolkit project? Ask Greg what you might help with. Or should modern deskop apps be written with something completely different, such as HTML5? An interesting question. I think thepyjamasproject is aimed in this direction, weeelll... we kinda want to keep as many platforms supported as possible, so that includes IE6 canvas (VML) which surprisingly works pretty damn good, the only thing missing is being able to add text to VML canvas: everything else (including colour gradients) shockingly actually works. it's slow, but what do you expect out of IE6, duh. but yes we're finding that an increasing number of people are saying i wrote a pyajamas app, it used direct HTML5, sod the browsers that don't properly support HTML5 and i think that's a good thing. but the author says he will never port to Py3. (He explained his reasons on this list when I suggested that.) :) it's not quiiite a matter of never - it's conditional. the conditions on which i, personally and extremely grudgingly, will get involved in a py3 port of pyjamas are when it becomes hellishly difficult for myself, personally, to maintain all of the components of pyjamas *including* the desktop ports (w32 MSHTML, gnu pythonwebkit project, xulrunner N.N) which people tend to forget exist for python 2.N. the reason for that are a) personally i don't like py3 (because it didn't include backwards-compatibility for python 2) b) the pyjs translator is self-contained, and has at absolutely no time any need for any links at runtime to in fact any python *at all* (because the pyjs version runs on a javascript engine *not* a python engine). there's no never in there - it's just that i'll keep reviewing the situation, and i anticipate / predict that it will begin to become difficult to compile python2 applications (such as python-comtypes) at some point in approx ooo... 5 to 7 years. maybe not - it's hard to say. anyway - if however someone else wants to collaborate and/or fund a py3 port of pyjamas, knock yourself out: just bear in mind that it's an estimated 18 man-month project. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Tim Roberts wrote: I don't think your glibness is justified. There is a legitimate appeal to this notion. The fact is that MANY APIs can be completely and adequately described by HTML. My brain raises a TypeError on that statement. According to my understanding of the world, describing APIs is not something that HTML does. (Or did you mean GUI rather than API?) Yes, you are correct. Brain fart on my part. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
John Nagle wrote: There's PyGUI, which, at a glance, fits whit what you want. Looks like it uses OpenGL and native GUI facilities. http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ It still uses Tcl/Tk stuff, which is un-Pythonic. You must be thinking of something else. My PyGUI has nothing to do with Tcl/Tk at all. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 07/20/2011 07:17 PM, rantingrick wrote: Please everyone, do not change the subject of someone's thread because it's considered rude. Thank you. Too funny. Says who? Changing the subject line to reflect the direction this part of the thread (a branch if you will) is going is definitely appropriate. At least according to etiquette rules that go back for some time (likely before you were around--you're pretty young no?) Besides forking is a time-honored open source tradition. What about the etiquette of staying on topic? The only person who is OFFICIALLY allowed to change the subject matter of a thread is the OP. Sure some folks might make an off topic post here and there however i find it bombastically rude when folks just change a topic of thread they do not own. Oh really. I guess since you are one of the leaders I guess it must be so. Too funny. Fortunately not all of us are using the crippled one-dimensional Gmail conversation way of reading threads on e-mails. So as long as the topic is appropriately changed, we can deal with branches that twist and turn. My e-mail reader threads them all quite nicely. Now replying to an existing thread to start an entirely new, unrelated thread is definitely rude. How would you like it if i came to your house and wrote my name on your refrigerator door, or used your toilet without asking, or slept in your bed? I would not do that because i have manners. Feel free to make yourself comfortable but don't put you feet on the coffee table. Did you study logical fallacies in English classes at uni? (If she weighs the same as a duck then she's made of wood, and therefore she's a witch). And as for manners go, I'm glad to see you've improved so much in the last year. Who knows you might just be removed from kill files yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 2011-07-24, John Nagle na...@animats.com wrote: On 7/19/2011 7:34 PM, Andrew Berg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 There's PyGUI, which, at a glance, fits whit what you want. Looks like it uses OpenGL and native GUI facilities. http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ It has quite a few external dependencies, though (different dependencies for each platform, so it requires a lot to be cross-platform). It still uses Tcl/Tk stuff, which is un-Pythonic. Like Tkinter does? I thought PyGUI it was based on GTk? That's what the web page seems to indicate. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 7/24/2011 8:51 PM, Michael Torrie wrote: Now replying to an existing thread to start an entirely new, unrelated thread is definitely rude. Rude or not, it tends to be unproductive. If someone posted Help with threading internals here, it could well not be seen by the appropriate people, especially if they have threads collapsed. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Gregory Ewing greg.ew...@canterbury.ac.nz wrote: sturlamolden wrote: Or should modern deskop apps be written with something completely different, such as HTML5? I hope not! HTML is great for web pages, but not everything should be a web page. I don't think your glibness is justified. There is a legitimate appeal to this notion. The fact is that MANY APIs can be completely and adequately described by HTML. It provides a very natural separation of presentation and behavior. Without style sheets, you can describe simple APIs very compactly and let the renderer do positioning. With style sheets, you can get very complete control over the look and feel. This is very similar to what Microsoft has done with Windows Presentation Foundation, except that they are using a more sophisticated XML DTD. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Tim Roberts wrote: Gregory Ewing greg.ew...@canterbury.ac.nz wrote: sturlamolden wrote: Or should modern deskop apps be written with something completely different, such as HTML5? I hope not! HTML is great for web pages, but not everything should be a web page. I don't think your glibness is justified. There is a legitimate appeal to this notion. The fact is that MANY APIs can be completely and adequately described by HTML. My brain raises a TypeError on that statement. According to my understanding of the world, describing APIs is not something that HTML does. (Or did you mean GUI rather than API?) There might be some sense in using something HTML-like to describe the layout of widgets in a GUI. But laying out widgets is only a tiny part of what's involved in creating an application with a GUI. You still need a GUI toolkit to provide the widgets being laid out, and application code behind that to provide the desired functionality. With style sheets, you can get very complete control over the look and feel. CSS is designed for graphic artists who want complete control over every aspect of appearance. Again, this is (arguably) okay for web pages, but I don't think it applies to GUI applications. You *don't* want every application looking completely different from every other on the whim of the author -- quite the opposite. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 23Jul2011 22:21, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: | Tim Roberts wrote: | Gregory Ewing greg.ew...@canterbury.ac.nz wrote: | sturlamolden wrote: | Or should modern deskop apps be written with something completely | different, such as HTML5? | | I hope not! HTML is great for web pages, but not | everything should be a web page. | | I don't think your glibness is justified. There is a legitimate appeal to | this notion. The fact is that MANY APIs can be completely and adequately | described by HTML. [...] | There might be some sense in using something HTML-like to | describe the layout of widgets in a GUI. But laying out | widgets is only a tiny part of what's involved in creating | an application with a GUI. You still need a GUI toolkit to | provide the widgets being laid out, and application code | behind that to provide the desired functionality. Sure, but if a suitable API is presented for javascript to hook into over HTTP an HTML widget kit isn't an unreasonable thing to build. And then you have the cross platform nirvana. Except for the browsers' various differences and bugs etc etc... | With style sheets, you can | get very complete control over the look and feel. | | CSS is designed for graphic artists who want complete | control over every aspect of appearance. Again, this is | (arguably) okay for web pages, but I don't think it | applies to GUI applications. You *don't* want every | application looking completely different from every other | on the whim of the author -- quite the opposite. You can override site specific CSS in the firefox browser, possibly others. There are extensions to make it easier rather than mega-awkward and undocumented. It is still a bit of a dobge, in not small part because CSS lacks a not - you can't say style everything except blah, which means you have to enumerate a bazillion combinations and you're still playing guessing games. So, yes, the every author's look'n'feel is gratuitously different chaos still applies :-( Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ But what ... is it good for? --Engineer at the Advanced Computing Systems Division of IBM, 1968, commenting on the microchip. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Sun, Jul 24, 2011 at 1:56 PM, Cameron Simpson c...@zip.com.au wrote: And then you have the cross platform nirvana. Except for the browsers' various differences and bugs etc etc... The platform ceases to be Windows/Linux/Mac, ceases to be Qt/GTK/Tk, and instead becomes Webkit/Gecko/Trident. It's still not perfectly cross-platform. (Although the recent ones are tending to comply with the standards better than during the old IE vs Netscape browser wars.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Wed, Jul 20, 2011 at 12:20 AM, Stefan Behnel stefan...@behnel.de wrote: Steven D'Aprano, 20.07.2011 06:28: Python has a GIL. Except for Jython, IronPython and PyPy. PyPy has a GIL, too. There's been talk of removing PyPy's GIL using transactional memory though. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 22 Jul, 02:34, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: I think that's a bit of an exaggeration -- there's only one major dependency on each platform, and it's a very widely used one (currently PyObjC/PyGTK/PyWin32). And I'm thinking about ways to reduce the dependencies further, Pyrex or Cython? -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 21 Jul, 16:52, Kevin Walzer k...@codebykevin.com wrote: I bet that other scripting languages would piggyback on top of it (Lua or Ruby bindings for Python's GUI toolkit, anyone?) because doing that is less work than writing your own toolkit from scratch. No doubt about that. Lua has a nice GUI toolkit by the way, which also has a C API. Currently it works on GTK+, Motif and Window. The C API is very small, only about 100 functions. So it makes a good candidate for a new Cython-based toolkit, even without piggybacking on Lua. http://www.tecgraf.puc-rio.br/iup/ -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 7/20/11 9:05 AM, rantingrick wrote: On Jul 19, 9:44 pm, Kevin Walzerk...@codebykevin.com wrote: 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit specifically designed for scripting languages. Tk is SPECIFICALLY designed for TCL. Tkinter works ONLY by embedding a TCL interpreter. You statements are misleading. Of course I know this--I'm one of the core Tcl/Tk developers on my platform. :-) My statement was actually based on Mark Lutz's characterization in Programming Python, when he defends Tk's inclusion in the stdlib (and his own book's extensive focus on it) by observing that the toolkit was specifically designed for use with scripting languages--Tcl at the start, but also Python, Perl, Ruby...he seemed to want to downplay Tk's Tcl-ish roots, as if he were embarassed by them. I guess it's a Tcl-ish subject. 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. Again, so? Again, this isn't applicable to Tk. He did not even mention Tk in that block, do you have a TK persecution complex? No, but it's an advantage that Tk has over the other ones, and an argument that reinventing the wheel is unncessary. 4. They might look bad (Tkinter, Swing with Jython). Then again, they might not. A lot depends on the skill of the developer. I write highly polished commercial apps with Tk GUI's. I'm sick of developers blaming their ugly apps on the toolkit rather than their own lack of design training and/or skills. This is true. Lots of people lack the skill to create professional quality GUI applications however lots of GUI devs lack the skill to create clean and intuitive API's also. Tkinter/TclTk and WxPython \WxWidgets has lots of warts in this respect. I think what constitutes a clean API is partly a matter of taste. 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) That's right. People issue a clarion call for a new GUI toolkit, then discover that even a so-called ugly, limited, minimalist toolkit like Tk has twenty years of development behind it. And people think they can duplicate this effort in a few months by starting a flame war on comp.lang.python? Just because someone wants to entertain ideas for a new GUI does mean they are starting flame wars. I would say out all the responses so far YOURS is the most emotional. *shrug* Maybe it is. I prefaced this by saying, OK, I'll bite, which suggests that perhaps I shouldn't, because complaints and hand-wringing are really a waste of time. In the future, I think my response (if I make one at all) will more likely be something like this: An interesting idea. Please post back when you have a source code repo, build instructions so we can play with your code, a mailing list, and a license that is suitable for both open-source and proprietary development. The most substantial effort at developing a new GUI API for Python did just this--PySide (alternative bindings to Qt). No hand-wringing, no flame wars, just an announcement of the project, an invitation to contribute, and so on. Whether you think it's a misguided project or an attempt to reinvent the wheel is beside the point--it's a substantial project, with both leadership and a growing community that support ongoing development and rapid maturation. In my own experience, this is the only way to move things forward or bring about any useful change--roll up my sleeves and do it myself. I've done this a bit with Tkinter (maintaining bindings/wrappers to a popular Tk widget, tablelist), but I've done this extensively with Tk itself on the Mac. I complained on mailing lists for years that Tk didn't do this or that on the Mac, and these complaints fell on deaf ears; finally, I decided to dive into the deep end, learn the low-level API's to do what I wanted, and bingo! Suddenly Tk did what I wanted. That's the essence of open-source development--scratching your own itch. Sometimes you get lucky and a large corporate entity has an itch to scratch, and this can bring large-scale projects with large-scale benefits. I believe Nokia is funding PySide. While Tk's port to the Mac's Cocoa API was done by a single developer, the project was funded by Apple. Creating a new GUI toolkit may require this scale of effort and investment. But even without it, if a developer can get something started and make enough progress to be of interest to others, then a larger community may move the project forward. Code trumps everything. 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. Presenting...Tk.
Re: I am fed up with Python GUI toolkits...
sturlamolden wrote: Or should modern deskop apps be written with something completely different, such as HTML5? I hope not! HTML is great for web pages, but not everything should be a web page. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Andrew Berg wrote: It has quite a few external dependencies, though (different dependencies for each platform, so it requires a lot to be cross-platform). I think that's a bit of an exaggeration -- there's only one major dependency on each platform, and it's a very widely used one (currently PyObjC/PyGTK/PyWin32). And I'm thinking about ways to reduce the dependencies further, -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Tue, Jul 19, 2011 at 8:12 PM, sturlamolden sturlamol...@yahoo.no wrote: 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. Perhaps you already know this, but recent versions of wxPython allow dialogs to be used as context managers, which destroys them when the with block is exited. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Steven D'Aprano, 20.07.2011 06:28: Python has a GIL. Except for Jython, IronPython and PyPy. PyPy has a GIL, too. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Wed, 20 Jul 2011 05:20 pm Stefan Behnel wrote: Steven D'Aprano, 20.07.2011 06:28: Python has a GIL. Except for Jython, IronPython and PyPy. PyPy has a GIL, too. Isn't it optional though? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.20 02:28 AM, Steven D'Aprano wrote: Isn't it optional though? No. http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOJojrAAoJEPiOA0Bgp4/LXdgH/RJefVrvsawewQsxMex9NlMl IRS6lMjVMFgsXHh2V2F+DfQ0bZ9904dgsgyU3zHkfevI3Stctrr8qainxlmUxj3q EFTzzQLUurY+tyR1sz5y9MtxWbjvOIQrZ8VN0aj/1ks+TU7fq+2d+sa+KFgMhP+k F2TQeZhDBYhm+NE7h7MHsYhnRHtA5nWW2UByFXu/gcdrk9rB+3nqHuxj4ROh7Ots vHbS9W/BsDver0e2Z9w4TxZ5Jb9cAjdkAqcK4Tqth0WMhvnIpnRGxM8npwD/xsKs 9jVkZhdG1BSvXdRUqLYTucA0lfTqNMh1CZtWzvOQIBqH1cdqKP+S7zdOloyti5Y= =H+A1 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Wed, 20 Jul 2011 05:51 pm Andrew Berg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.20 02:28 AM, Steven D'Aprano wrote: Isn't it optional though? No. http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why Ah, my mistake, thank you. I knew PyPy had multiple garbage collectors, and confabulated that it didn't have a GIL. So, that's two GILs, two without for the Big Four. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20/07/11 04:12, sturlamolden wrote: 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. I wonder - what do you think of GTK+? I've only used Qt with C++, and I've always been highly suspicious of wx (something about the API, or the documentation… I haven't had a look at it in a long time), but I always found PyGTK quite nice. 4. They might look bad (Tkinter, Swing with Jython). Oh well. Really, while Swing and Tkinter are particularly bad as they draw their own widgets (instead of using a native toolkit), if you want your GUI to look good, you'll need to write a separate GUI for each platform that follows each platform's UI conventions. 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) Aye, existing GUI toolkits are mature. They work. They do the job. 5. No particular GUI thread synchronization is needed -- Python has a GIL. That's where you're wrong: the GIL is not a feature of Python. It is an unfortunate implementation detail of current versions of CPython. (and PyPy, apparently) 6. Expose the event loop to Python. You can tap into the Gtk/GLib event loop. Don't other toolkits allow you to write your own loop, using some kind of process_events() function to take care of the GUI? 7. Preferably BSD-style license, not even LGPL. Umm? 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. HOLD ON a second: 4. They might look bad (Tkinter, Swing with Jython). [...] , if based on native widgets: What do you propose? We know what happens when you write a fresh GUI toolkit: Swing and Tkinter show us. The only reasonable option to create a toolkit that actually looks good is to base it on the usual GUI libraries. The Eclipse SWT library does some of this for Java does some of this, though it also has flaws (e.g. manual memory management). A Python GUI toolkit could be partially based on the SWT code. Okay, I haven't used SWT yet: manual memory management? Java is GC! It is perfectly reasonable to be required to manually call some sort of destroy() method to tell the toolkit what you no longer want the user to see: firstly, you have the display a reference to your window, in a manner of speaking, by showing it. Secondly, in a GC environment like a JVM or the CLI, it could take a moment. Was that what you meant? Is it worth the hassle to start a new GUI toolkit project? No. Or should modern deskop apps be written with something completely different, such as HTML5? NO!! Don't be silly. Even using a crappy windowing toolkit is a lot simpler than doing the HTML/JavaScript/HTTP/etc dance. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Tue, 2011-07-19 at 19:12 -0700, sturlamolden wrote: What is wrong with them 1. Designed for other languages, particularly C++, tcl and Java. 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) I've no idea what this means. I happily use pygtk. As for application frameworks maybe you are referring to their having their own event-loop, etc... They don't have any choice. A UI toolkit has to have an event-loop and related pluming. Gtk builds on top of glib; which has its own event-loop etc... This makes perfect sense to me. 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. Widget registration / hierarchy != memory management. 4. They might look bad (Tkinter, Swing with Jython). Sorry, I think Gtk apps are very nice looking. 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) PyGTK just released version 3 with GObject introspection. etk.docking went beta a few months ago [a pygtk docking solution]. All seems pretty alive to me. And the developers respond to questions. How I would prefer the GUI library to be, if based on native widgets 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. Sounds like PyGtk to me. All that other stuff and you are on your own. Although I'd like to have data-model binding. 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. Unreasonable. 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. NEVER GOING TO HAPPEN. UI's don't work that way. They are inherently hierarchical. Just get over it. 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable Gtk supports multiple canvas modes. 5. No particular GUI thread synchronization is needed -- Python has a GIL. Wrong. 6. Expose the event loop to Python. It is. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. Why. Pointless. That is just re-implementation. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 07/19/2011 09:12 PM, sturlamolden wrote: How I would prefer the GUI library to be, if based on native widgets: http://xkcd.com/927/ :-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Wed, 2011-07-20 at 11:59 +0200, Thomas Jollans wrote: On 20/07/11 04:12, sturlamolden wrote: 5. No particular GUI thread synchronization is needed -- Python has a GIL. That's where you're wrong: the GIL is not a feature of Python. It is an unfortunate implementation detail of current versions of CPython. (and PyPy, apparently) And this GIL is certainly *not* a synchronization solution. Even with a GIL you can hang yourself with threads - I've verified this. :) 6. Expose the event loop to Python. You can tap into the Gtk/GLib event loop. +1 What do you propose? We know what happens when you write a fresh GUI toolkit: Swing and Tkinter show us. The only reasonable option to create a toolkit that actually looks good is to base it on the usual GUI libraries. +1 It is perfectly reasonable to be required to manually call some sort of Is it worth the hassle to start a new GUI toolkit project? No. +1, or -1, errr.. which ever one means I agree with no. Or should modern deskop apps be written with something completely different, such as HTML5 NO!! Barf. Of course, Gtk [at least experimentally] supports an HTML5 canvas. A good UI library provides a lot beyond painting-the-screen (there are events, and packing/geometry, etc...). So even if you use HTML5 you are then going to lay something on top of that [JavaScript + JQuery...]. Don't be silly. Even using a crappy windowing toolkit is a lot simpler than doing the HTML/JavaScript/HTTP/etc dance. +1 -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
sturlamolden, 20.07.2011 04:12: Or should modern deskop apps be written with something completely different, such as HTML5? Depends. For many desktop apps, this is actually quite workable, with the additional advantage of having an Internet-/Intranet-ready implementation available in case you happen to need it later on. Plus, you can take advantage of any HTML designers (as in humans) you happen to have around, whereas you are often a bit on your own when you design a GUI using a toolkit, especially when you want it to work well in a cross-platform way. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Thomas Jollans t...@jollybox.de writes: On 20/07/11 04:12, sturlamolden wrote: 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. I wonder - what do you think of GTK+? I've only used Qt with C++, and I've always been highly suspicious of wx (something about the API, or the documentation… I haven't had a look at it in a long time), but I always found PyGTK quite nice. GTK+ doesn't work well at all on Mac, so if cross-platform includes Macs, it's not a contender. To quote the gtk-osx.sourceforge.net page: Developers considering GTK+ as a cross-platform environment for new work are advised to evaluate other toolkits carefully before committing to GTK if they consider OSX an important market. From experience, GTK apps are pretty awful on OSX. -Johann -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 19, 9:12 pm, sturlamolden sturlamol...@yahoo.no wrote: What is wrong with them: 1. Designed for other languages, particularly C++, tcl and Java. This fact bugs me but no one is willing to put forth an effort to make things happen. So we are stuck with what we have now. 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Users should NEVER need to explicitly destroy a dialog. However it would (should) be easy to subclass the wxDialg and create your own logic tied to the ok and cancel buttons. See tkSimpleDialog for old inspiration or see my threads on tkSimpleDialog improved for modern inspiration. Parent-child ownership might be smart in C++, but in Python we have a garbage collector. There is nothing wrong with hierarchy. Please show examples where this relationship fails. 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) Well you've got to get some like minds together. I would be willing to participate on something more Pythonic. PyGUI looks promising. How I would prefer the GUI library to be, if based on native widgets: 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. PyGUI 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. Some heavy lifting must be done in these languages. 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. I don't see how that messes things up? 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable. Hopefully you want a canvas at least. I don't think i could get by without one. Not only is a canvas good for drawing graphics via user input but also for creating custom widgets that the GUI does not expose. 6. Expose the event loop to Python. This would be nice. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. Agreed! Wx is nice but feels too much like writing C. Is it worth the hassle to start a new GUI toolkit project? It's a huge hassle and might be much better to grow/repair some existing API's. PyGUI is one however it's very young. Tkinter could use some re-factoring however it will always be based on an embedded TCL interpreter doing magic behind the scenes. Or should modern deskop apps be written with something completely different, such as HTML5? F___ NO! That sort of thing needs many more years to mature. Currently we are in the beginning phases when everybody has their idea of what is perfect and nobody agrees on which is best. Plus you have many incompatibilities between the major browsers. People like to parrot off about how cross-platform these things are compared to GUI; and that's true only for the same version of the same browser. You just switch from OS incompatibility to browser incompatibility. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 19, 9:44 pm, Kevin Walzer k...@codebykevin.com wrote: 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit specifically designed for scripting languages. Tk is SPECIFICALLY designed for TCL. Tkinter works ONLY by embedding a TCL interpreter. You statements are misleading. 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. Again, so? Again, this isn't applicable to Tk. He did not even mention Tk in that block, do you have a TK persecution complex? 4. They might look bad (Tkinter, Swing with Jython). Then again, they might not. A lot depends on the skill of the developer. I write highly polished commercial apps with Tk GUI's. I'm sick of developers blaming their ugly apps on the toolkit rather than their own lack of design training and/or skills. This is true. Lots of people lack the skill to create professional quality GUI applications however lots of GUI devs lack the skill to create clean and intuitive API's also. Tkinter/TclTk and WxPython \WxWidgets has lots of warts in this respect. 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) That's right. People issue a clarion call for a new GUI toolkit, then discover that even a so-called ugly, limited, minimalist toolkit like Tk has twenty years of development behind it. And people think they can duplicate this effort in a few months by starting a flame war on comp.lang.python? Just because someone wants to entertain ideas for a new GUI does mean they are starting flame wars. I would say out all the responses so far YOURS is the most emotional. 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. Presenting...Tk. True Tkinter does no Database, networking, threading, etc. However i would not call an embedded TCl interpreter lean and mean. 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. And what's wrong with native (ie. compiled) code? Python is written in native code, isn't it? To extend Python in significant ways, it is often necessary to drop down into native code. I will agree with Kevin here. Hey, he's not ALWAYS wrong you know; just most of the time! ;-) 6. Expose the event loop to Python. Presenting...Tk. Tk's event binding (whist quite powerful) is also quite overwhelming in the sheer number of event sequences alone and leads to spaghetti code. See my recent thread about the subject. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. Well, that's the holy grail, but given the history of other toolkits, you'll reach a comparable level of maturity in 2031. I think it could happen much sooner if people got serious. However it won't happen tomorrow for sure. Is it worth the hassle to start a new GUI toolkit project? Not unless you want to reinvent the wheel yet again. The old reinvent the wheel argument is only valid when wheels already exists. Currently we have triangles (or maybe pentagons) but no wheels. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 11:59, Thomas Jollans t...@jollybox.de wrote: I wonder - what do you think of GTK+? PyGTK with GLADE is the easier to use, but a bit awkward looking on Windows and Mac. (Not to mention the number of dependencies that must be installed, inclusing a GTK runtime.) Really, while Swing and Tkinter are particularly bad as they draw their own widgets GTK and Qt do that as well. The Eclipse SWT library does some of this for Java does some of this, though it also has flaws (e.g. manual memory management). A Python GUI toolkit could be partially based on the SWT code. Okay, I haven't used SWT yet: manual memory management? Java is GC! So is Python, yet wxPython require manual destruction of dialogs as well. It is perfectly reasonable to be required to manually call some sort of destroy() method to tell the toolkit what you no longer want the user to see Yes, but not to avoid a memory leak. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 2011-07-20, Thomas Jollans t...@jollybox.de wrote: 5. No particular GUI thread synchronization is needed -- Python has a GIL. That's where you're wrong: the GIL is not a feature of Python. It is an unfortunate implementation detail of current versions of CPython. (and PyPy, apparently) And there are always people trying to figure out how to get rid of it. So far the cures have been worse than the disease, but that may not always be the case... -- Grant Edwards grant.b.edwardsYow! ... the HIGHWAY is at made out of LIME JELLO and gmail.commy HONDA is a barbequeued OYSTER! Yum! -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 2011-07-20, Adam Tauno Williams awill...@whitemice.org wrote: On Tue, 2011-07-19 at 19:12 -0700, sturlamolden wrote: What is wrong with them 1. Designed for other languages, particularly C++, tcl and Java. 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) I've no idea what this means. I happily use pygtk. I agree. PyGTK works great -- on platforms where GTK works great. -- Grant Edwards grant.b.edwardsYow! !! I am having fun!!! at gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
sturlamolden wrote: On 20 Jul, 11:59, Thomas Jollans t...@jollybox.de wrote: It is perfectly reasonable to be required to manually call some sort of destroy() method to tell the toolkit what you no longer want the user to see Yes, but not to avoid a memory leak. OTOH, if you intend to re-use the Dialog object, it's not a memory leak. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 11:59, Thomas Jollans t...@jollybox.de wrote: Okay, I haven't used SWT yet: manual memory management? Java is GC! It is perfectly reasonable to be required to manually call some sort of destroy() method to tell the toolkit what you no longer want the user to see: firstly, you have the display a reference to your window, in a manner of speaking, by showing it. Secondly, in a GC environment like a JVM or the CLI, it could take a moment. Was that what you meant? A .hide() method is warranted, but not a .destory() method to deallocate C resources. Python calls tp_dealloc when needed. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 16:17, Mel mwil...@the-wire.com wrote: OTOH, if you intend to re-use the Dialog object, it's not a memory leak. It cannot be reused if you don't have any references pointing to it. Sure it is nice to have dialogs that can be hidden and re-displayed, but only those that can be accessed again. tp_dealloc should free any C resources the object is holding. There is no need to save anything beyond the call to tp_dealloc. Before the call to tp_dealloc any C resources should be kept, for the reason you mentioned. That is why the parent-child method of clean-up is at odds with the Python garbage collection. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 13:04, Adam Tauno Williams awill...@whitemice.org wrote: 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. NEVER GOING TO HAPPEN. UI's don't work that way. They are inherently hierarchical. Just get over it. Swing relies on the Java GC. Tkinter also does this correct. A hierarchy is nice for event processing an layout management, but not for memory mangement. C resources should be freed by Python calling tp_dealloc, not by the parent calling a .destroy() method on it's children. Python is not C++, so we have a method to automatically reclaim C resources. I don't want a toolkit to deallocate objects while Python still holds references to them (PyQt) or require a manual call to deallocate a widget tree (wxPython). Python knows when it's time to deallocate C resources, and then makes a call to the tp_dealloc member of the type object. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 13:08, Tim Chase python.l...@tim.thechases.com wrote: http://xkcd.com/927/ :-) Indeed. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 20, 9:27 am, sturlamolden sturlamol...@yahoo.no wrote: On 20 Jul, 16:17, Mel mwil...@the-wire.com wrote: OTOH, if you intend to re-use the Dialog object, it's not a memory leak. It cannot be reused if you don't have any references pointing to it. Sure it is nice to have dialogs that can be hidden and re-displayed, but only those that can be accessed again. I find that keeping a dialog alive (and hidden) is bad practice EXCEPT in the case where a dialog will be used many, many times in an application. Since that kind of re-usage is rare destroying the dialog and freeing the graphical resources it consumes is important. However a dialog should handle it's own state. That is, and application should never have to keep up with dialog default values and re-insert then every time, NO, the dialog should do this all by itself. My solution is to create a simple container class that creates and destroys the dialog as needed (when show is called) however keeps a state of the last user inputs so the main application does not have to. class Dialog(): def __init__(self): self.state = [] # the dialog IS NOT created here! def show(self): # Create the dialog here # and load any initial values # from self.state. def cb_okbutton(self): # Process the inputs, store the # current values in self.state # and destroy. def cb_cancelbutton(self) # destroy the dialog. This is a proper design pattern for all GUI dialogs. *school-bell* -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20/07/11 15:47, sturlamolden wrote: On 20 Jul, 11:59, Thomas Jollans t...@jollybox.de wrote: I wonder - what do you think of GTK+? PyGTK with GLADE is the easier to use, but a bit awkward looking on Windows and Mac. (Not to mention the number of dependencies that must be installed, inclusing a GTK runtime.) Don't know about Mac, I was under the impression that GTK was fine on Windows these days. You can bundle GTK+ just as easily as Qt or Wx. It might, of course, be less usual. Really, while Swing and Tkinter are particularly bad as they draw their own widgets GTK and Qt do that as well. Qt uses the native libraries on Windows and OSX. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 17:21, Thomas Jollans t...@jollybox.de wrote: Don't know about Mac, I was under the impression that GTK was fine on Windows these days. GTK looks awful on Windows, requires a dozen of installers (non of which comes from a single source), is not properly stabile (nobody cares?), and does not work on 64-bit. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 06:28, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: Have you tried Tkinter version 8.0 or better, which offers a native look and feel? Python 2.7.2 |EPD 7.1-1 (64-bit)| (default, Jul 3 2011, 15:34:33) [MSC v.1500 64 bit (AMD64)] on win32 Type packages, demo or enthought for more information. import Tkinter Tkinter.TkVersion 8.5 -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 19, 11:28 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: Have you tried Tkinter version 8.0 or better, which offers a native look and feel? Steven, you have no buisness offering advice on Tkinter since you yourself have proclaimed that YOU NEVER used the module and never will. Stick to what you know please. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 20, 10:32 am, rantingrick rantingr...@gmail.com wrote: Steven, you have no buisness offering advice on Tkinter since you yourself have proclaimed that YOU NEVER used the module and never will. Stick to what you know please. Allow me. Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of- GUIs scratchy window with grooves and lines everywhere. Tkinter is awesome because you can nest anything inside anything else, and it has an elaborate extendable properties system. Oh, and you can TDD it. Unlike some more modern GUIs I could mention... -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 22:58, Phlip phlip2...@gmail.com wrote: Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of- GUIs scratchy window with grooves and lines everywhere. The widget set is limited compared to GTK or Qt, though it has the most common GUI controls, and it does not look that bad with the recent ttk styling (it actually doesn't look like Motif anymore). But it does not have a good GUI builder (that I know of). Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Excerpts from Phlip's message of Wed Jul 20 16:58:08 -0400 2011: On Jul 20, 10:32am, rantingrick rantingr...@gmail.com wrote: Steven, you have no buisness offering advice on Tkinter since you yourself have proclaimed that YOU NEVER used the module and never will. Stick to what you know please. Allow me. Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of- GUIs scratchy window with grooves and lines everywhere. Themed Tk (TTK) has come a far way. I'll leave the research for you, however, as I can not give this post the time it deserves. -- Corey Richardson Those who deny freedom to others, deserve it not for themselves -- Abraham Lincoln signature.asc Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20 Jul, 22:58, Phlip phlip2...@gmail.com wrote: Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of- GUIs scratchy window with grooves and lines everywhere. And using it with OpenGL has been impossible since Python 2.2 (or whatever). -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 20, 3:13 pm, sturlamolden sturlamol...@yahoo.no wrote: On 20 Jul, 22:58, Phlip phlip2...@gmail.com wrote: Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of- GUIs scratchy window with grooves and lines everywhere. The widget set is limited compared to GTK or Qt, though it has the most common GUI controls, and it does not look that bad with the recent ttk styling (it actually doesn't look like Motif anymore). But it does not have a good GUI builder (that I know of). Oh, and you can TDD it, too... -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 21 Jul, 00:52, Phlip phlip2...@gmail.com wrote: Oh, and you can TDD it, too... No, I can't TDD with Tkinter. All my tests fail when there is no OpenGL support (Togl is gone). For TDD to work, the tests must have a chance of passing. -- http://mail.python.org/mailman/listinfo/python-list
Tkinter in Python has native widgets (was: I am fed up with Python GUI toolkits...)
Phlip phlip2...@gmail.com writes: Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of- GUIs scratchy window with grooves and lines everywhere. Applications have been written that look like that, sure. Many of them were *written* in the 1980s and 1990s, so the wonder is not how they look but that they still work today at all. To continue supporting those old applications, written with the assumption that the widgets will look like Motif, Tk must default to looking like ugly old Motif. But it simply is not true that Tk applications *must* look like Motif, or even close. We have for a long time had the “themed Tk” extension URL:http://wiki.tcl.tk/14796 which makes themed and/or native widgets in Tk. Python's Tkinter has this at the ‘tkinter.ttk’ module URL:http://docs.python.org/py3k/library/tkinter.ttk.html, or for Python 2 at URL:http://pypi.python.org/pypi/pyttk. Oh, and you can TDD it. Unlike some more modern GUIs I could mention... Yes, the ability to test one's GUI from unit test code is a huge plus. -- \ “Everyone is entitled to their own opinions, but they are not | `\entitled to their own facts.” —US Senator Pat Moynihan | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
RE: *Ben Finney changes thread subject* Please everyone, do not change the subject of someone's thread because it's considered rude. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: changing thread topics (was: I am fed up with Python GUI toolkits...)
On 07/20/2011 08:17 PM, rantingrick wrote: RE: *Ben Finney changes thread subject* Please everyone, do not change the subject of someone's thread because it's considered rude. Thank you. Right...do not change the subject because it's considered rude. Change it because the topic drifted from the original topic and a fitting subject line helps people decide whether they want to read any subsequent sub-threads. That's just email etiquette as old as the tubes. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
RE: *Tim Chase changes topic and talks smack* On Jul 20, 8:38 pm, Tim Chase python.l...@tim.thechases.com wrote: On 07/20/2011 08:17 PM, rantingrick wrote: RE: *Ben Finney changes thread subject* Please everyone, do not change the subject of someone's thread because it's considered rude. Thank you. Right...do not change the subject because it's considered rude. Change it because the topic drifted from the original topic and a fitting subject line helps people decide whether they want to read any subsequent sub-threads. That's just email etiquette as old as the tubes. What about the etiquette of staying on topic? The only person who is OFFICIALLY allowed to change the subject matter of a thread is the OP. Sure some folks might make an off topic post here and there however i find it bombastically rude when folks just change a topic of thread they do not own. How would you like it if i came to your house and wrote my name on your refrigerator door, or used your toilet without asking, or slept in your bed? I would not do that because i have manners. Feel free to make yourself comfortable but don't put you feet on the coffee table. -- http://mail.python.org/mailman/listinfo/python-list
Changing subject sucks. Re: I am fed up with Python GUI toolkits...
On Jul 20, 6:17 pm, rantingrick rantingr...@gmail.com wrote: RE: *Ben Finney changes thread subject* Please everyone, do not change the subject of someone's thread because it's considered rude. Thank you. No it isn't. Rambling off on a new topic under the wrong subject is rude. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
rantingrick rantingr...@gmail.com wrote: The old reinvent the wheel argument is only valid when wheels already exists. Currently we have triangles (or maybe pentagons) but no wheels. No, currently we have a small handful of people who feel the wheels are triangles but have done nothing more than complain about it, while those who don't feel likewise continue to cycle on them smoothly. The reinvent the wheel argument is only valid when the affected people do something other than whine. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
rantingrick rantingr...@gmail.com wrote: What about the etiquette of staying on topic? Such as raising your personal opinion of online etiquette in a thread on GUI toolkits? As always, there's what you say, and there's what you do, and never the twain shall meet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing subject sucks. Re: I am fed up with Python GUI toolkits...
On Thu, 21 Jul 2011 12:34 pm Phlip wrote: On Jul 20, 6:17 pm, rantingrick rantingr...@gmail.com wrote: RE: *Ben Finney changes thread subject* Please everyone, do not change the subject of someone's thread because it's considered rude. Thank you. No it isn't. Rambling off on a new topic under the wrong subject is rude. Ha ha, rantingrick lecturing others on rudeness! How cute! Or hypocritical. Sometimes I get those two confused. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 20Jul2011 19:06, rantingrick rantingr...@gmail.com wrote: | | RE: *Tim Chase changes topic and talks smack* | | On Jul 20, 8:38 pm, Tim Chase python.l...@tim.thechases.com wrote: | On 07/20/2011 08:17 PM, rantingrick wrote: | | RE: *Ben Finney changes thread subject* | | Please everyone, do not change the subject of someone's thread because | it's considered rude. Thank you. | | Right...do not change the subject because it's considered rude. | Change it because the topic drifted from the original topic and a | fitting subject line helps people decide whether they want to | read any subsequent sub-threads. That's just email etiquette as | old as the tubes. | | What about the etiquette of staying on topic? The only person who is | OFFICIALLY allowed to change the subject matter of a thread is the OP. | Sure some folks might make an off topic post here and there however i | find it bombastically rude when folks just change a topic of thread | they do not own. You're labouring under a misapprehension. The OP doesn't own the thread. Starting a thread on a public list is like throwing a party. People are going to come. And talk, damn their impudence! It is good to stay near the topic, but threads will inevitably drift unless they're talking about something utterly trite. It is good of an author to mark his/her departure from the main topic, should it be significant, with a subject change. Or even a new thread. | How would you like it if i came to your house You can stop there, thanks. You continue to confuse a cooperative anarchy with some kind of stringent autocracy or heavily premoderated forum or something. As with your docstring formatting opinions or your spaces-vs-tabs opinions: mandating behaviour is a little pointless - it can't be enforced, few directives are unambiguously one sidedly good and so mandating stuff is divisive and will drive people away. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ It's quite difficult to remind people that all this stuff was here for a million years before people. So the idea that we are required to manage it is ridiculous. What we are having to manage is us. - Bill Ballantine, marine biologist -- http://mail.python.org/mailman/listinfo/python-list
I am fed up with Python GUI toolkits...
What is wrong with them: 1. Designed for other languages, particularly C++, tcl and Java. 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. 4. They might look bad (Tkinter, Swing with Jython). 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) How I would prefer the GUI library to be, if based on native widgets: 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable. 5. No particular GUI thread synchronization is needed -- Python has a GIL. 6. Expose the event loop to Python. 7. Preferably BSD-style license, not even LGPL. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. The Eclipse SWT library does some of this for Java does some of this, though it also has flaws (e.g. manual memory management). A Python GUI toolkit could be partially based on the SWT code. Is it worth the hassle to start a new GUI toolkit project? Or should modern deskop apps be written with something completely different, such as HTML5? Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 7/19/2011 10:12 PM, sturlamolden wrote: What is wrong with them: 1. Designed for other languages, particularly C++, tcl and Java. 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. 4. They might look bad (Tkinter, Swing with Jython). 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) Greg Ewing's pygui project is still going and releasing new versions. How I would prefer the GUI library to be, if based on native widgets: 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable. 5. No particular GUI thread synchronization is needed -- Python has a GIL. 6. Expose the event loop to Python. 7. Preferably BSD-style license, not even LGPL. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. I think you described pygui. Is it worth the hassle to start a new GUI toolkit project? Ask Greg what you might help with. Or should modern deskop apps be written with something completely different, such as HTML5? An interesting question. I think the pyjamas project is aimed in this direction, but the author says he will never port to Py3. (He explained his reasons on this list when I suggested that.) --- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 There's PyGUI, which, at a glance, fits whit what you want. Looks like it uses OpenGL and native GUI facilities. http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ It has quite a few external dependencies, though (different dependencies for each platform, so it requires a lot to be cross-platform). - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOJj7PAAoJEPiOA0Bgp4/Lh5AH+wXA8SneG7QQfL/WQipQCG93 79JIVMEQz7O+LYoHNLso1nNoVlz2UW4h1xaZp5ZrqMDyHRNQPwjA15hPGUqjng2V MBUD3IMvi4K04ZbozAZ/dWFnKrhLZ043OrwtSsKZImPcoP4Kq3ReiejjDLPReFLV 3yzyYa6i1eIabU5JlxD2B6vPM9IfYdgB3/UZXcI0DKozU7LnCGNMoNlEJzfH4c5C gkqr2e0RhWRf17Nax9RURbaIFjbMCuFTTR7HM46Z1/WLf16+sr2AQElzG+d8a6Bx kq5i/u5ie+rpvSpz3KbhrPaF7rCyPBa3xdX+UTfrlp3geGGbzI4K/PbN12tVAMc= =h89v -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
OK, I'll bite... On 7/19/11 10:12 PM, sturlamolden wrote: 1. Designed for other languages, particularly C++, tcl and Java. So? Doing a GUI toolkit is a hard project. 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python has a standard library!) Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit specifically designed for scripting languages. 3. Unpythonic memory management: Python references to deleted C++ objects (PyQt). Manual dialog destruction (wxPython). Parent-child ownership might be smart in C++, but in Python we have a garbage collector. Again, so? Again, this isn't applicable to Tk. 4. They might look bad (Tkinter, Swing with Jython). Then again, they might not. A lot depends on the skill of the developer. I write highly polished commercial apps with Tk GUI's. I'm sick of developers blaming their ugly apps on the toolkit rather than their own lack of design training and/or skills. 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) That's right. People issue a clarion call for a new GUI toolkit, then discover that even a so-called ugly, limited, minimalist toolkit like Tk has twenty years of development behind it. And people think they can duplicate this effort in a few months by starting a flame war on comp.lang.python? 1. Lean and mean -- do nothing but GUI. No database API, networking API, threading API, etc. Presenting...Tk. 2. Do as much processing in Python as possible. No more native code (C, C++, Cython) than needed. And what's wrong with native (ie. compiled) code? Python is written in native code, isn't it? To extend Python in significant ways, it is often necessary to drop down into native code. 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. Presenting...Tk. 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable. Artist framework? I'm not sure what you mean here. 5. No particular GUI thread synchronization is needed -- Python has a GIL. No comment here. 6. Expose the event loop to Python. Presenting...Tk. 7. Preferably BSD-style license, not even LGPL. Presenting...Tk. 8. Written for Python in Python -- not bindings for a C++ or tcl toolkit. Well, that's the holy grail, but given the history of other toolkits, you'll reach a comparable level of maturity in 2031. The Eclipse SWT library does some of this for Java does some of this, though it also has flaws (e.g. manual memory management). A Python GUI toolkit could be partially based on the SWT code. Your practical suggestion for the basis for a new Python GUI toolkit is...a Java GUI toolkit? I'm quite confused. Is it worth the hassle to start a new GUI toolkit project? Not unless you want to reinvent the wheel yet again. Or should modern deskop apps be written with something completely different, such as HTML5? If it's written in HTML5, it is, by definition, not a desktop app. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Wed, 20 Jul 2011 12:12 pm sturlamolden wrote: What is wrong with them: [...] 4. They might look bad (Tkinter, Swing with Jython). Have you tried Tkinter version 8.0 or better, which offers a native look and feel? 5. All projects to write a Python GUI toolkit die before they are finished. (General lack of interest, bindings for Qt or wxWidgets bloatware are mature, momentum for web development etc.) Then you'll love PythonCard, which didn't die until after it was mature! Actually, that's not entirely true. PythonCard is still hanging in there on life support. Perhaps all they need is an infusion of fresh, enthusiastic blood. How I would prefer the GUI library to be, if based on native widgets: [...] 3. Instances of extension types can clean themselves up on deallocation. No parent-child ownership model to mess things up. No manual clean-up. Python does all the reference counting we need. Unless you're using three of the four major Python implementations, Jython, IronPython and (usually) PyPy. 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is suitable. 5. No particular GUI thread synchronization is needed -- Python has a GIL. Except for Jython, IronPython and PyPy. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
