Slashdot Mirror
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.
I find that the majority of my time in X is spent with something onscreen not running on the local machine. Even if we call the programs running on the same machine as my window manager this is true.
Maybe your desktop machine is fast enough, but not mine. I used to have an ultra sparc on my desktop. I hated it, genuine noisy fan, poor keyboard (You think Sun would know the controll key belongs next to the A. xmodmap is for more difficult tasks than that) And when I kicked the power cord all my compiles stoped. Now the server is in a back room, I have a NCD (A dumb terminal that can run X) on my desk.
As a devolper I find that my programs have to run on a machine in the lab. Pop an X window from the lab machine to my desktop and its like working in the lab. THen I can go home and pop an X window from the lab to my home FreeBSD machine. (I don't normally work from home, but if I can check my compile over night and fix the one typo after supper I save time at work the next day)
I used to have a sun3 in one room, and my main machine in anouther. In theory I could run programs on the sun3, but since the main machine is 400 mhz, and the sun is 16 (20? doesn't matter as m68k and x86 of different generations don't compare well by looking at mhz, but you can get the idea) who wants to? X still has life. Xfree86 is very fast on a local machine, and works just fine on a remote one.
I wonder how many slashdot readers figured out that this poster is being sarcastic? Anyway here is my take on this new embeded QT.
I read through the comments looking for someone who gets the real significance of this and came up with a blank. So here is my take on this baby.
When WinCE was 1st released oneof MSs major promises was that it would let you run the same apps and exchange files in the same format on both desktop and palmtop. Basically they promised MSWord in a pocket sized version.
It never happened and the reason is simple. MS office is over 200 megs of bloat. If they could have made it smaller they probably would but frankly that's tough to do. a 16 meg office suite and OS combination just isn't going to happen.
fast forward to the present. portable Linux has a compressed file system almost dubbing the capacity of a flash card so all you really need is a 32 meg office suite to fit in 16 megs of flash. KOffice is normally under 30 megs with the kdelibs. add on 2 megs of QT and 400 K kernel with all the drivers for that device plus frame buffer and you are running in 16 megs of cache with an OS and an OFfice suite. add another 16 or 32 megs of RAM to run everything in and you can get decent performance plus a desktop.
THAT is the significance of this thing. Linus plus Transmeta plus Troll Tech and the KDE team are about to deliver on Bill's promise.
Frankly I would hate to be a microsofty right now.
As for little issues like "dose this interface match the small size device?". They don't matter. Interfaces can be hacked and adjusted and with tidy modular code like this it doesn't really take much for good GUI designers to "fix" it.
--= Isn't it surprising how badly I spell ?
But I don't want to see a "toolkit" interface as the low-level API. This will completely freeze all gui devlopment. It will also make Linux much harder to "hacker" program and will make it less fun. If I am forced to use Qt, I might as well use MFC and Direct X.
What we need is a true replacement for X that keeps the (few) good ideas of X:
A networked, buffered protocol. Despite claims above, this is more efficient than a call-based API. There has to be context switches, unless we want to allow the programs to write and peek at each other's windows and to be able to clobber the video registers. The way to keep the context switches down is to buffer requests. Nice simple buffering at a low level, and we get an efficient interface, and we get networked transparency for "free" (rather than having to add it on, as MicroSoft is feverishly trying to do right now...)
The server does not have to do any "GUI" things. X design is 20 years old, yet it is obvious that it can draw all the GUI components ever invented (like we can copy Windoze quite exactly, and that was not a design criteria when X was made). I do not want a server that has any concept of a "menu" or "button". That is bloat. Put it in the user-level library (much like Qt and GTK are now). I really really fear Qt becoming the standard interface, even MicroSoft was smart enough to not cram MFC down everybody.
The server does need advanced graphics capabilities. Here the opposite is obvious: X obviously cannot duplicate new ideas. We have seen antialiasing for years now and X cannot do it. 3D requires a whole new interface (OpenGL) that does not interact well with the rest (it does not use X gc's or colors, for instance). And way too many programs "work" by creating a local image buffer, doing all the work there (thus losing all hardware acceleration), and drawing the image.
I envision a server much like X, but with graphics capabilities like a combination of PostScript and OpenGL (plus antialiased everything, like Flash, and 4-channel images, and transparent paint, and UTF-8 text).
It seperates programs into arbitrary-shaped "windows" (perhaps with transparency) and does not allow one program to draw in another's "window" or intercept events to another's "window". But except for that it is "GUI stupid". It must deliver raw events to the clients and make absolutely no assumptions about anything, for instance a "window" does not mean it has a border.
It sounds nice at first, but don't get the idea that Qt is replacing X on the desktop anytime soon.
As others have mentioned in here, it is likely that as a consumer desktop graphical system, an X-less QT/KDE interface could fill a big need. Consumers who just want to run graphical applications locally, don't ever need the overhead that X provides.
Is Qt becoming its own windowing system as well?
Seeing that KDE runs on Qt, if Qt/Embedded is source compatible, then the problem is solved. KDE on non-X displays.
Will you be able to run more than one Qt app and have them windowed?There are 2 answers to this. 1, with embedded devices, such as webtops, PDA's, and refrigerators, only one app is running, and therefore windowing isn't needed. For set top boxes, and consumer Linux installations, windowing can be provided by KDE, or any other Window Manager that is ported to Qt.
Where are the video card drivers coming from without X??Frame-buffer devices. This is what gives you the graphical penguin on most distributions bootup now.
Sure it's nice for embedded stuff, but a lot of people seem to have the idea that they're getting a small, fast, free X11 replacement for their desktops.And for those who are looking to run their Qt/KDE applications, they are.
-BrentWhen I asked them about it, they used the "we have to eat somehow" line.
Do you have a problem with them eating? The levels of intolerance here at Slashdot have reached an all time low.
A Government Is a Body of People, Usually Notably Ungoverned
I don't think the original poster was objecting to them eating, merely to their use of proprietory licensing.
:-)
Then he should have stuck to that objection, instead of bringing food into it
Seriously, it is unrealistic to expect commercial developers to give up their jobs and become waiters as suggested by RMS. But we are not talking about developers here, we are talking about the companies that employ developers. Before these companies can pay their employees, they need revenue. If Troll Tech open sourced their professional version, they would end up with ZERO revenue, and be forced to lay off their employees. If they can get complementary products to support Qt with in the future, then that may be an option at that time. But it is not an option now.
Qt is not the type of product that you can shrink wrap, put on store shelves, and hope enough users buy it to subsidize those that download it instead. And it's unrealistic to expect them to convert to a support company, particularly since their customers are in the profession least likely to need support.
The unfortunate fact is that Troll Tech has only one product. They don't sell other proprietary software like Redhat does. They don't sell hardware like VA Linux. All they have is Qt, and if they don't sell it they have to lay off their employees.
Their current situation is in my mind nearly ideal. The software is free if you write free software, but it's proprietary if you write proprietary software (I only wish that the Windows version were the same). But one who is of the opinion that all software must be free takes a strange stand by insisting that proprietary software get the benefit of a free library.
A Government Is a Body of People, Usually Notably Ungoverned
In a similar vein, the YAX (YAX Ain't X) project aims eventually to build a windowing system on top of svgalib/GGI/fbcon/Mesa/whatever that will support Gnome and GTK apps. There hasn't been a lot of traffic on the list, but the code is progressing, albeit somewhat slowly.
It sounds nice at first, but don't get the idea that Qt is replacing X on the desktop anytime soon.
Is Qt becoming its own windowing system as well? Will you be able to run more than one Qt app and have them windowed? Where are the video card drivers coming from without X??
Sure it's nice for embedded stuff, but a lot of people seem to have the idea that they're getting a small, fast, free X11 replacement for their desktops.
-JD
Both share a common graphics engine. Nano-GUI is based on an X-like protocol called Nano-X. Microwindows sports an interface similar to the ECMA APIW spec with some advancements.
RFC1925
I'm talking about efficiancy. If you look at the BeOS and MacOS APIs a lot of what they do is very efficiant code-wise. I'll speak for BeOS because thats what I use most often. The BeOS display server is just a thread in the app server (the BeOS is a microkernel.) The connection between the app and the server is just some really efficient message passing between two threads. It leaves out a lot of the negotiation and protocol stuff needed with X. In the app server, it is drawn using the graphics driver which is loaded as a dynamic link library. I don't know too much about MacOSX, but I do know that it too uses a light weight window process. Also, there is very little cruft in the BeOS window manager. It is not nearly as feature heavy, and a lot of the layers such as toolkits and window managers and desktop environments are not there. Sure it can't do any of the network transparent stuff, but it really isn't meant to. Aside from technical factors, X is slow from experiance. There are noticable problems with redraw in KDE, and it just doesn't feel snappy. Its on par with windows 98 and slightly slower than 95. Of course, since I come from BeOS, it is painfully slow. I've seen what a light, well designed interface can do. For example, BeOS has a busy cursor, but I've only seen it once when running a benchmarking app. Huge menues load instantly, complex views almost never have redraw problems, and there is never a time when you feel like you're waiting for the sytem to respond to you.
A deep unwavering belief is a sure sign you're missing something...
So will there be an API for 2d drivers for common cards? (embedded systems seem to be using all the same chipsets ...) will they use an existing one so that existing drivers can be used? what about 3d drivers?
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
This version of QT without X looks very nice for running on Set-top boxes - anti-aliased text and all. In this sort of environment, the 'display anywhere' X protocol is just excess baggage and a more direct route to the screen makes a lot of sense, especially if you are a company intent on providing a cheap device for general home use and want to get maximum speed out of the hardware. This does of course assume that the license for QT/Embedded is reasonably set... On the flip side, just how much software are you cutting yourself off from if you don't provide X libraries? Quite a lot I suspect unless QT/Embedded is providing some extra coverage.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Really?
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.
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.
No argument there; X is tried, true, and it works.
That doesn't help you if you're remote ... and yes those are nice sometimes if you're remote.
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.
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?
DNA just wants to be free...
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
All opinions expressed herein are my own, and not those of my employers, who are appalled.