Trolltech Developing Qt That Doesn't Need X

Thrakkerzog writes: "Here is an article about Qt/Embedded, a version of Qt which is source-compatable with Qt/X11 and Qt/Windows. It doesn't use X11, and just uses the Linux framebuffer. This is very ideal for embedded systems. Check the link for more info."

According to Trolltech's release, "Qt/Embedded will also provide functionality not found in the X Window System, such as anti-aliased text rendering and alpha-blending of images. For increased performance, Qt/Embedded can utilize hardware graphics acceleration and it is well suited for multimedia and Web applications."

Flashy graphics without the overhead of X looks like a winner for all the companies providing embedded Linux devices and sofware.

Comments

~/There's something wrong with make world today/~

[MenTaLguY]

X11 is still a great protocol for network transparent windowing

Really?

it's efficient

Only if you consider marshalling/unmarshalling individual drawing primitives across some sort of IPC (network or local) efficient. No, I'm not advocating direct application hardware access. Think outside the box, and maybe go back and look at how systems like NeWS, Display Postscript and Berlin are designed.

conceptually simple

No, not really. Try writing a window manager sometime. The original idea was (is) pretty simple, but once you start adding the various standard extensions that accumulated over the years, if you're writing something major, it's a real mind-bending mess. You're fortunate nowadays that GTK+ and Qt hide a lot of the evil from you.

mature

No argument there; X is tried, true, and it works.

In those areas where it really matters (bulk image and geometry transfer, 3D graphics) X11 already gives applications memory mapped access.

That doesn't help you if you're remote ... and yes those are nice sometimes if you're remote.

X11 does lack a few features, like antialiased drawing and fonts. Those can be added easily with X11's well-defined and widely used extension mechanism, and without breaking backwards compatibility.

Ever wonder why that hasn't been done yet? It's because most people who thought about it decided it wasn't worth the trouble: existing applications might run, but they wouldn't get the new functionality (i.e. antialiased characters). They would still still require a rewrite (yes, a rewrite, not just recompiling). The APIs and necessary backend code are just necessarily that different, because the original X ones were designed so badly.

[To be fair, the situation is a little better now, just because modern toolkits abstract the stuff enough that you could get by with only minor changes to the library APIs ... in most cases you'd just have to recompile the apps that didn't use the changed APIs, and only make minor changes to the ones that did, or that bypassed the library in some way]

If the antialiased font server was backwards compatible, it would only be because it kept the entire old (now redundant) architecture and API, in addition to implementing the new one.

The necessity of taking this approach to extend other aspects of X is one of the contributing factors to its bloat over the years.

Using libraries that access the frame buffer directly does make sense for embedded systems, but for general usage, they would represent a big step backwards.

Agreed, for the most part. However, arbitrated (i.e. not totally unsupervised) hardware access is still good for certain classes of specialized applications, and of course games. That's the need that ultimately spawned fbcon and KGI (the GGI kernel layer).

Something to ponder in parting... if someone wants to experiment with a windowing system that is not X, they either need to rewrite all the drivers themselves, run under X (...then what's the point?) or they need to have some kind of non-X driver infrastructure availible.

i.e. has the reliance on X to drive graphics hardware directly strangled the development of alternatives on Unix?

Similarities to Berlin or GGI?

[Thag]

I'm wondering how this would compare to the Berlin windowing system or GGI? With the goal of running embedded, I'd guess QT's new system is simpler, and less cross-platform. Basically a way to get QT apps ported to handhelds really quickly, rather than a general replacement for X. I'll freely admit, though, that I don't know much about GUI framework design. Anyone out there in the know and willing to comment?

I have to wonder, though, how many X apps will really work well on a handheld? It's a different environment, after all, with somewhat different inputs and uses. Just dumping X apps to a PDA would be like the approach MS used for WinCE, and it didn't really work.

Jon