Slashdot Mirror

← Back to Stories (view on slashdot.org)

Qt On DirectFB

Posted by timothy on from the jumping-a-layer dept.

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

14 of 417 comments (clear)

  1. Before all the flamers get in. by mindstrm · · Score: 5, Interesting

    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.

    1. Re:Before all the flamers get in. by tomstdenis · · Score: 5, Interesting

      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

      --
      Someday, I'll have a real sig.
    2. Re:Before all the flamers get in. by mindstrm · · Score: 5, Insightful

      I think you are missing the point.. we aren't saying "This is a drop in replacement for X" .. it's NOT X. I'm saying, to build desktop GUIs, we don't necessairily need to use X as a base.
      Yes, that might mean that only apps written for that gui would work.. but that gui could be, say, QT (as the article is about) or something else.

      See OSX for an example. Can I run X apps? Sure, if I fire up the X server. ANd they run just how you expect them to, they look the right way, and everything... but the apps that work really well use the native display library, not X.... and they work even better. And no, it's not because the X server sucks, in fact, the X server is quite good.

      We are adding so much stuff on top of X we have to question if we really need what X provides, and if it can't be better provided better another way.

    3. Re:Before all the flamers get in. by Arandir · · Score: 5, Insightful

      In reality, though, to a great many linux users, it's a neat trick that you don't necessairly NEED.

      In the midst of citing reality, you're ignoring reality. First of all, Linux isn't the only OS that uses XFree86, X11R6, or another X11 based windowing system. Heck, it ain't even the only free OS that uses it.

      Second, even supposing Linux will achieve it's goal of "World Domination", where everyone must use Linux or be branded a luser, it's still ignoring the fact that Linux is a Unix-like operating system, and to confine it to only the home based game machine is to deny it 95% of its potential.

      Third, that "neat trick" doesn't cost you a damn thing if you don't need it. The only thing holding back XFree86 performance is the fact that it must operate in userland.

      I've heard the phrase "why keep it of 95% of the people don't use it", referring to the remote network capabilities of X11. Well, why not turn that statement on its head? Why support SMP in Linux, if 95% of the users don't use it? Heck, why do I need snowchains for my car if 95% of the time I won't be driving in snow?

      Fact of the matter is, most people using Linux, BSD or UNIX outside of the home will want and need the networking capabilities of XFree86. If you want Linux to be confined to home game machines, then go roll your own distro. But in the meantime a lot of us want the capabilities of XFree86.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    4. Re:Before all the flamers get in. by caseih · · Score: 5, Interesting

      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.

  2. Wowsa! by tds67 · · Score: 5, Funny

    The screenshot looks HOT!!! And oh, yeah, the desktop looks okay, too...I guess...

  3. Don't be betting on it either way... by Svartalf · · Score: 5, Interesting

    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.

    --
    I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
  4. Mirror by keesh · · Score: 5, Informative

    Site is kinda slow... one, two, three, karma please?

  5. DirectFB Inherently Insecure? by istartedi · · Score: 5, Insightful

    Not being familiar with it, the first thing I did was read the FAQ:

    Q: Whenever I try to start a DirectFB application, I get the error message

    Error opening /dev/tty0
    A: You have to be root to run DirectFB apps. The main reason is that only root is allowed to change virtual terminals.

    So. In order to get the supposed benefits of DFB, you have to run apps as root? I guess maybe you could log on as a user and su the DFB apps, but that's a pain. Why should a graphics lib muck up security? That seems inherently broken to me. If it really just abstracts graphics then there should be no problem with user apps running it.

    This isn't really my area of expertise. Perhaps there's something I'm missing. Can anybody clue me in?

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    1. Re:DirectFB Inherently Insecure? by RelentlessWeevilHowl · · Score: 5, Informative

      Your X server also needs root access, and for much the same reasons. X needs to muck with the registers on your video card, for example. Nowadays, there's a little setuid program called "XWrapper" that gets access to everything it needs, then drops its privileges and loads the main X server on top of itself.

      There is at least one project (KGI) that attempts to rationalize all this. It puts the privileged functionality in kernel space, then exposes it all in a safe manner. Linus has not been receptive to this design in the past, preferring the X mechanism.

  6. Windows or holes in the walls? by Yaa+101 · · Score: 5, Interesting

    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/

  7. Re:Sounds like a plan. by warrior · · Score: 5, Interesting

    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

    --
    Intel transfer the difficult from Hadware to software, for get more power, programmer need more technology. -- chinaitn
  8. Re:Good start, but not useful yet by puetzk · · Score: 5, Insightful

    many KDE programmers have, because of QT/Embedded (and the zaurus).

    Konqueror, KHTML et all already have releases built to not need X (kdenox cvs module).

    Now, for the more desktop-ish apps this is certainly true, and X11 usage is (unfortunately) rather sprinkled about.

    The biggest single piece is probably replacing kwin, followed by the dcopserver.

    --
    The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
  9. Re:GDK vs. GTK by ambrosius27 · · Score: 5, Informative

    Not exactly. GDK is an *abstraction* layer with multiple backends, the X11 one being the most prominent. To quote from the GTK/GNOME developers' website: "Instead of directly building on top of the X Window System, GTK+ introduces an intermediate layer, GDK, which isolates GTK+ from the details of the windowing system. This simplifies things for the programmer and increases portability." See the webpage. Through GDK backends, GTK has been ported to MSWindows as well as DirectFB(see also here).

    I hope that helps.

    --

    ~~~~~~~~~
    dissertus scribendo latine videri volo.