Slashdot Mirror
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."
Now I guess we get to find out how much KDE assumes X11. Because there aren't many QT only apps out there.
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.
What's up with all the "Hot Babe" backgrounds? Makes all Open Source developers look like horny teenagers. Do you want a horny teenager writing your production Apache server??
The screenshot looks HOT!!! And oh, yeah, the desktop looks okay, too...I guess...
This is unlikly. The avarage X user (hell even the KDE fanactics) won't want to give up all the nice features of an X server. Who wants to use only QT applications? That cuts out most commerical software for linux, and most OSS.
This is most likely to help TrollTech in the embedded space.
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.
Boy, with that girl in the background, I about forgot to look at the transparency effects!
On a more serious note: this is good. Not that I want X replaced or anything, but a little copetition is always good. (Besides, why can't there be X-Free distro's and DirectFB distro's?)
...interesting if true.
Eugina has released some screenshots of the New Redhat Severn desktop.
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
Maybe it's just the nature of the post, but I looked at the DirectFB screenshots (on DirectFB.org), and I see everything from GNOME 2 to WindowMaker to the GIMP, translucency, etc., etc., while I've never heard of DirectFB before.
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!
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
one of my biggest issues with linux is that X is slow and bulky. You can compare it to any other major OS is terms of Memory footprint(which is bad) The Ability to run Qt and eventually all of KDE on DirectFB is great. Should also push other toolkits to this, or maybee to evas or something.
If I can get remote display and gtk I'll make a switch. But there's gotta be a distro that makes it easy, like Mandrake or something.
The GeekNights podcast is going strong. Listen!
Site is kinda slow... one, two, three, karma please?
I'd just like to point out that replacing X is pretty pointless, particular with a strictly less powerful infrastructure like DirectFB. Replacing XFree86 is another matter.
Please don't confuse X (a protocol specification) and XFree86 (an implementation of X).
X-less MythTV, here I come.
as people click on the link for the screenshots at http://linuz.sns.it/~monge/qt-directfb/story.html nerds everywhere do directly to google to search for more.... just like me :)
(no text)
Not being familiar with it, the first thing I did was read the FAQ:
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"?
For putting the bimbo shot in the screen shots. Now I can be fired for sexual harrassment for viewing this at work!
From here
What I'd like to see is GNUStep on DirectFB. There's no reason GNUStep on a 2 ghz PIII should run slower than NextStep on a 25mhz 68030.
A mirror of the site is here: http://www.madcowworld.com/qtfb/%257Emonge/qt-dire ctfb/index.html
I think this is a great thing for ones who argue that X is old and obsoulete. Go Trolltech!
The first sentence of the article no verb.
drinkypoo says this comment very amusing thanks ashcrow very funny comment missing several important parts of speech.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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/
Your opinion is fucking wrong. X is not bloated and it is not buggy.
Fuck you and lick dick.
Does anybody know how DirectFB handles key-input for languages other than US-english? Something like the stuff that gets configured with the "XkbLayout" and other similar options in the XF86Config file.
Does it use the keymap from the console, or is it just hardcoded to use US-english keyboard layouts?
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. Hey, don't snear at them. That was about the time that Intel almost went under...
If you're gonna advertise music, spell Rhythm right. Thanks to you, Neil Peart fans are now seen as raving idiots worse than Linkin Park's.
Alright, is it just me or do people only seem to use DirectFB for transparent GUIs?
Wait, looking closer ...
AND TETRIS!! Chicks and Tetris, what more do you need for a computer?
Though if I didn't know any better there might be a valid alternative to X real soon. All-in-all, looks good.
Ignore the "p2p is theft" trolls, they're just uninformed
you are just perpetuating mindless FUD about X. since YOU are making these statements about a need to chage X for something utterly untested and undeployed, YOU need to provide the hard evidence that there is a need to change. where are the numbers?
Oh bloody nonsense.
Every time I hear someone make this complaint that I've been able to physically go take a look at their system, I've found the bugginess and the bloat all right, but it's not in X.
It's in using miscompiled libraries, buggy bloated WMs, and the like.
You can run X on a 486 with decent performance, if you don't &*(% the thing up and saddle it with a bunch of useless crap.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Through looking and comparing DirectFB and Fresco/Berlin indepth and thoroughly, it is my expert opinion that Fresco/Berlin has much more potential for replacing X. If anyone is able to donate time to the Fresco/Berlin project I urge you to do so as soon as possible. X needs a replacement, and quickly, if Linux and other Open Source operating systems are to replace Microsoft Windows in the future.
Absolutely true -- I'm running X on a 25MHz 486SX with 8MB of RAM, and X is very responsive.
Can You Say Linux? I Knew That You Could.
"X is a really great system. Not perfect, but no system is. It's a shame you don't appreciate it, but if you want something else, feel free to build it and use it."
It's a Microsoft plot to trick us into giving up one of our advantages[1], and make us waste resources in making up an uneeded substitute[2].
Remember Sun Tzu: make your opponent think their strengths are weaknesses (The GPL is communist), and make your opponent waste resources fixing them. Clever.
[1] Windows can do it with external software, but boy does it cost. No wonder MS fanboys don't see the merits. It costs too much to find out.
[1a] Watch and see if MS doesn't incorperate such a capability in it's products. Then ask yourself why do that if it's such a bad feature?
[2] Any alternative, as already been discussed will have to solve some of the same problems X already does.
"You can run X on a 486 with decent performance, if you don't &*(% the thing up and saddle it with a bunch of useless crap."
useless crap like...a decent gui?
Amen to that. I run X on my 486-75 laptop with 24Mb RAM without a hitch. It runs Opera, gvim, GAIM at the same time without lag or hitches. Of course, I'm using Fluxbox (I even run that on my Duron 1300 with 512Mb) which lightens up the load a bit.
X runs fine - it's all the other little trinkets that people love to add which slows the whole machine down.
she was a blight on the beos community back in the day, and now is trying to extend her moronic drivel into linux.
this is the woman that whined about upcoming releases of beos not having support for more than 8 cpu's or more than 4 gigs of ram, when be had minor things like device drivers for common video cards (and a shitty network stack) to take care of.
please ignore this stupid bitch, lest she believe people actually care about her opinion.
X is available as a feature on DirectFB- it's called XDirectFB.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I think GDK is a replacement for XLib (draw line here; draw pixmap there), and GTK is all the higher level stuff (draw button here and hook it to this function; draw and operate spinbox there).
From the SCO website:
"Caldera Systems, Inc. is a Canopy Group holding under the Ray Noorda/Canopy Group Investment Company. Ray Noorda is the former CEO of Novell, Inc. (NASDAQ:NOVL)"
And from the TrollTech site, you can see Canopy, along with SCO group own about 6% of trolltech too.
Take a look at the Canopy group main website and be sure to not patronize any of their other 20 or so "Portfolio Companies" like me.
Go to heck SCO and the VC you rode in on too.
Wax on, wax off baby!
Now you, too, can run an unaccelerated window system (Qt+DirectFB) that runs only a tiny fraction of the software that runs on X11, has much less functionality, and that requires you to pay big bucks to Troll Tech in order to develop commercial apps.
With brilliant ideas like that in the free software community, who needs enemies like Bill Gates trying to kill Linux on the desktop?
That was sarcasm? I hope so.
The idea of saving the network abstraction layer of X "till you NEED it" is flawed. If we design all of our applications without it, then when the occasion comes up (for some it may be rare, but I use it every day) it will be too much trouble to retrofit those applications to have X support. But if you assume X all the time, then you can gaurantee it'll be there when you need it.
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?)).
Isn't that what Fresco is supposed to become?
The GTK on DirectFB project can be found at:
www.directfb.org/gtk.xml
The screenshots look similarly nice, but unfortunatley without any additional eye candy in tight t-shirts.
I had also read a month or so ago that work is underway to port the gnome libraries over to DirectFB. If I remember correctly, because of the extensive use of the gdk library in Gnome, there weren't too many Gnome libraries that still depend on X. However, it still probably won't be trivial to convert the remaining ones, or it would have already been done.
Since I'm sure we're all busy folks, let me save everyone some time by summarizing what this whole discussion is going to boil down to:
The screenshots are great, the technology is cool, but the one thing that prevents the free desktop to come true on the machine of Average Joe is the lack of applications.
Changeing the direction of the graphics environment right now isn't productive. It will delay the common use of Linux/FreeBSD on the desktop. As applications will need to be ported to the new system, instead of using that developer effort to produce new and better applications.
Perhaps even that killer app that makes the difference.
One other thing, one of the the most attractive features in the X11 desktop to corporate user is the remote display facilities. This is a major advantage over windows. It makes system administration a lot cheaper as application can be installed in one place. The admin cost is much more important to this group than the cost of hardware. Even if they needed twice as fast/memoryrich hardware to get the same performance on X11 they would prefer X11.
Once free software have higher market penetration on the Desktop we can change to better technology. But first we need to kill the competition from MS and Apple. X11 is good enough to do that, especially since the average desktop PC gets more and more memory and processing power.
The technology could still prove interesting for emedded devices where memory and processing power constraints still are more common.
God is REAL! Unless explicitly declared INTEGER
1) As many have said over and over, XFree86 is not slow. It runs great on a 486. Try using a faster WM.
2) Transparancy/hardware rendering. For some reason people think XFree86 needs to be tossed out completely in order to get this. Check out this interview statement from David Dawes (XFree86 developer):
David Dawes: There has been some work on a new rendering model for XFree86 that provides some more advance composition techniques (including transparency), this currently being implemented in software. For XFree86 5.0 we'll be investigating this as part of our review of rendering models, and seeing if a hardware implementation would not be more appropriate.
----
All of whose base are belong to the what-now?
Wow nice job.
I first ran X on a 386, 25Mhz I think? It was from before they started making SXs. I wouldn't call the thing responsive, but hell nothing outside DOS/Console mode was... it worked well enough.
The 486 I was referring to in my post was a clock tripled 33DX (DX100 they called it, but it wasn't, a real DX100 is a clock doubled 50 and boy are those hard to find - not many were made because not many MBs back then could really handle the 50Mhz bus) with 16 megs of ram. It ran quite well, but for your setup I imagine you must be a little more stripped down... fluxbox?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
yea, like anything more featureful/pretty than twm or fvwm2.
Since you haven't said exactly what is bloated and buggy with XFree86, nor stated why Windows 95 is a better GUI than any other X GUI, I'll assume you're just talking out your arse.
But rather than just flame, I'll present you with some reasons why you *perceive* Windows to be better.
A) Everyone tells you it's faster. Don't laugh this one off! The average human being rivals the cow when it comes to peer pressure. I've done some tests on my dual boot Win2k/FreeBSD machine. FreeBSD with KDE can do from powerup to surfing slashdot with Konqueror in 45 seconds, while powering up under Win2k to surfing Slashdot under Internet Exploder takes 60 seconds.
B) At work we're taking a i486 embedded device running X11R5 (R5 mind you!) and redesigning it from scratch to run WinXP Embedded on a 1Ghz P4. The new system *HAS* to use DirectX, because win32 is too damn slow. It does not have the performance that the i486/X11R5 has. They can't draw realtime *labels* and *graphs* faster than 15fps without it.
C) But that's speed. There can be a noticable response difference between the two, especially if your distro was asleep at the wheel when it came to default X settings. Why is Win95 more responsive than KDE or GNOME? Because the Win95 GUI DOESN'T DO ANYTHING! Even vanilla Blackbox has a higher feature set then it does! The win95 desktop can't even handle a jpg background without resorting to an ActiveDesktop hack, but most X window managers can use any image format you throw it at, and will scale the image without aliasing to boot.
D) A Qt application is no slower or less responsive under XFree86 than the same Qt application recompiled for win32. Try it and see! In fact, the only GTK+ application I use under Windows is *slower* than its XFree86 counterpart (GIMP).
E) If you see a significant performance increase under Win95/2k/XP, it's because it's an ActiveX application. It's bypassing the GUI completely. Please reread the previous sentence and attempt to comprehend it. See my note under B. We had to use ActiveX in our project because the WinXP GUI is too slow. Linux/BSD needs an ActiveX analogue, true, but that's no reason to dump X completely. Sometimes when you're playing Quake and feeling l33t because you're using Linus instead of Windows, then you want a good direct rendering engine. But it's completely pointless when you're running Scribus or GIMP. Perhaps DirectFB can fill this role for the times it's needed.
A Government Is a Body of People, Usually Notably Ungoverned
So it's not a replacement in the strict sense (because you can't do away with XLib), but you're correct in the sense that it does the low level stuff for GTK.
. . .
Never mind.
Well, there's spam egg sausage and spam, that's not got much spam in it.
It's not insightful at all.
True, there are maybe a dozen teens around the world who are capable of writing code worthy of Apache, but those are exceptions.
Treating exceptions as some sort of rule is not insightful.
I don't care how motivated or energetic you were as a teen -- you just didn't have the experience to write really good code. If you can't see the difference, you still haven't got it.
No, muLinux with fvwm95. The distribution is an amazing collection of tight packages, scripted equivalents and even hand coded assembly language replacement utilities. It really is responsive (much more so than my Pentium-133 with 80MB RAM running a minimal Redhat 9 with X (used as an X-terminal, no local wm or apps). Picking the right tools really makes all the difference.
Can You Say Linux? I Knew That You Could.
X in itself is very fast and pretty slick. Try yourself by kicking gnome/kde and trying OpenBox or some other fast WM. The difference on slower machines is pretty big.
I have a feeling that some n00bs confuse X with their Window Manager and Docks and Panels etc.
HTTP/1.1 400
I never really understood why people thought transparent windows were so cool.
Now I understand why it should be a priority 1 feature in all applications.
I've played around a bit with DirectFB and I think it has the potential to be a really slick solution for some users/applications. The problem I've had is that I have a widescreen display and I've yet to get any of the Linux FB drivers to display in its native resolution. I've tried the various formulas to figure out which numbers to use, but I've never gotten it working. Has anyone been able to use DirectFB on a widescreen display?
I hate it when opaque windows block my view of Anna Falchi. Finally, with DirectFB, my work-related windows won't block the important stuff!
Free also means liberated, asshat.
The problem is The Clipboard (Drag And Drop, Cut and Paste Etc). It only does text! I can't cut and paste from Gimp to Open Office or Mozilla to Open Office. Here we have the two most important linux desktop application and dragging a gif from mozilla to open office doesn't work. It's just text!
I know this would be tough to implement with X Remote desktop since two applications being displayed on your X Server might be on different machines but can't we set up a drag and drop daemon on each machine that lets them talk to each other so open office on machine a could except some paste information from the machine that was running Mozilla via a xclient to xclient connection or from a low level cut and paste service that communicated from server to server? Anyway.. I hope somebody in KDE or Gnome land is listening here.
Check out the Freesco windowing system. It does exactly this, plus more.
um. actually X selections are more powerful than other systems at allowing cut-n-paste and drag-n-drop of non-text. X selections let the pastee and paster negotiate on a prefered file format based on what they have to offer and what they can accept.
Just because people who write apps for X don't seem to use this functionality, don't blame X11. if the app writers are too lazy to use the power of X selections, I don't see why they would suddenly for some new system.
http://notanumber.net/
maybe win95 was not the best comparison of a GUI
but beos is
jpegs and ANYTHING else with a handler driver works fast and flawlessly (although you could say that just uses the replicant "hack") and beos 4.5 + opera 4 = 25s or less (max 15s boot and 10s opera load) to read slashdot on a p150.
oh and on windows i see HUGE performance diffrences that aren't from activex, they are from FrameBuffering! (playing video - at least on my system)
now for what IS bloated and buggy about XFree86. The config files and driver support. i don't mean specific card support witch is understandable, i mean simple auto vesa support. those problems have caused 99% of my gripes about linux.
points
-I have used 4 diffrent distro's
a really old slackware
mandrake
redhat 5 and 8
and gentoo - fully compiled for my processor with VERY little bloat (only XFree86)
-i have used gnome and kde.
-I like OSS - almost every program i use regualrly is OSS.
Jot used to fail because it would request an X extension (OpenGL) that nobody else had. You could add OpenGL to your X server, and Jot would run just fine.
Of course, you had to find an OpenGL X server first...
Especially in companies. At most places in companies where unix/linux is used, it is used by servers and thin clients. The network transparency is absolutely crucial. Even MSFT tried to add it to its GUI using terminal server.
Also at home it is useful to many. All the people I know that run linux or freebsd at home (except those that just try it out occasionally) have a linux or freebsd server and a windows or linux/freebsd desktop. Most apps are run through X, just 1 or 2 games that need more speed are run locally.
I think everyone how "grew up" on unix uses it this way. Only people that grew up on windows and just recently moved to linux are used to setting things up so that all interactive apps run directly on the desktop.
I wonder where this myth of X being lightweight came from. Have you ever performed a trace on what gets sent over the network? Well I did - printing out the trace of just the solaris login screen (completely black except for the dialog box in the middle) is over 96 PAGES LONG!
And let's not get started on security shall we? It is quite possible that, once you get permission to connect, you can choose to randomly kill any window of any client by just dishing out the ID.
You know you've got problems when RDP gets called ultra light and works much more reliably.
Technologically, an X terminal is just a computer that runs a X server, and nothing else. Was there ever a time when such a system was drastically cheaper than commodity computers? Without a good price advantage, X terminals didn't make economic sense. I can only think of one other excuse for them: the assumption that applications would always be run on a shared system. I suspect a lot of IS people would be a lot happier if that were true -- it would save them always having to fix systems screwed up by too-clever users.
Very offtopic, but worth knowing. Although I usually prefer a network share via samba or NFS. The ancient Unixian in me wants everything to be "just a file"!
The whole idea beyond "replacing X with something"
is an idea to replace network transparent GUI
protocol which suits perfectly for multiuser
environments with something which is only able
to display only programs which run locally.
Of course, KDE and GNOME developers done much work
to dumb full-featured OS down to something windows-like, but nobody forces you to use this bullshit.
Even microsoft realizes that computers are not
meant to be personal. They included terminal service into XP Prof. It took them nearly 20 years
to reinvent great MIT invention.
If we want average dumb user
to be happy and productive with his desktop, we
need smart admin lurking around. Preferably behind
the scenes, and without disturbing user and dragging him away from the keyboard.
Of course, there are handhelds and other such nifty gadgets. But wait a bit. I remember times
where hard disk of average desktop computer was
smaller than memory of present day Zaurus (it was
20Mb).
Of course, there are few problems with bandwidth
of wireless networks. I doubt that someone would
be happy running X over GSM 9600 baud or even GPRS, but 3G cellular networks are on the way.
just like the UNIX underneath.
Personally, I consider the true multi-user nature of UNIX systems to be their greatest strength.
Getting rid of X means giving that up. It also means making our OS just like the other multi-tasking, but not mulit-user ones out there.
It is just not worth it.
I use X every day. For gaming, remote support, and various other things. The current XFree works better than any other X server I have used.
Look at OS X. It has a frame buffer. It also can have a rootless X server. All the apps for the machine target the frame buffer. None of them work well over the network.
Sure you have VNC, but that just moves the ONE desktop around.
In an X environment, you get to move anything anywhere you want to. This is where the strength of UNIX is.
Multi-user computing is valuable. It makes older hardware continue to be useful. It also allows for different computing models and resource usage.
The other Operating systems do not do this. Linux / UNIX does and it is our killer feature.
What happens when a win32 server has trouble? You get a few admins looking at the machine while one operates it. With UNIX, you get a few admins all poking at the machine at the same time working together to work through the problem!
X is not slow. DRI has fixed the 3D part of things. 2D has always been fast. The transparent windows are nice, but do we really need them more than we need to continue to build on the software base we have now?
Look at Open Office. It runs nicely over X. One machine can serve many others. Install one copy of the software, setup the environment for the end-users once and you are done! No local installs, no hassle. Upgrade once and everybody is done.
If we do a frame buffer, it needs to be truely multi-user or it is not work doing. VNC is not the same as remote application display.
For those who say most people do not use the features of X, I say you are right. Why? It's because they don't know better, not because the tech sucks.
I have several machines that all perform their various functions. Some are Linux, some are IRIX and one other one is win2k. On my Linux desktop, the IRIX and Linux are perfectly intergrated. All the machines act as one. The odd man out is win2k. I have to bring up a silly VNC window for it.
Things are getting faster in a hurry folks. X is there already. The toolkits and window managers and desktop stuff is progressing nicely.
Choice is a big part of what OSS is all about. X provides more choice and power than any other display system ever has. That is why it is still around. That is also why it should stay.
Anyone who really wants to replace X does not understand just what it does. They just want the simple system their old OS had without realizing it is part of the problem.
Blogging because I can...
Problem not in X, but apps you are using.
You are citing names of modern things with windows-like concepts built in it - GIMP, OO, Mozilla. Their authors never take a pain to read
ICCCM specification.
Really there are protocols to negotiate any selection format between two applications.
There is some good thinks which appear last five
years like xdnd.
But while people would still use Qt and Gtk
in preference to older and more mature toolkits
like Motif/Lesstiff or Tk, nothing really good is going to happen.
First of all, DirectFB is an interface that abstracts the hardware drawing capabilities (and with a window system thrown in for free). DirectFB can't replace the whole XFree86, because the XFree86 is a whole suite of software, including many apps and libraries. The only thing that can be replaced is the window mechanism...that means an XLib implementation for DirectFB.
Secondly, why so much fuss about transparency ? take a look at the screenshots. All windows are transparent, making the display an ugly mess. I don't need transparency to do my work. It's difficult to understand what is happening on the screen.
Look at the fonts (especially on the Tetris window). They are ugly. Instead of transparency, I want good fonts and a good font rendering subsystem. I've got Redhat 9, and the HTML font rendering sucks in all browsers (Mozilla, Nautilus, etc) when compared to Windows.
Thirdly, a while ago somebody told me (here on Slashdot), that in XFree86 there is a direct XLib (which uses no networking) when the app is local. Is this true ? please confirm.
Forthly, the widget set is ugly. If you take out the pretty background (which really distracts from noticing the gui), you will see that widgets are simple 3d rectangles. This is an ugly gui, simply too much Windows 95. The world has seen many beautiful guis from 1995. Of course, this being Qt, is not really a problem, since it can be skinned.
The problem with Linux is not the XFree86. It is the intergration with the system. For example, under the default workstation installation for Red Hat 9, if I try to copy a file to a directory that only root has rights to write to, the GUI says : "nope, you can't do that. Try the command line instead". If I install a new icon on the desktop, I can't later change it. Instead I have to delete it, and create a new one. Back to the command line then.
Look at all those Gnome or KDE menus. Lot's of stuff cramped together in a tiny space, with lots of weird names. Is this a good gui ? nope. Is it a fault of XFree86 ? not at all (well, except for the fonts). It is much a problem of designing guis, and the simple fact that geeks can't design good guis.
Lastly, the world must forget about pixels. We need a library that deals with the screen in terms of points, not pixels, using an arbitrary user defined resolution. We need a gui that:
1) can look the same independent of the screen resolution
2) is consistent through out all applications
3) provides access to most stored information with a few clicks
I've always wanted faster 2D performance in Linux - it's one of those things that makes the desktop feel nicer to use. But I can't find many benchmarks of directFB vs X. Apart from this
Which is just on the Matrox G400, which isn't that common a card. Are there more? If not, why not publish an extensive list of benchmarks with many cards and settle the X performance question?
Anna Flalabalalooy isn't really my type. I won't run this until it has Alyson Hannigan on the desktop.
Clearly you don't play quake much.
Quake over a dumb terminal utterly sucks, and it doesn't take someone without a rudimentary understanding of the way X works to figure out why.
I don't want to have to "download" each frame of animation over the network, I want my graphics card to render it directly and as fast as possible thankyouverymuch.
And when it gets round to coding this stuff, I want the ability to talk to my graphics card's vertex shaders to make this as pretty as possible.
And I want the ability to put the whole thing in a window on my desktop.
Sorry X.
There's no reason why X can't be a library ON TOP of DirectFB, which is kind of the point people are trying to make.
It has some really good points and facts, more than it's parent.
Yessssssss
"write apps for X don't seem to use this functionality, don't blame X11"
People don't use it cause it was badly designed...
Well I'll have to say that processor speed is not everything, nor amount of RAM.
,16MB DRAM and 256 cache, other had Matrix Millenium,32Mb EDO and 512kb of cache.
My tweaked 33mhz 486 with 8MB of ram ran circles around my friends 66mhz 486's.
[description]
One experience of doom was choppy. Another had other slowdowns.
Duke that supposed to need 66mhz 486 ran just fine. And with several other games had similar experiences.
[reasons.]
Fast gfx, large low latency L2 cache, high quality DRAM chips. And carefully selecting drivers which to put for maximum performance.
Another example, 100mhz pentium vs 133mhz pentium, difference in quake frame rates 100%. [software rendering, both had similar optimizations from software side.]
One had S3 vision
Neither of system, did any paging during tests.
Software tricks are also important. Himem.sys and emm386:s features selected on application basis meant a LOT.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
256 MB of Video RAM on graphics card = X server will appear to be at least 256MB in size under top.
That is why X seems to be so big and bloated when running.
Realise that X was originally developed on a DEC machine with 2 MB (thats TWO MEGA BYTES) of RAM in total. That is why they haven't had too much trouble porting X onto PDAs with a total of 8 MB of RAM.
I really like X - I prefer to even use twm to windows, but the furthur accross platforms apps stretch the better. My job would be very difficult without *nix apps ported to windows (eg. putty (ssh) and vi), and the more apps that can run on embedded systems the better. Having a web server on a photocopier is a very useful thing, and as more apps are ported things will only get better.
Actually, you can do away with XLib. The XCB and XCL projects are an attempt to replace XLib (XCB) and provide backwards compatibility (XCL), and are being taken pretty seriously by many in the X programming community. Rasterman (of Enlightenment fame) talks of his desire to move Enlightenment to XCB (an X C Binding) here
Which graphical toolkit do you think ActiveX controls use to draw their content?
Seriously.
You can run X on a 486 with decent performance, if you don't &*(% the thing up and saddle it with a bunch of useless crap.
The fact remains that Windows is still faster when saddled with all that useless crap, and at least as fast without it. Something needs to change (and it goes deeper than "don't run it, it's slow").
For anyone who doesn't understand why you would use anything other than X, take a look at ByzantineOS, which uses DirectFB for rendering in low powered Internet and home entertainment appliances.
Woopty Doo Basil, what does it all mean?!
I am perfectly happy with my GEM desktop, don't see the need for all this X nonsense anyway.
I would like to see a more secure, network transparent windowing system that uses the widgets on the display server and not the machine the application is running on. This way there would be consistant look and feel to the apps regardless of where they are running.
Personally, I would like see the GUI integrated into the kernel, with net transparency and compatiblity handled by daemons.
I have been talking about this in my journal
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
More secure is a good idea, but transport level
security (such as SSL or ssh-forwarding) handles
this.
As for "consistent look and feel", I think it is
most evil idea ever invented by proprietary software vendors.
Look and feel of the program should be consistent
with function of program, not with other programs
on the same desktop.
Of course, there might be advantages of having more complex protocol which operates on the widget level, rather than on the drawing primitives and
elementary events level, but I think that standartizing complex interprocess communications
as a layer above ICCCM, and audio input/output (for which we now have at least four competing standards) is much more important.
As for GUI integrated into kernel, there is nothing wrong with it on thin clients. Really,
for example NCD ECX X terminal uses one binary for
both kernels and X server. But if you have an application running on the machine, you should
avoid as much complexity in kernel as you could.
See microkernel systems linke QNX or HURD.
While alpha transparency is pretty, it really isn't much of a benefit for a user interface (i.e. communicating with the user).
Try running three different programs on three different machines and displaying them together on one screen with VNC.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Be aware that the memory on your video card shows up as memory used by X. Deduct that and you get the real RAM footprint.
I guess some obvious things coming from a windows gaming/game developer person (ok, "stone him" ;) are:
;)
:)
1, ability to go into "true fullscreen" - not just a window covering all of the screen. "Stop the rest of the world" approach (ya, if you're using your linux system as some kind of server in the background this is nothing for you - but I said I was interested in gaming
2, related to 1 - ability to change bpp and "screen size" dynamically, without requiring a restart of the X server.
Are any of this available or not? To my knowledge no, will it be available soon(tm)?
I guess the above two points should be taken care of a.s.a.p - then linux will truly be a better gaming platform than windows (imagine games written in java/"other platform indenpendent code" + opengl + openal running better on linux than the same game on windows! This could become a reality real soon with the new preemptible 2.5-6 kernel and some X server improvements
While the cosmetic appearance of programs is not vitally important, consistency does make them easier to use. For example, I use KDE with the MacOS style menu bar at the top of the screen. If I use Mozilla in KDE it doesn't follow the KDE style and I get two menu bars (mozilla's and the default KDE one). Confusing and a waste of screen space.
If a button always looks the same, if menu layout is always the same, using the GUI requires less thought. I can get on with using the computer, instead of having to waste brain power thinking about how to do things with the interface.
with function of program, not with other programs
on the same desktop.
I believe the programs look should be under the control of the user. How it is done, I don't really care.
As for the drawing level of comms, per haps I miscommunicated. I think the program should say "Draw this kind of thing here with this in it." as opposed to "Here is something I want you to show on the screen ."
I hope this clarifies things.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
actually X selections are more powerful than other systems at allowing cut-n-paste and drag-n-drop of non-text. X selections let the pastee and paster negotiate on a prefered file format based on what they have to offer and what they can accept.
Actually, Windows does the same thing, as does the Java drag-and-drop api.
You may be thinking of earlier Irix machines that used NeWS, which really did have the widgets on the server end. Unfortunatley this was almost unused and everybody used it's X emulation.
Microsoft is working very very hard right now on adding remote display to their interface. This is because it is vitally needed and they screwed up by making some assumptions (mostly about the instant delivery of PAINT events, and too many calls that programs assumme are synchronous) that are making this hard while remianing compatable. The remote display adds ZERO to the time it takes to draw anything, every single GDI call is a call into a library that can decide whether to draw locally or remotely (or perhaps you didn't notice that GDI can already redirect calls to your printer, which is a remote device) and this redirection requires no more code if there is a possible target that is remote.
Now the difficulty is that even though remote display is not a problem, X still sucks. The main reasons:
1. horrid graphics model that requires any modern interace appearance to draw locally and send bitmapped images to get the display they want.
2. Many many synchronous calls (calls that return values). Asynchronous calls can be inserted into a buffer and sent at once, resulting in a 1/1000 or so ratio of context switches to calls, which makes the arguments used by Windows to put graphics in the kernel (which changed the ratio from 2 to 1) look terrible. But synchronous calls completely ruin this, and huge numbers of them are needed, especially for all the kludges needed to talk to the desktop environments.
3. Window managers seperate from programs. This produces the most objectionable redisplay problems, the ones that are not solved even though machines have sped up 100's of times, since there can always be the lag of one program or the other being swapped out. The time has come for people to give up their beloved window managers and realize that these are widgets just like everything else and put them into the local toolkit. Also anybody who suggests that more widgets should be in the server is an idiot, it should be obvious this is a VERY VERY BAD idea if you just look at the problems with window managers.
The X clipboard protocol has only one huge technical problem, which is that it has a nasty complex interface so that "large" blocks can be copied (this was designed back when it was common to cut a piece of data larger than the memory on the X server, this is probably not true today), and typical X stupidity of not adding a modern call which hides this silly and obsolete interface. Otherwise the X protocol is exactly equivalent to what Windows has, with the advantage that there are more than one clipboard and that it was designed from the start to defer the communication of the data until the paste request comes (Windows was forced to kludge this on).
However the real problem is that while both X and Windows had a symbol that indicated the "type" of the data, Windows went through the simple step of assigning some predefined types. The X people instead felt that should be left to the programmers. The end result is that we have about 10 ways of cutting/pasting text (I know I have seen them all in an attempt to accept UTF-8 pasting) and no defined symbols that mean anything else. Meanwhile Windows went and said the number 10 (or something) means a .bmp file, and despite the fact that that format is terrible and inefficient, at least it allowed a picture to be sent and all the software agrees it is a picture!
In any case both are obsolete. What we really need is and interface that sends UTF-8 text and UTF-8 encoded arbitrary URL's. An image would actually be sent by writing it (hopefully to a temporary filesystem) and sending a URL to it. Since all programs probably know how to read/write their own data to files, this would allow them to communicate clipboard data with little extra code. Also it provides a human-readable fallback when the data cannot be interpreted.
"Consistent user interface" is a fraud being thrown at us as a way to prevent programs from exploring new interface ideas and prevent systems from being designed where it is possible to program at low levels so that programs can be easily ported between completely different low-level implementations.
People once believed that database queries and record structures had to be understood by the base filesystem, or else programs would never be able to share files (take a look at VMS and the "pip" programs). Fortunatley the plain filesystems of Multics/Unix showed this to not only be false, but actually completely the opposite of what was true, and now we have programs that can read/write files on every operating system in the world and written by every other program, we have disks that are a MILLION times larger than the disks in use when the filesystem interface was designed but the programs can still use them, and we can transparenlty read/write files over a network that was not even imagined in 1970.
Yet 30 years later GUI design is still held down by a bunch of people who think that the idea of "menu" should be built into the operating system. Lets learn from what worked for filesystems, everybody!
I am not an expert here but here are a few of my findings...
/Windows XP box and I can say that they feel about the same in terms of speed - Its a 750mhz Duron, on a 1200 Duron XP feels a lot snapier (haven't tested KDE on this setup...)
1) I have a dual boot Mandrake 9.1 - KDE
2) X may not be as bulky as you think - I was when I first started using system monitors alarmed at how much memory was being used - my resource meter did in fact reveal that most of this memory was being used by x (hundreds of Megs) however I tried the following.... With nearly all my ram in use I started opening many large documents in the GIMP - X gave back the memory gracefully and no swap space was used... Indicating that the memory was only been taken by X because it wasn't in use elsewhere...
3) I have heard that a lot of the percieved problems with X comes from poor usage of XLib - can anybody confirm, denie or go into detail on this topic.
With the latest stable XFree / fontconfig / freetype, my fonts look *much* better on my Gentoo box than on any windows box I've seen. I have a crappy CRT, and I'm running at 1024x768 ATM, the text is absolutely perfect.
I believe the programs look should be under the control of the user. How it is done, I don't really care.
."
It is good point. Problem is there is too much things to control. Users want computers to just do the job, and balance between flexibility and time
to spend either tuning things up to your preferences or learning how to use things which cannot be tuned is very complicated thing.
As for the drawing level of comms, per haps I miscommunicated. I think the program should say "Draw this kind of thing here with this in it." as opposed to "Here is something I want you to show on the screen
Problem of "miscommunication" sits in the definiton of thing or something.
X takes consistent approach, defining set of primitives such as windows, drawing primitives fonts etc, which can be used in communication protocol.
It is possible to extend this set, using common controls such as buttosn as "terms" in communication.
But I cannot see the difference between draw this thing and I want this thing to be shown. All user interface systems use event loop which makes updates on the screen only when there is no user input to process. Curses does so, X does so, Win32 does so.
BTW, why do you disable comments on your "Modern OS" Journal entries? There are few points which I'd like to comment.
I have comments enabled. I do not know why you can not post to it. I will investigate. I am interested in your opinions.
But I cannot see the difference between draw this thing and I want this thing to be shown.
I am referring to what gets passed over a network connection. I think the appication should not contain the actual thing to be displayed, but rather just enough information for the server use its primitive, widgets, etc to display the information.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
I am referring to what gets passed over a network connection. I think the appication should not contain the actual thing to be displayed, but rather just enough information for the server use its primitive, widgets, etc to display the information.
Things to be displayed may vary.
For instance, consider a photo of nice kitten to be displayed in graphics editor. Obvoisly, it cannot be contained in GUI subsystem, and should be passed over network connection.
There is limited number of things which could be
stored in X server. On NCD ECX there is only four
megabytes of memory to run X server in.
How should you know that particular interface element is a standard thing, not a "kitten photo".
Applications may need custom controls like dials
or draggable graphs.
Of course, there are things like font, which can
be requested by X server on demand.
It is interesting idea to convert widget library
into separate server, like font server and provide some contorl cache in X server.
Yes, but what about toolbars, menu bars, dialog boxes, menu lists, etc.? These are items that can be standardized and/or abstracted so that the widget can be local to the server.
There is limited number of things which could be stored in X server. On NCD ECX there is only four megabytes of memory to run X server in.
This is the exact reason for discussing a replacement of X for certain devices. X serves a purpose. Rather than scrap X, write something new and different that can interoperate with X but supports newer and different features.
How should you know that particular interface element is a standard thing, not a "kitten photo". Applications may need custom controls like dials or draggable graphs.
Good question. I am not sure. I suppose it would work like thus for a PNG of a kitten displayed at 240x420 in a window by itself:
encoded for transmission. The display server would handle creation, location and display of the window with the picture in it. For an something like a word processing program, the display server would handle the standard widgets and creation and location of the windows, popups etc. The actually content of the window would be handled at the appliation level. For custom widgets, there are a number of ways to do it from the current method used by X to something akin to ActiveX controls used by windows. It is an implementation detail that can be discussed at length later. This is more of brainstorming thing.It is interesting idea to convert widget library into separate server, like font server and provide some contorl cache in X server.
This is an interesting idea. I have not considered it, but it may be worth exploring further. Do you have any further ideas on it?
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Yes, but what about toolbars, menu bars, dialog boxes, menu lists, etc.? These are items that can be standardized and/or abstracted so that the widget can be local to the server.
Toolbars are essentially collections of
images with commands bound to mouse event. There is nothing to standartize.
Menus are strange animals. Menus in Windows are very limited (becouse they ARE standartized) but in mosu X toolkits (like Tk or even Gtk) menus are much more flexible. They can contain checkboxes, radiobuttons, handle dynamic shortcut assignments etc. It is better to leave this functionality to application.
As to dialog boxes, it seems that you never tried to design informative and useful dialog box. It is art.
There is layout problems (especially if user is allowed to change fonts, which is required by accessability, or text strings vary according to current locale, which is required by i18n), which is handled by complex geometry management algorithms, which obvoisly belong to application, there is various application specific validation routines which handle input or movement of focus between controls, there is order of focus movement which should be controlled by application because it depends on semantic.
Good question. I am not sure. I suppose it would work like thus for a PNG of a kitten displayed at 240x420 in a window by itself:
GraphicFame:PNG:240x420:
You'll be surprised, but your suggestion is very close to one of real X protocol events. With only difference that you are requiring display server to know about various graphic formats like PNG, and X requires apps to convert all images it wish to display into X Pixmap format.
There is good reasons to handle it. First it makes possible to application to decide what to do if there is not enough colors. Consider map of states where states are colored in different color and photo of kitten. If display is unable to handle all colors required by on-disk representation of image, first image should have each solid color region filled by any available solid color, which is visualy different from its neighbours, and second needs dithering.
Second, and more important - application seldom needs to display images as they are stored on disk. It scales them or cuts them. So, it have to decompress them into raw array of pixels before displaying anyway, so it doesn't make sense to use variety of formats to send them further. It is just as easy to convert this raw array of pixels into standard format.
For custom widgets, there are a number of ways to do it from the current method used by X to something akin to ActiveX controls used by windows.
You seems to be completely ignorant on this problem. How awful! Active X is Windows specific thing. And we are talking about real computers here, not a brain-dead personal ones.
At my home I have local X server which runs on Linux PC, NCD ECX , which has Motorola 68020 processor and HP X terminal which has i960.
With current state of X it doesn't matter on which of them I start an application. It just works if it has enough colors and pixels to work.
If X applications would want to run custom code inside these X servers, I would need to keep three copies of each custom control. Note that Java is not an option here, becouse X terminals typically has 4-16Mb of RAM and have better uses for it than to run JVM. Also Java is awfully slow.
I'd rather say that with all those GLX, Xkb and antialiased fonts X servers grow too large nowadays, and we have to restrict their functionality to achieve compactness and speed, not to extend it.
One of reasons why I think that personal computers are brain-deed and thing invented by evil vendors is endless upgrade cycle. My X terminals are about 10 years old both, and they serve their purpose perfectly.
I need to upgrade only main machine, where apps are run. And becouse I run free software on it, I don't need to do it to often,
With your suggestion terminals would need to be upgraded as well as computers, to cope with newer and more bloated custom controls libraries, which would benefit only hardware vendors.
I am talking about a non-exsistant system that would replace X-windows (and possibly GNU/Linux) on personal computers. It could have X compatiblity, but not necessarily need it.
X is good for what it is good for and I don't want to replace X in all situations, just, maybe, possibly in one.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
We both discuss common general thing - how GUI,
which is used by average user to interact with computers should work.
You are thinking that personal computers are acceptable, but X window should be replaced.
I think that X window is acceptable, moreover, it is only existing example of usable GUI system, but concept of personal computers is not.
Points I'm insisting on
should not bother with technical issues. There should be guy, which logins on the computer where user's apps run, and fixes problems when they arise. Just as average car owner drives this car to service to have engine checked by qualified mechanic. Because computers are not able to drive, but they are able to let people login from network, system, where everage user runs his apps, should allow logins from network.
There were no significant improvement in display technology last 10 years and in keyboard technology last 20 years. And possible would never be. I.e. I cannot see why one should use 200dpi screen to read one's e-mail, while 100dpi one does the job. So, window system should be designed such way that it doesn't need to change when applications changes.
*nix like systems with X window almost fits these criteria. So we should talk about improving X windows and manufacturing cheap X terminals with some 200Mhz processors like ARM or Dragonball. No fans, no disks, etc. You cannot imagine how absolutely silent device could improve your productivity. Entire logic should fit on the small board of size of network card which should be built directly into display. Couple of USB connectors to attach your digital camera or PDA would be nice of course.
Here is a link to Linus's thoughts on this:
h tml
http://www.ggi-project.org/mailinglist/may99/320.
It is your personal duty to fight for what is right on a daily basis. Ignoring injustice is identical to approving
Exactly, X11 application developers are lazy. Being one of them, I can confidently say that nobody really wants to bother implementing drag-and-drop or cut-and-paste. I wouldn't bother in a Windows application, either, actually. It's just too much hassle for me. I personally never use drag-and-drop anyway, prefering the control and certainty of cut-and-paste, but whatever.
The reason why it's more common on Windows and Macintosh programs is that the developers on these platforms pay more attention to end user usability and platform UI guides. To start off, *nix doesn't even have platform UI guides. And as anyone can tell you, *nix applications prefer to be powerful and flexible over "user friendly", especially open source projects which generally only implement the "interesting" functionality.
So, yeah. Blame the X11 client programmers.