Paul Rubin <http://[EMAIL PROTECTED]> writes: > > No native integration - no "open file", no "browse the filesystem", no > > rich drag and drop, no copy/paste. > > File i/o and file system browsing are available from javascript if the > user grants permission. File system browsing for the limited purpose > of file upload is available in regular html. Copy/paste of ordinary > text is always available. However, this type of requirement is what I > mean by a "good reason" to write a desktop gui. It applies to some > applications, not all.
I should also add: there is also the possibility of running a Python program with an embedded http server on the same desktop as the browser, using the browser purely as a gui, but with the Python program having complete access to the file system and so forth. This could be seen as combining the disadvantages of both the remote web server approach (i.e. gui elements constrained by the browser) and the all-desktop approach (deployment issues). However, a lot of the time it's still just plain easier to do. Whenever I've written a desktop gui app I've always just been shocked at how much time goes into making the gui look decent and do the right stuff, even though none of mine have been even slightly slick (they've all been for industrial applications). When I do a web gui, it's been just a matter of tossing some html into a file or into some print statements, viewing it in a browser, and tweaking it a little as needed. Maybe that's mostly a matter of the lousy state of gui toolkits, and we actually need a toolkit that's more like an embedded browser. But we don't have that at the moment. -- http://mail.python.org/mailman/listinfo/python-list