Chrome OS Switches To "Freon" Graphics Stack To Replace X11

[justmy2cents]

Haha, I certainly don't mean a total takeover. Just where it makes sense, to the point that everyone's experience is roughly the same as it is now, but the developer side of things is much more manageable.

honestly, the worst thing about making html more popular would be doing same for google at the same time.

this Chrome i'm writting on is my last google... anything and this is just because computer is waiting reinstall. ditched android for sailfish, chrome for epiphany, google.com for duckduckgo.com, actively using my old gmail address for my fake e-mail address and even there mostly using it to register on as many porn sites as i can just to spam them with traffic just for fun

i wasn't really concerned when I knew that most lettered agencies have access to my data, problem is that right now it looks like whole world does

[scionicspectre]

Yes... that's a crazy idea.

Well, for a web developer who occasionally makes applications for mobile phones and has a hard time doing good layouts with Qt or GTK, it seems just a tiny bit less crazy.

Of course, QML is great, so if I had to choose one widget library on technical merit it would clearly be Qt. On the other hand, it's taking some time for designers to take advantage of it. Sailfish is a shining example of why I prefer Qt, despite the incredible designers in the GNOME project.

[ucepit]

Chromebooks are a dumb investment because you can buy a Windows laptops just as cheap; Look at the HP Stream 11 with 1 year of Office 365 for $199.

However, Chromebooks can make sense if you put a proper Linux distro on it either natively booting it via SeaBIOS or with a Crouton chroot. You can then run Chrome OS apps on a proper Linux distro via the Chrome and Chromium web browsers, along with all the other software available on regular Linux.

Will the switch to the Freon graphics stack have any negative impact on Crouton Ubuntu spawning an X11 server instance inside the chroot environment?

I agree. When you look at what you get for your money there is no contest. If they had got these things out of the door at a realistic price they may have had a chance but as of now these devices seem only for the uninformed or the idealogically obsessed.

[zanny]

Honestly, I've been hoping people could ditch GTK and Qt for a few years now in favor of HTML5 frontends. I know that's a crazy idea, but in the near future it may make a lot more sense than what we've been doing.

At least from my development experience (a little bit of Vala / GTK, but barely any - a lot of Qt and QML, and a lot of html5) I would much rather see the day where browsers support rendering .qml files than the day where people ditch desktop toolkits exclusively for the web. Writing any kind of application in HTML always feels like a fundamental hack, and it makes me feel so dirty when I have to have fifty lines of painful javascript to inappropriately fondle the DOM in ways the original creators of hypertext markup documents never intended them to be fondled.

That and I'd love to chuck keyboards every time I get an off by one pixel alignment problem or some other crap in CSS, because fuck CSS.

My point is that at least Qt is miles superior in developer sanity than HTML webapps, and that is just in general, and QML is a huge improvement on that that I feel certain organizations should even think about adopting into browsers as a webapp format since its designed ground up for network serving anyway.

[scionicspectre]

At least from my development experience (a little bit of Vala / GTK, but barely any - a lot of Qt and QML, and a lot of html5) I would much rather see the day where browsers support rendering .qml files than the day where people ditch desktop toolkits exclusively for the web. Writing any kind of application in HTML always feels like a fundamental hack, and it makes me feel so dirty when I have to have fifty lines of painful javascript to inappropriately fondle the DOM in ways the original creators of hypertext markup documents never intended them to be fondled.

That and I'd love to chuck keyboards every time I get an off by one pixel alignment problem or some other crap in CSS, because fuck CSS.

My point is that at least Qt is miles superior in developer sanity than HTML webapps, and that is just in general, and QML is a huge improvement on that that I feel certain organizations should even think about adopting into browsers as a webapp format since its designed ground up for network serving anyway.

Huh... yep, I agree with all of that. You got me. I think, for me, it comes down to what my goals are.

My first goal is to run everywhere, because if I'm withholding software from someone, I'm a jerk. My second goal is to have a relatively easy way to handle layout. My third goal is not to write C++. Writing for the web is the best option available to me so far as that goes. Qt has decently robust bindings, but the documentation for people to write non-C++ apps that utilize QML is... nonexistent? That isn't to say that Qt's documentation isn't, on the whole, amazing.

I guess I just need to get over my addiction to Javascript, Python, Vala, and C and come to grips with C++ some day. It just makes me uncomfortable because it feels like such a fundamental hack... wait a second.

[Maxjen]

Honestly, I've been hoping people could ditch GTK and Qt for a few years now in favor of HTML5 frontends. I know that's a crazy idea, but in the near future it may make a lot more sense than what we've been doing.

There are a few things that I require of web-applications before I want them to replace native applications:
- They must run at near-native speed
- They can be written in real programming languages (at least C/C++ and Rust)
- They must look and behave like real applications (i.e. not embedded in a browser)

The two technologies that go in this direction are NaCl and Emscripten. Emscripten compiles the code into javascript so it's out of the question. NaCl supposedly only has a 5% performance penalty compared to native applications but sadly it only works in Chrome and I think it currently only supports C/C++.

I think something like NaCl that supports more languages and isn't tied to a browser would be ideal. It should basically just be a sandbox environment that can safely run code from anywhere. But you should also be able to download that code and run it locally or put it on your webserver and run it from your desktop computer.

[balouba]

Anyone who thinks HTML tech is good enough should have a better look at why they're using apps on their phone.
Then make a new doc in Google docs (2 to 10s). Then do the same in libreoffice (instantaneous).

Then of course goes the whole "Google own and controls your OS, doesn't let you do much with it - all your apps, everything you and own do is recorded on their side, readable and modifiable by them" thing.

[liam]

This makes perfect sense to me. If you have so few external technologies to support, you might as well cut out everything in the middle to have a greater impact on overall performance. While I agree that a 'web OS' isn't a great idea in terms of being connected at all times, I do think that web technologies themselves are now wonderful for building performant interfaces. I think of it more like a graphical toolkit on steroids than simply a way to give companies personal information. You could certainly have a robust application suite that never connects to an external server and works offline. Firefox OS is probably the best example of this in practice.

Honestly, I've been hoping people could ditch GTK and Qt for a few years now in favor of HTML5 frontends. I know that's a crazy idea, but in the near future it may make a lot more sense than what we've been doing.

It's not crazy. Mozilla is working to bring this about.
I expect that interfaces written in HTML, JavaScript and CSS will be at least as fast (I think they'll be faster, actually) as native ones like those you mentioned.
Of course, I'd then expect some of the toolkits to then utilize, as much as they are able, the ideas of the servo layout engine, and possibly surpass HTML again.
Regardless, we should have an idea where things stand in a few months.

[mike4]

Maybe we see soon Android modified to run webgl/html aside / instead of java. Wouldn't surprise me and would make sense for google to not help
with Vulkan.

[darkblu]

Maybe we see soon Android modified to run webgl/html aside / instead of java.

https://www.mozilla.org/bg/firefox/os/

I have one at home, and it's a perfectly viable phone platform. Its SDK is hosted inside desktop Firefox, providing both an emu and access to the physical device. HTML5 + webGL = all you need on a phone.