Qt On DirectFB 417
Ashcrow writes "The feasibility for DirectFB to replace XFree86 just a little stronger thanks Maurizio Monge very first alpha release of Trolltech's Qt library for use in DirectFB. You can check out some screenshots or go straight to the source. And yes, it has been released as Free Software."
Good start, but not useful yet (Score:5, Interesting)
Before all the flamers get in. (Score:5, Interesting)
Yes, X has remote display. That's a really useful and flexible feature in some situations, no doubt about it. And from a technical point of view, it's extremely elegant.
In reality, though, to a great many linux users, it's a neat trick that you don't necessairly NEED.
We use QT or whatever and try to design desktop systems (KDE, Gnome) which really just use X as a way to load up graphics primitives... those same systems could equally work on something else, with some great benefits in terms of speed.
From a GUI perspective, if you use all KDE apps, for instance, things have a very nice consistent feel to it. Same with gnome. When you start mixing things, plus mixing in old X apps, you just detract from an overall experience.. so let's come out with a fast, standard display system taht's NOT x.... and use X rootless for those legacy applications we need.
Sounds like a plan. (Score:5, Interesting)
If this is a step in that direction, and it sounds like it is, I'm all for a decent alternative that isn't slowed down by having to be a swiss army knife. Especially if it makes resolution switching, 3D graphics, and direct screen drawing less of a hassle.
In somewhat related news (Score:2, Interesting)
Don't be betting on it either way... (Score:5, Interesting)
2) You CAN have X apps under DirectFB with XDirectFB.
3) They're posting rather impressive framerates under Quake III:Arena with the DirectFBGL layer code.
4) Qt's ALREADY in the embedded space- QtEmbedded is what they're using on the Zaurus.
directfb (Score:4, Interesting)
Great. Now let's see how I get this on my Debian... hmm... I guess it would take a whole other Debian "port".
Hey; it would be cool to combine Linux + DirectFB + GNUstep (+ "3rd party" Free SW) into a MacOSX wannabe distro. It's not a problem if that would still mean it's lacking more than half of the basic OSX functionality; it's the other, Free half that makes the thought interesting!
Re:Before all the flamers get in. (Score:5, Interesting)
I mean its like saying "drop linux kernel, use QNX kernel"
Tom
Re:Before all the flamers get in. (Score:5, Interesting)
Well, considering one of the founders of the XFree86 Project (and board members) has said that the *nix desktop needs to be replaced by a direct rendered model with an X interface on top of it (exactly the same thing but with faster local rendering at the cost of nothing) I would like to call bluff on your "If it ain't broke, don't fix it."
Because according to (at least one) XFree86 founder, it is broke, and it does need to be fixed.
The best solution (Score:4, Interesting)
From here [bell-labs.com]
Re:Before all the flamers get in. (Score:2, Interesting)
Windows or holes in the walls? (Score:5, Interesting)
Though their ambitions were higher with making a new windowing system...
They still exsist at:
http://www2.fresco.org/
Re:Before all the flamers get in. (Score:5, Interesting)
Why maintain a stable of computers when you can have one ubermachine (and of course a few cruddy ones for DNS and webcaching.) The wife has a copy of Win4Lin for Quicken and Office. And I never have to worry about being booted off the "good" computer.
Hell, with my cable tuner in the big computer I can actually watch TV over the wireless. That is of course, if I had cable. I'm practicing living on Internet and DVD's alone. Apparently I missed something called "Reality TV."
Re:Sounds like a plan. (Score:5, Interesting)
Good idea, I've thought the same thing. I wrote a GUI toolkit for X, and a window manager, so I've got a good idea of how the whole thing works. I quit working on it as I was frustrated that I couldn't do some of the neat things I see in OS-X on X (that sounds funny, doesn't it?). Soooo...
I started from scratch writing an OpenGL based display server. I'm using a lot of ideas from X, but throwing out a lot of cruft and adding lots of enhancements. All of the drawing is double-buffered -- no more Expose events!!!!
Some of the ideas I am keeping are the idea of "internalizing" graphics buffers to the server where they can be shared among other applications. I'm also keeping the idea of a replacable window-manager like shell.
For fonts I'm using Freetype. Standard image format is png. The display is also hardware-resolution independent and colordepth independent. Right now I'm being setback by the fact that I can't get X working on my new laptop (anyone know a modeline for WUXGA+ 1920x1200@60Hz, for Compaq X1000?). For communication I'm using named pipes/shared mem.
So far, my numbers are better than these [apple.com].
I'd also like to implement creating server-side macros so a client can pass one command to the server and execute a whole set of drawing routines atomically. Oh, and the source is definately going to be open. Any of this sound like a good/bad idea?
Cheers,
Mike
Terminate the Terminal (Score:3, Interesting)
It's worth remembering why X is a network-based system in the first place. The X server software we use now was originally meant to run only on a dedicated terminal. Some of these were actually manufactured (I think there might even be some still in production) but X Terminals were never cheap enough to compete with single-user computers for most applications. I suspect that the X architects just took it as a given that most computing would always be done on time-sharing systems [wikipedia.org]. Hey, don't snear at them. That was about the time that Intel almost went under...
Re:nice (Score:3, Interesting)
Running it as a local desktop it is, however, not that excellent.
So basicly, the same people who whine that Windows sucks, especially all the legacy code from the Windii of old are now whining when the *nix legacy code that is X is beeing replaced?
Did I miss something? I think it's a great idea.
Re:Before all the flamers get in. (Score:4, Interesting)
I guess the problem is figuring out whether or not the library is remotely present, and falling back gracefully if it isn't.
Re:Before all the flamers get in. (Score:3, Interesting)
This is the only piece of "eye candy" that I miss from XP/2000 and I find that it is actually useful. And why after all this time hasn't X gotten an alpha channel? It seems like a lot of poeple would like this feature. Plus it makes using a terminal soooo much easier on the eyes.
Re:DirectFB Inherently Insecure? (Score:3, Interesting)
I suspect (since I have not tried it myself) that the problem with the DFB apps is that they don't come with the rendering abstraction layer that X provides (think client-server model). So every application needs to be root to write directly to the framebuffer. Sure, it will increase the rendering speed, but it sacrifices security while doing that.
Re:Before all the flamers get in. (Score:4, Interesting)
There is no reason why you can't run a X server over the top of a directFB desktop. This would enable applications that support the new system to run fast locally while X based Apps (remote and local) can take to the X server.
There are plenty [google.com] of X servers for Windows and MacOS [xdarwin.org] that plenty of people use already.
Re:Windows or holes in the walls? (Score:2, Interesting)
-Stefan Seefeld
Fresco architect and lead developer
You can't save it till you need it (Score:2, Interesting)
If you are worried about interface responsiveness, there are plenty of things that are being done to address that without giving up the X paradigm, such as the X DRI extensions, and X server hardware support (its difficult enough to get NVIDIA and ATI's support for X, do you think they'll want to bother with 2 totally different unix graphic drivers?), and my personal favorite, the preemptable kernel (woohoo, Linux 2.6! (3.0?)).
Re:Before all the flamers get in. (Score:5, Interesting)
I own a zaurus and was initially impressed with the Qtopia/OPIE user interface. That is until I hit that one design flaw: They write directly to the framebuffer. This means I can't mix and match gtk programs with qt programs. This means I can't develop any non-free apps at all, since QT is GPL and that's the only thing you can run on Qtopia.
As I disected QT/E, I found that it pretty much had to duplicate many things that X does well, like windowing. Yep. And event handling and exposure stuff. Personally I think the Qtopia guys would have been much better off using the mini KDrive X server and use a modified version of QT/X11.
As soon as I can, I'm blowing away Qtopia and not going to OPIE but rather to GPE, which is based on X. A much better solution. Check out their screenshots if you don't believe me how well X fits a handheld.
My point here is that I don't think this directfb idea gives me any more advantage than X does. Sorry. Furthermore, we'd just need an X server on top of directfb anyway to run our main apps, and that is essentially duplicating the drivers that X11 already uses to talk to the framebuffer.
The best improvement I think we could bring to X11 would be a special mode where each window is a live opengl surface. That way we wouldn't need to do "exposure" events and other things. Window dragging would be silky smooth. Other 3d effects could follow. Forget the frame buffer.
Re:Sounds like a plan. (Score:3, Interesting)
I don't think anyone has claimed that at all.
Of course there is overhead involved in that abstraction, but there is overhead plenty of places. With modern hardware it's trivial. You can run X on a 486 just fine, and if the overhead isn't too much there then why would you worry about it on a newer 'puter?
Lots of people complain about X in ignorance, because what they're complaining about, when you look at it, isn't X at all. It's bloated crap they insist on running on X. It's libraries compiled with silly options. It's Xfree86, in some cases, which is simply one implementation of X, and has some weak spots. People, innocently, then generalise that because one poorly configured or designed system that happens to use X runs poorly for them, that something must be wrong with X itself, but that does not follow.
If you throw that same bloated software on a FB, it's going to be just as slow and bloated. If you compile your libraries with debug symbols on and use them on FB, it's going to be just as much a ridiculous memory hog as it was on X. If you don't use (or don't have) a good accellerated driver for your video card, changing from X to a FB isn't going to fix the problem.
FB makes sense for embedded applications where you really don't have room for X. But on a regular workstation, you have more than adequate resources to run it and run it well. If it's not running well, the problem is not X itself, and changing from X to a less sophisticated, capable, and mature system isn't going to address the real problem, except possibly by sheer accident.
Re:Before all the flamers get in. (Score:3, Interesting)
The thing is, while this is excellent advocacy, almost no one actually does this. Most people, at home, in a small business, or in a large corporation, have desktop machines, not thin client GFX servers. And they want to keep them.
There's a few legacy apps where X is required, but MS own's 90% of the desktop, and the desktop is not migrating to any *nix until the *nix's drop their 10 year old X server technology and move to something more modern.
I've lurked on several X formums for a while now, and there's seems to be a common thread. While X was written to run well on a very low end machine (one person said they had helped develope X on a 8 MHz 68000 CPU), everyone agrees that the current X desktop is rather laggy on much higher end machines. This has two reasons: lack of hardware accelleration support (good video card drivers for X are really hard to find) and the fact that modern apps do not do what X was designed to do.
Motif is a graphical desktop specification that is designed to run well on top of X. But no one likes the way Motif looks anymore, at least no one used to Windows or Apple GUIs. After 10 years, it' time for something new, IMO.
Re:Don't think so.... (Score:2, Interesting)
If anything, I want to see X11 incorporate more network saavy features... not remove them. It would be nice, for instance, to park X11 sessions and applications, much like screen [gnu.org] allows you to multiplex terminals. (There are apps like xmove and others, but none of them are reliable enough yet to withstand X server reboots.) I'd also like to see more RDP-ish functionality (Microsoft's RDP protocal lets you carry sound and printer connections over the network as well). And more flexiblity when working with different screen depths and other resources would be nice too.
Getting back to your point... a frequent piece of design advice is to "optimize the common case". Yes, cutting out network independence does help performance for the common case, but consider: for many, network independence is a must-have feature. It provides all sorts of flexibility with different hardware arrangements and usage models. Thin-client protocals like VNC are nice, but they don't cut it for serious, extended use. And the DirectFB X server isn't going to provide a whole lot of network independence if developers are targeting DirectFB.
The true promise of network independence is only now being realized: it opens up new avenues, even for users who have been content with the "single PC, single desktop" model. It would be a shame to lose the network conveniences provided by X now that we have computers fast enough to host it. :-)
Yes, it would be nice to optimize the common case, but cutting network independence is the wrong way to do it: ideally, the client librarys should be able to choose b/t listening on the network and connecting via shared memory (if X doesn't already have an extension for that [Xshm?]). This choice should be done by the library so that all apps written for X11 are network-capable by default. If the programmer knows they are doing something intensive, then they should be able to do something special to insist on a non-networked app, but this should be the exception and not the rule (and I think X11 has extensions for this too [DRI? xv?]).
Re:Before all the flamers get in. (Score:4, Interesting)
The drawback is that such X clients only work if the remote client has the appropriate extentions loaded.
It is well possible to develop QT or GTK X extentions. However for normal uses on a LAN any 2D application is fast enough to make it totally superfluous, and thus it makes to sense to throw away compatability with all X servers. Only for 3D, for video streaming and other special applicaions it makes sense.
Re:Before all the flamers get in. (Score:3, Interesting)
I would like to also point out that the human eye can only see 12 frames per second. Motion pictures are shot at 24 frames per second. The picture on your CRT refreshes 60 times per second. Any difference you percieve in frame rates above 24 are in your head, above 60 are REALLY in your head because you aren't seeing them.
While I like the power that X provides and agree (at least in part) with your earlier posts, I have to call you on this one. I can see a difference between a monitor running at 60Hz refresh and one at 85Hz. It is especially apparent when viewing large white areas (like a blank word processing document) and on larger monitors. I can also see the jerkiness that accompanies 24 frame motion pictures as compared to 60 field (30 Frame) television when there is a great deal of motion. I can tell the difference when I see a 50 field (25 frame) tennis match televised via satellite from Europe compared to the NTSC standard. I can tell if a video game is running at 30 frames versus 60 frames, but above 60 I don't notice a difference.
That having been said, I have walked past monitors with a noticable flicker and the person using it doesn't complain. Even when I call attention to it and up the refresh rate, they can't tell the difference between the two. I suspect that sensitivity to refresh rate is highly variable among individuals.