GUIs - A Modest Proposal
in [Python]
|
From: Arndt Roger Schneider on 7 Jun 2010 17:25 Terry Reedy schrieb: > Ant > I agree that the current tk situation is not completely satisfactory. > In particular, the IO facilities are inadequate and have not, to my > knowledge, changed in a decade. Image input formats are limited. There > is no canvas output as an image. (Output of the canvase display list > as a dialect of postscript that not everything can read is not a > substitute for this.) > Hah, You are ill-informed. tkpath 0.3 contains a surface element, which renders vector graphics elements in an off-screen tk image. Forget postscript! Generate SVG from a tk canvas or --better-- from tkpath. Jeszra (from me) generates SVG. There is also a SVG export package available in python/tkinter, search the tkinter wiki. > However... > I think it important that Python come with a minimal IDE that is > adequate for someone like me doing Python-only development. I thank > the programmers of IDLE. So merely deleting tk/tkinter is not an > option. Indeed, having something similar to and at least as good as > IDLE for any candidate gui replacememt should and I think would be a > requirement for consideration. > Yes, use emacs or vim, without any GUI. > The problem with the big gui application frameworks are that they are > too big. The two I have glanced at -- wx... and qt -- have much more > than gui stuff and duplicate parts of the Python stdlib and other 3rd > party libs. The question is: What sort of devices are being used by *normal* computer owners in the near future? My guess: It wont be a Desktop Computer. Will any big GUI-Framework work on those devises? No! Will a light-weight GUI-toolkit being ported to these devices ? Perhaps, but not likely. Will any scripting language run on such devices? Perhaps, but not likely, if then it will be Ecmascript or a 4GL. Will SVG run on thoses devices? Yes, it must, because SVG is an integral part of OEBPS, and the tiny implementation is already part most mobile phones. Take a look at SVG for BlackBerry for instance. > > As for a small gui written in Python, you seem to have ignored the > link to pygui. Of course that has its own problems. Among others: it > is incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to > 2.6), which is the only place it could be added; the api sytle is not > standard in Python (get_xx and set_xx methods instead of direct access > or properties); and there is nothing yet like IDLE. > What would be required is a Python3 GUI project with multiple > contributors. > > Terry Jan Reedy > What sort of GUI project? On the initial proposition: Grapical design is art and art requires an artist. A community cannot work like an artist. The best a community of top-class *graphical designers* could produce would be of mediocre quality. -roger
From: Michael Torrie on 7 Jun 2010 17:52 On 06/06/2010 02:13 AM, Gabriele Lanaro wrote: > I'd really like to s/tkinter/WxWidgets/g, the multiplatformness is (almost) > the same but wx looks infinitely better. IMHO a good intention is to best > the API of wx. Does WX still do weird things like use event message maps instead of a sane signals and slots mechanism? Last I used it, the API wasn't very pythonic either (PyQt isn't really pythonic either; PyGTK seems to be much better). WX may look better than Tkinter on the screen, but it still has problems fitting in everywhere. Certainly wx apps on OS X are pretty bad, though that's mostly a developer issue. Qt makes it a bit easier to fit in by providing a nice API to change button orders and integrate with native dialog boxes. At least with Tkinter, it doesn't quite fit in anywhere so a user is alerted to the fact that it probably won't behave as other Windows apps do. Then again, the Windows world is so full of inconsistent UIs and custom widget sets that it probably doesn't matter either way. On OS X, though it will matter greatly.
From: Michael Torrie on 7 Jun 2010 18:05 On 06/06/2010 04:55 PM, ant wrote: > What an interesting set of responses I got! > And - even more interesting - how few of them actually seem to think > there is a problem, let > alone make any attempt to move the situation forward. You simply haven't made a case that there is a problem to be solved. Why should a language be integrated with and married to a GUI toolkit anyway? Python was born in the Unix world, and the Unix philosophy of using the tools that make sense in a modular and pipelined way is very applicable to GUI development. There is a case to be made for a widely portable, lowest-common denominator UI toolkit, but that will always only fulfill limited needs and always will be subjected to the limitations that have been specified by several posters. Thus for Python to really be successful in a broader sense, we need good, solid, bindings for Cocoa, or Windows forms (whatever they are using these days), as well as the most popular windows toolkits. We don't need another Swing. As someone else mentioned, web-based interfaces are increasingly important. That means you have to write your apps in a modular way that separates the GUI from the business logic. That way you can develop a nice GUI app and then, when there is demand, give it a web front end.
From: Grant Edwards on 7 Jun 2010 18:54 On 2010-06-06, ant <shimbo(a)uklinux.net> wrote: > On Jun 6, 2:22?pm, ant <shi...(a)uklinux.net> wrote: >> I get the strong feeling that nobody is really happy with the state of >> Python GUIs. ><snip...> > > What an interesting set of responses I got! And - even more > interesting - how few of them actually seem to think there is a > problem, I rarely write programs with GUIs. When I do, wxPython seems to work fine. So you're right: I don't see a problem. >[...] > > My concern is simple: I think that Python is doomed to remain a minor > language unless we crack this problem. How is being a "minor language" a problem? -- Grant Edwards grant.b.edwards Yow! How do I get HOME? at gmail.com
From: Terry Reedy on 7 Jun 2010 19:28
On 6/7/2010 5:25 PM, Arndt Roger Schneider wrote: > Terry Reedy schrieb: .... > Hah, You are ill-informed. How about 'under-informed'? That I readily admit ;-) > tkpath 0.3 contains a surface element, which renders vector graphics > elements in an off-screen tk image. As far as I know, tkpath is either not part of the tk that comes with python, or not accessible via tkinter, or not documented. > Forget postscript! Gladly! > Generate SVG from a tk canvas or --better-- from tkpath. > Jeszra (from me) generates SVG. I found http://jeszra.sourceforge.net/ It looks interesting but not quite what I need, which is to export a tk canvas that I draw on with Python in a form I can import into OpenOffice. There is also a SVG export > package available in python/tkinter, search the tkinter wiki. I presume you mean there is a 3rd party python add-on package that exports from a tk canvas. Can you be more specific as to what you meant? Googling 'tkinter wiki' got me to http://tkinter.unpythonic.net/wiki/ wiki.python.org/moin/TkInter has a link to the same. Searching there for 'svg' title or text has no hits. Searching PyPI also turns up nothing obvious. Googling further, I found canvasvg.py at http://wm.ite.pl/proj/canvas2svg/index.html via an answer to a question at http://bytes.com/topic/python/answers/629332-saving-output-turtle-graphics I will give it a try. Terry Jan Reedy |