The first, very-alpha, release of the Qt library on DirectFB is now available for testing. A lot of things still have to be implemented, so please don’t expect to be able to run Konqueror on DirectFB (yet). More info and screenshots at the Dot.
Qt Ported on DirectFB
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
From a technical standpoint:
Where’s the difference to QtEmbedded?
Read the linked article’s comments: “Qt/Embedded accesses your /dev/fb device directly, while the Qt in this news article uses the DirectFB API.”
Now my Linux box can be nearly as uncontrollable remotely as my Windows machines! Yay!
>> Now my Linux box can be nearly as uncontrollable remotely as my Windows machines! Yay!
Then stay with your rusty XFree86 and don’t whine against people who like DirectFB.
Personally I don’t really care about being able to control my system remotely or not (using a GUI at least) so I can only say: great, lets konvert Konqueror to DirektFB!
For MattPie :
A linux box is still totally remotely controllable with ssh and command line
XFree remote display export is too slow to be really interresting to my mine. I prefer using vim and bash remotely than Konqueror + Kate
Now my Linux box can be nearly as uncontrollable remotely as my Windows machines! Yay!
Ummm… two things…
As previously mentioned, Linux is still remote controllable via ssh,
And secondly, WinVNC (just google for WinVNC) gives you remote control access to windows (graphically btw), and I would assume that a port of VNC to DirectFB would be rather trivial, if not already in existence.
> A linux box is still totally remotely controllable with ssh > and command line
Granted. I’m just waiting for some dipshit to make GUI-only configuration tools (hopefully with binary format files!).
At least this seems like a good deal: if it’s QT, apps should be able to be compiled for either QT-on-FB or QT-on-X11.
I realize 90% of people don’t use stuff remotely, but I get a perverse sense of pleasure knowing I can run KDE PIM remotely and be able to access all my data with a “mostly dumb” client.
VNC is a rather sane lowest common denominator though, should be trivial to implement a server for DirectFB too (provide a dummy device to replace /dev/fb from the server).
While not as conceptually pure as X11 it is a _lot_ simpler and a far more portable. Speed is not too shabby with the modern GUI being so unsuited for X11 use anyway (pixmaps everywhere!).
DirectFB is primarily a vehicle for decoupling input and output device drivers from the XFree server. In essense it allows you to run XFree in rootless mode.
Unfortunately most vendors (ATI, NVidia, NEC (kyro and powervr) release drivers only for X which means that DirectFB currently lags X in quality of drivers, especially in the OpenGL arena
Having Qt on top of DirectFB does allow embedded applications to bypass the overhead penalty that X incurs.
DirectFB allows X to exists just fine as it is, so no one need worry about losing their good network transparency, nor worry about their everyday applications going away.
Honestly I firmly firmly believe that X has the best transparency out there. VNC and other competitors just don’t measure up for that task. And yes, network transparency is something any unix platform should never lose.
(hopefully with binary format files!).
If it’s GUI-only, why should it matter what file format it uses? Right right…it’s always a PLUS to not be able to fix a problem when you’re GUI goes to hell.
And…calling developers “dipshit”…why?
This sounds like it would be great for consumers who might put Linux (or FreeBSD etc) on their desktops. I don’t know any casual Windows users that want to control their computers remotely (although with WinXP, you can, built in). I especially don’t know of any casual users that want to compile software.
Please try to look at things from more than just your own perspectives.
Calling a person a dipshit: People who use binary config files are indeed dipshits, developer of not. I await being moderated down.
As for perspectives: I am considering all perspectives, and frankly, I don’t believe DirectFB support to be good for consumers or experts.
Pros of DirectFB: 1> Speed, 2> possibly transparent windows 3> easier resize/rotate
Cons: 1> Loss of remote control, 2> More code in the kernel to be maintained 3> When the Graphics driver crashes, it takes the whole machine with it as opposed just X
The biggest problem I see with modern Linux is putting too much crap in the kernel (which you can comment out, true). I’ve had my Linux machine hard lock with certain variations of the Nvidia kernel driver. Based on that, putting the entire video driver in the kernel seems like a supremely bad idea, much like Windows.
Hard lock is: on response on display, kb (including LEDs). I could ping the machine, but not ssh. (basically, all user threads stopped responding)
I’m not trying to troll, I think I’ve laid out valid concerns.
> putting the entire video driver in the kernel seems like
> a supremely bad idea, much like Windows.
Since when has Windows put video drivers in the Kernel? I’m the first to criticise Windows, but that just ain’t true. Not even for Win 3.1 IIRC.
Windows might not have the video drivers directly in the kernel, but it does load the modules in kernel space. microsoft went from nearly pure userspace to kernel space in either the transition from nt351 to nt4 or nt4 to win2k (i cant remember which). this was done for speed purposes, keeping the graphics stuff in kernel space did massive speed improvements in their internal testing. 9x has always had kernel space video drivers.
i cannot comment on anything in the win3.xx line or below, i honestly am not sure of the architexture.
…but those screenshots may not be safe for viewing at work, depending upon your seating arrangements.
…but those screenshots may not be safe for viewing at work, depending upon your seating arrangements.
Well, not to be a hypocritical prick, but you really shouldn’t be viewing those screenshots at work, or this site either for that matter. Especially if your seating arrangements leave you without privacy.
Well, not to be a hypocritical prick, but you really shouldn’t be viewing those screenshots at work, or this site either for that matter. Especially if your seating arrangements leave you without privacy.
Oh man… if i couldnt view this site at work…i think i’d go crazy. I haven’t looked at the screenshots yet, but the linux + anime combo that seems to always come up has almost gotten me in trouble more than a few times.
Obviously, I can view the site at work, as well as any other site I wish in the privacy of my office (with the exception of pr0n). We’re somewhat liberal about surfing since we work our asses off. However, I was providing a warning for people in public areas that hadn’t gone to the screenshots yet. Whether or not they’re allowed to go web surfing in the first place is a matter for them to figure out.
Ate these not a good news for a “desktop linux” and finally a “linux desktop user”? As an end user, I do not care about kernel, file system and so on. I just will appreciate a machine with a consistent GUI interface.
PS I’m not a linux user, but I have tested linux on live-cds.
Pros of DirectFB:
1> Speed:
-it depends, i guess that if you count only the time it takes for the xfree server to do simple blitting it should be about the same, if you add the client/server lag, for example the time it takes from generating an event(s) such as using the mouse to resize a window, then directfb should be faster. Also xfree would be much slower doing stuff like transparent blitting and such.
2> possibly transparent windows
-yep. ARGB color modes are not x11 forte.
3> easier resize/rotate
-doesn’t really matter.
Cons:
1> Loss of remote control,
-xdirectfb
2> More code in the kernel to be maintained
-the only thing in the kernel is the framebuffer driver, wich you probably already have running.
3> When the Graphics driver crashes, it takes the whole machine with it as opposed just X
-the graphics driver isn’t in the kernel, only the framebuffer driver.
You have some valid points, but let me answer one of them.
3> When the Graphics driver crashes, it takes the whole machine with it as opposed just X
From the perspective of any casual computer (desktop) user, if the graphics system crashes, the whole system might as well have crashed.
I think in the case of casual users (non-technical), the performance benefits out way the fact that only one part or another of the OS may crash. Casual users can’t tell the difference anyway.
Putting the graphics system is a great idea IMO. The GUI for most people is such an integrated part of the computing experience, that it just makes sense. Could you imagine a kernel that couldn’t store information on a hard disk?
Besides, this is OSS, and OSS is all about choice. You have the choice to continue using the painfully slow X11 (I know it isn’t technically slow, but it sure feels like it) or using the lightning fast DirectFB. I’ll be using DirectFB.
“From the perspective of any casual computer (desktop) user, if the graphics system crashes, the whole system might as well have crashed.”
Well, that’s not exactly true.
I remember once when X crashed for me, it would immediately restart itself en log me in and start all the apps i had running before the crash.
PS. I used XF864.3+KDM+KDE .DS
That’s cool that it restarted the DE and all your apps, but a casual user isn’t going to tolerate that either. It will still seem unstable, in the same way that XFree seems slow. It’s better to make it crash less, regardless if it is in the kernel or not. And if putting it in the kernel makes it feel faster, then I’m all for that.