ok. I was focusing on mobile phone applications that seldom are as complex as photoshop or similar. an average cellphone "app" is pretty simple...

I think the Acer Iconia W500 with AMD C50 is the best one but any Intel Atom based will do just fine too.

i realise that many maem-oans are deeply rooted in the debian .deb tradition, but i was always a suse .rpm fan, and i certainly wouldn't cry if more big distro's hopped on the LSB standard, including Nokia with whatever Linux concoction they come up with next.

Adding a web page as an icon to the menu, which will launch the browser and some page (app) in it is not really an example of HTML(5) based environment - by that account you can claim that even Maemo 5 with web page 'widgets' on the desktop was moving in that direction. Heck, you could claim that Windows 95 was moving in that direction with .url files/shortcuts linked to a browser.

And the Quake example, while being impressive for the time, does scream - it's just a browser! Granted, the new concepts like Canvas, WebGL and so on made it possible to port a full-blown game engine into a browser-friendly variant, but it will never be able to reap the benefits of native, or at least as-close-as-possible-to-native development - when you do it the traditional way, you can actually talk directly to the graphics sub-system (or in worst case through 2 intermediaries - gfx toolkit and drivers) and tell it to draw something where you want it, how you want it, with blazing performance along the way. When you do it in a browser, you have about 10 layers your instruction has to pass through before the graphics chip sends something to the display. And the same situation is for any other hardware access.

On battery-operated devices this aspect is anything but negligible, you can use the Android platform as a prime example of how you end up needing dual-core CPUs just to handle the basics on a satisfactory level (which also means abysmal battery performance with not much room for improvement) whereas other, closer-to-native devices get away with half the hardware, or less, needed for the same performance. Case in point - my N900, with all its quirks and bugs, and almost 3 years old hardware, and anything but professional-level apps, runs smoother than most, even this year's Androids and their professional-grade apps I've tried. Even when it comes to HTML, comparing MicroB with the native Android browser on most Android devices - MicroB blows them away, and I'm talking only about the performance part.

And what if you want to create your own browser (for whatever reason) on a platform that's HTML5-based? You'd be essentially writing a browser inside of a browser. Browserception?

With that being said, I'm sure that the hardware will progress and given enough time it will be able to cope quite satisfactory with all those virtual layers between the software stack and the actual hardware, so eventually HTML5-based apps should be able to provide enough wiggle-room for most needs, just as with Java from 10 years ago and today. I don't think we're there, yet, but that's a whole other subject. What I the find most annoying in that concept is that you're essentially restricted to one language, one toolkit, one way to do things, with various conceptual limits that HTML5 brings.

As a developer, those things are more important to me than things like open-source kernel or OS components. As volt above said - I wouldn't mind running a Windows 8 on my device as long as it doesn't restrict me in a way how will I create and distribute my apps, or at least doesn't restrict me as much as - you will use HTML5 or GTFO. Sure, the more open - the better, you're less at a whim of the OS developer and you can actually fix the bugs the developer fails to acknowledge, or doesn't want to be bothered with, but that is not as important to me (and the vast majority of developers) as is the flexibility and as-little-restrictions-as-possible when it comes to developing for that platform.

When it comes to programming, there is a plethora of ways to skin the cat, and no tool is the best for all cases (and in some cases one and one tool only cannot do the job at all), which is why it is inherently wrong to restrict development to only one channel. Case in point, HTML is not even close to the best way to describe a layout (due to its top/down origins), and JavaScript is inherently difficult to manage, debug and reuse (due to its lack of extensive set of natives, strict typing and prototype-based OOP - some of which were changed only recently). Sure, it's easier to create an info page with some basic interactions in HTML/JS combo than it is, for example, in C++, but writing something more complex, for example a game engine or some face recognition software in HTML5 (even if it would provide direct access to the webcam's feed) is a daunting task to be taken only by enthusiasts to prove that it can be done at some level. Not to mention that you have to rewrite every single library, that has been brewing for decades, into JavaScript, if possible at all, just to use features that you're accustomed to. And that's only from development POV, performance is a whole other subject.

HTML5 suffers from the same problem that all previous iterations of HTML suffered - a slow mammoth that is W3C, that takes years, or even decades to push even the most basic improvements, and at least the same time browser developers to integrate those. JavaScript was stuck for more than a decade due to Ecma International failing to push the new specs for ECMAScript, and even those from 2 years ago are not on a satisfactory level + many browsers don't support the full set of those and most developers don't even know that the changes exist. For a comparison, you can check what Macromedia, and even mammoth-itself Adobe has done with ActionScript over the same time period, starting on the same grounds of ECMAScript 3 - today you can actually create and manage a moderately complex project in AS3, while using good programming practices and being fairly productive, the same cannot be said for JavaScript even in its latest iterations.

I personally don't mind having an option of developing close-to-native HTML5 apps, for many use cases it is the most optimal solution, but making it prime-and-only development option is just wrong. Qt is probably the best of both worlds when it comes to portability vs performance, which is why I condoned that direction (as long as there is alternative, of course), HTML5 is a step in a wrong direction.

For such apps, each and every platform should usually be good enough. HTML5 apps should be very portable, as should Qt and Java. "Should" often hangs at someone having to do a manual porting/recompiling, though.

Traditional Linux ARM apps are harder to port, but they are powerful tools if someone manage to port them. That's what I've liked with Maemo. Not "apps" as in single screen single functionality ad screens. Few of those have given me much.

Things sounds much smartererer when they come from you than from me, but I agree completely with your full post.

...or, rather than crippling themselves by moving to a lowest-common-denominator (the main reason it was chosen), perhaps merge the two by pulling in the odd thing RPM-based systems do better than DEB-based ones into DEB and rename it to be a bit more distro-agnostic.

Yep. That's right, that's right...

I have an HP Touchsmart TX1025-dx (I think that's the model number, I don't have it here with me)

There really is only a few things missing to make it a nice complete set up. XInput2 for multitouch (I believe GTK 3.x supports it already, but Xorg doesn't quite yet) and the auto rotate has to be tweaked and hacked in. Gnome 3.0 is also missing it's own onscreen keyboard, though I really like Cellwriter for the stylus.

I would love to put it on my Superpad 2 Flytouch 3 Chinese knock off tablet. Gnome 3.x would just rock on that.

slaapliedje

Edit; I guess technically the Touchsmart isn't a tablet, but more of a convertable touch screen laptop.

I'm seriously thinking now; had Samsung control of Qt and the Moblin core (basically MeeGo), they would've bought Palm for $1.5B in a heartbeat.

Combining the patents, designers, developers, and contracts from Palm... to the sweet base Intel was working on... to the awesome ecosystem Qt can provide, Samsung would've cooked it up like a Master Chef.

(Big) Bada (Boom)... would be just their dropped development. They would've built a tablet OS which would easily surpass HC3.2 and later tone it down to a smartphone OS which would be quite the beast. Even later, they would buy Alien Dalvik/Myriad/whatever and have "MeeGo" support Android applications but emphasize developers for Qt.

Why?
Cause Samsung has cojones!

Bad example. Yes, Visual Studio has different languages, but ultimately it is all based on a common SDK. Non-standard SDKs on Windows (Qt, GTK+, tkinter) are second class citizens. People don't develop with those on Windows unless they have to. They also don't have much in common.