On 06 Aug 2007 08:20:20 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > "Chris Mellon" <[EMAIL PROTECTED]> writes: > > No native look and feel - constrained by the browser. > > Might or might not matter for the application, especially considering > that tkinter is part of the discussion. >
The point is that you have no option with the browser - even Tkinter has platform theming support now. > > No control over browser UI idioms. I had to write this post twice > > because the text control lost focus and I hit backspace, going back in > > the history and losing my work. > > Sounds weird, I'm used to having stuff in text boxes stay in the > browser, and why did backspace have that effect anyway? > On Windows, backspace is a browser global hotkey that means "go back once in the history". When the text box lost focus, hitting backspace navigated back. Gmail uses ajax instead of a page load when you start typing a reply, and the fragile tricks it uses to try to keep the browser history and the ajax state in sync don't work in this case. It's a specific example of the general problems of the browser as application platform. > > 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. Which they won't (I don't even know how, from Firefox), so you can't rely on it working. You can mitigate with your own browser host, or if you write all your own file browsing in HTML and move it into your local browser. Poor solutions all around. > File system browsing for the limited purpose > of file upload is available in regular html. >Copy/paste of ordinary > text is always available. But not of anything else. I've often wanted to drag & drop a file onto the file upload box in gmail, for example. >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. > How about something as simple as context menus? You can't reliably override the browser context menu from a web page unless, again, you provide your own browser host. This is a good thing, because a browser needs to be wary of arbitrary malicious web pages. They aren't good application hosts. Keyboard shortcuts that happen to conflict with whatever the browser or any of its plugins happen to use, too. Although I notice that Firefox now allows web pages to override that, which is a little sad. > > No or poor dialogs. Poor multiple window support. > > Might or might not matter depending on the application. Most dialogs > can be done with html. Multiple windows are evil most of the time, > and should instead by done with multiple panes or cells in a single > window. > Multiple windows are the common case on the mac. They're not rare on other platforms as well. The fact that your windows are constrained to the browser and can't be torn off is a large limitation. No toolbars, no palettes, no modal dialogs (except on IE, or if you constrain them to the browser). Lots of unnecessary chrome on your extra windows, too (see below). > > More platforms to develop on and test with. > > Compared to a desktop app? I don't think so. > Did you ever try counting? X browsers * Y browser versions * Z platforms. There are javascript and CSS bugs and differences between all of these. From my own professional experience, it's not any easier to account for browser differences than it is for platform differences. It's getting better as more people jump on the web bandwagon and CSS and JS abstraction libraries show up, but it's not even good as the available platform abstraction libraries like wxWidgets or Qt. > > Limited to CSS box model for layout. > > Might or might not matter depending on the application. If you're > doing a consumer app that has to look slick, you have no choice but to > use something like wxwidgets (tkinter won't cut it either). If you're > doing a special purpose office or industrial app, slickness isn't > important. > I'm not talking about chrome and slickness. I'm talking about basic usability concerns like "will this work with a higher font size" and "will it reflow in a sensible way if I change the window size". The CSS box model works okay for text, it's not so good for widgets. More than a few web apps end up writing their own layout engines in dynamic javascript. This is sad. While I'm talking about chrome, add "wasted screenspace due to browser chrome" to a limitation of web apps, again unless you write your own browser host. This is another example of a feature that makes a good browser (don't let arbitrary web pages mess with my web browser functionality) clashing with the desires of a good application (don't waste screen space with irrelevant functionality). > > The web is a terrible application platform. There is not a single web > > application in existence which has even half the UI functionality of a > > rich client application. > > Some of us consider simple interfaces with consistent, familiar > (i.e. web) elements to be a good thing. Fancy client interfaces are > ok if you feel you need to make a style statement, but are often > unnecessary if you just want to get something done. > Man, you should be in PR with the way you spin things. You can't implement anything except the most trivial of applications using only the simple, familiar web elements like HTML forms. Anything more complicated than that needs to be done with DHTML and probably AJAX, and those UI elements don't look anything like the familiar ones. You go in one breath from saying that you can implement dialogs in HTML to saying that the rich client is the *less* familiar of the interfaces? > > There are some (even many) applications for which the benefit of > > global access and easy deployment makes up for the lack in > > functionality, but statements like "At this point I think nobody > > should write desktop gui apps without a good reason" are simply > > ludicrously misguided. > > Well, I don't say that good reasons don't exist, I just see a lot of > desktop apps that could be done just as well as web apps, i.e. for > those, the good reason didn't exist. > -- If you'd said "if you're making something really simple that has limited rich UI or data entry needs, consider a web application instead" I wouldn't have posted. A web application is something you make because the deployment and access benefits outweigh the UI and integration limitations, not as your default "go to" whenever you create an application. I'd like an example you have of a desktop application that could have just as easily been a web application. Bonus points if it's not a CRUD screen, and double bonus if you don't just handwave away things like file browsing. Although there are benefits even for the crud screen - I've written screens and applications for data entry professionals and they almost always prefer the speed optimizations you can make in a client application. -- http://mail.python.org/mailman/listinfo/python-list