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

12 of 417 comments (clear)

  1. Good start, but not useful yet by lakeland · · Score: 4, Interesting

    Now I guess we get to find out how much KDE assumes X11. Because there aren't many QT only apps out there.

  2. 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 Natalie's+Hot+Grits · · Score: 4, Interesting

      "The good news is that they're not going to do that. If it ain't broke, don't fix it."

      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.

      --
      Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
    3. Re:Before all the flamers get in. by EvilTwinSkippy · · Score: 4, Interesting
      Network transparency is a beautiful thing. I admit, my needs are a little exotic, but I happily run my computer from several dumb terminals (stripped down laptops).

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

      --
      "Learning is not compulsory... neither is survival."
      --Dr.W.Edwards Deming
    4. Re:Before all the flamers get in. by slyall · · Score: 4, Interesting

      I would not be happy to give up remote display. Not going to happen.

      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 of X servers for Windows and MacOS that plenty of people use already.

      --
      "To stay awake all night adds a day to your life" - Stilgar | eMT.
    5. 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.

  3. Sounds like a plan. by Meat+Blaster · · Score: 4, Interesting
    While I've grown accustomed to X-Windows' ideosynchronities, 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. X-Windows 4 has been a vast improvement, but I'm talking about something more like OS X where the whole thing is rewritten to be very smooth and responsive to user input.

    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.

    1. 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
  4. 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
  5. The best solution by Anonymous Coward · · Score: 4, Interesting
    Plan 9's. The graphics, mouse and keyboard devices are standard devices that can be mounted from a remote filesystem; the advantage being the windowing system does not need to handle the network layer. And since each process has its own filesystem namespace, you have a bunch of different consoles and each program accesses its one at /dev/cons.

    The entire system, including the default program that runs in the window the equivalent of xterm [Far89] with `cutting and pasting' between windows is well under 90 kilobytes of text on a Motorola 68020 processor, about half the size of the operating system kernel that supports it and a tenth the size of the X server [Sche86] without xterm.

    The components of Plan 9 are connected by a common protocol based on the sharing of files. All resources in the network are implemented as file servers; programs that wish to access them connect to them over the network and communicate using ordinary file operations. An unusual aspect of Plan 9 is that the name space of a process, the set of files that can be accessed by name (for example by an open system call) is not global to all processes on a machine; distinct processes may have distinct name spaces. The system provides methods by which processes may change their name spaces, such as the ability to mount a service upon an existing directory, making the files of the service visible in the directory. (This is a different operation from its UNIX namesake.) Multiple services may be mounted upon the same directory, allowing the files from multiple services to be accessed in the same directory. Options to the mount system call control the order of searching for files in such a union directory.

    8½ serves a set of files in the conventional directory /dev with names like cons, mouse, and screen. Clients of 8½ communicate with the window system by reading and writing these files. For example, a client program, such as a shell, can print text by writing its standard output, which is automatically connected to /dev/cons, or it may open and write that file explicitly. Unlike files served by a traditional file server, however, the instance of /dev/cons served in each window by 8½ is a distinct file; the per-process name spaces of Plan 9 allow 8½ to provide a unique /dev/cons to each client. This mechanism is best illustrated by the creation of a new 8½ client.
    From here
  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/