You are positing a declaration ("A browser is not a suitable
environment for writing desktop apps") which is either trivially true
and thus uninteresting (A browser is obviously not meant for desktop
apps), or which you haven't backed up (if we funge the definition of
browser a smidge to include embedded geckos and webkits). I'll
highlight the parts where you're just making unsupported statements:On Nov 5, 9:42 pm, matthewjfarw...@gmail.com wrote: > The problem is that if I use a browser for writing desktop applications, > then I have to jump through a lot of hoops just to get basic stuff like > this working, just to prevent a user from doing something silly. "basic stuff like this" - what are you referring to? The back button? An embedded webkit can easily be configured to disable the back button and doesn't normally have one in the chrome unless you specifically put it there. However, the web model basically dictates that the back button should work and should do sensible things, it's part of what makes the UI of web apps far superior to non-web based desktop apps - as any user interface expert can tell you, undo beats the pants off of "are you sure" dialog boxes, or no way to revert, any day. The back button is 'undo' for navigation. When ajax is involved, managing history is a real pain on browsers, especially older ones, but if we are allowed to handwave an entire platform away for a single flaw, let me buy some new batteries for my wireless keyboard; I'm sure I'm going to exhaust the current ones if I'm going to list all of the silly things swing makes you do just for basic stuff to work. Look at the bigger picture; don't get hung up because there's a single flaw that annoys you. Especially a flaw that can be fixed pretty much outright. There's a bit of miscommunication in this thread, in that some are talking about deploying a webapp to a vanilla browser (and usually, in a way that works amicably on all major ones), vs. deploying a desktop app as a desktop app, but using a largely hypothetical java-based platform that involves an embedded webkit, a few hooks to manage the chrome and GUI/OS interaction, and a servlet runner of some sort. When deploying to a vanilla browser I still say a webapp is generally a far better plan than a swing app, but obviously there are far more corner cases where a web app clearly isn't going to work. Something as simple as local file interaction isn't even possible, so if you need that, clearly "webapp" is not a good direction to take. That goes without saying, or, at least, I assumed so. When the case isn't as clear, though, web apps win. Just look at the state of IT 2010. > You said that 'This is not how a web page is supposed to work'. I agree > completely. But this thread is about desktop applications. Not web pages. > Two different things. So you say. Where's the proof? > Unfortunately, you are not my client. In general, my clients do not > understand that clicking on the back button is a bad idea. If you think the back button is a bad idea, I doubt I'll ever be your client. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
