Qt On DirectFB

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."

Comments

Before all the flamers get in.

[mindstrm]

Consider this: What do you really NEED X for. Try to think bigger than unix for a minute.

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.

Re:Before all the flamers get in.

[tomstdenis]

so first port motif, pango, gtk, etc... to DirectFB and then you can say "drop X, use DirectFB".

I mean its like saying "drop linux kernel, use QNX kernel" :-)

Tom

Re:Before all the flamers get in.

[caseih]

Isn't this backwards, going back to a dumb (albeit accelerated) framebuffer? X does much more than just push pixels. If you take a look at how Microsoft does their gui these days, you'll find that it's a lot more like X these days than a framebuffer.

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.

Don't be betting on it either way...

[Svartalf]

1) DirectFB supports GTK+ as well- I suspect Fltk's on the way as well.

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.

Windows or holes in the walls?

[Yaa 101]

This reminds me of a long going project that was once called Berlin and is renamed Fresco along the way...
Though their ambitions were higher with making a new windowing system...

They still exsist at:

http://www2.fresco.org/

Re:Sounds like a plan.

[warrior]

I've always thought that it would be a good idea to reengineer the whole system from scratch to take advantage of today's hardware and UI concepts.

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!!!! :) All of the drawing is also hardware accelerated. I've figured out a way to do this very well, without context switching the gfx hardware. One possible method will allow many clients to draw at once and keep a constant framerate (by not context switching/swapping buffers within a certain timeslice, these are very costly operations).

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.

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