Slashdot Mirror
freedesktop.org xlibs 1.0 Released
Daniel Stone writes "A short time ago, freedesktop.org xlibs 1.0 was released. Simply put, this is the collection of libX11, libXext, and other little-used libraries that kind of power your whole desktop. The xlibs team at fd.o are now maintaining all these libraries, and more, and we're going to be making releases as part of the fd.o platform, which is far more wide-ranging, but it still forms an important part of the platform. Share and enjoy!"
I want 2 b spoder man:(
It's fun! Please try it.
What is your definition of "Doesn't depend on"?
They both use xlib exclusively for drawing!
QT (and possibly GTK) exists in a version for embedding/framebuffer devices, but that's not the version you see in everyday KDE/Gnome.
With great numbers come great responsibility!
still use non-bloated window managers like WindowMaker, Blackbox, IceWM, and Enlightenment that don't use the GTK/QT libraries.
No one uses Xlib, thats the problem with the X development team. They waste time reinventing the wheel over and over. We don't need cairo. we don't need Xlib, we don't need to switch to this stupid open GL interface bloated crap.
Virtually every toolkit out there uses xlib. It really isn't
"little used", but rather key part of the whole *nix desktop.
... but having one group looking after all these libs would seem to offer some scope for optimisation and consolidation. Sounds like a good thing...
What's the DBUS ? (Desktop bus ?)
Simon
Physicists get Hadrons!
And X is NOT slow. For what it does, it does it quite efficiently, and it even has network transparancy thrown in for "free", because of the way it works. Just because the code base of XFree86 is a bit aged and has accumulated a lot of cruft over the years, doesn't mean the initial design is flawed. It was ahead of it's time, and it's still relevant.
Oh, and X works pretty good for me. Haven't seen a crash because of X in years. Maybe it's something else (buggy driver? broken hardware?) that's plagueing you. It's not X, in any case.
Ok how can they be litle used and yet power my whole desktop? I'm confused.
XFree86 Has Not Merged With X.Org (see News)
[23 January 2004] http://www.xfree86.org/
So have they merged or not merged?
Why is this a "troll"? Offtopic, perhaps marginally - but a troll? Please, don't be silly.
You say X crashes twice a week? How bizzarre - perhaps you have hardware problems. I use X all day every day and I can't remember it ever crashing.
Is there any chance of this desktop being used on a distribution small enough for a credit card sized CD? 50MB.
From the site:
This table represents the state of libs from XFree86 that should be brought into the Freedesktop cvs as autofooed projects. Please update these if you have any further information.
Library current status
GL needs to be done
GLU FreeGlu? may be better? (don't think so, and Mesa should have the same libGLU available --EricAnholt)
GLw
XThrStub? would be part of libX11, but may be better not as a separate library
XTrap
Xaw6
Xbsd
Xfontcache
Xft1 Maybe do not need this
Xinerama Multiscreen unified display
Xp X print
Xss X screen saver A newer smarter version of this may be nice
Xtst
XvMC?
Xxf86dga Probably does not need to be done.
Xxf86misc getting and setting of input device attributes possible ideas for better device handling
Xxf86rush
Xxf86vm VidMode? extension that allows modifying video attributes on the fly
apple
dps There may be a GNU package for this, but it may be old.
dpstk See dps
expat Should be depended upon
font
fontconfig
fontenc
freetype2 Should be depended upon
libxutil
libxml2 Should be depended upon
misc
oldX
psres See dps
regex
xkbfile
xkbui
zlib Should be depended upon
Saskboy's blog is good. 9 out of 10 dentists agree.
Don't forget to remove the line containing "killall X" in your crontab !
Xlib, what's it all about? Is it good, or is it whack?
One more question. Whats the diffrence between the freedesktop xlibs, and the xlibs in XFree86 ? I understand they forked from XFree at one point. What did they change/improve ?
It's a message queue for programs to take advantage of. Just a simple way to communicate between desktop applications. I think they're planning on using it in the Dashboard project.
True story.
as far as i know and have experienced... GDK, the lower API part of GTK+ is a thin wrapper for XLib. It provides you with basic drawing primitives also more or less available in Xlib but with less code. It also makes things easier.
Which is exactly what DCOP is. And guess what, it's not even tied to KDE and Qt. It's just bundled with KDE, and KDE depends on it. You could build dcop and use it in your apps without the need for KDE and Qt.
They use the xlibs to communicate with the X server. In simple terms, they provide a C interface to the X (and lots of releated X mechanisms) protocols.
I see very little of the slowness everyone trolls about, though if you want to improve it, one should implement some better redrawing algorithms in the toolkits. And write some better gfx card drivers. Though that is hard, graphics is hard. And vendors do seldom hand out hardware specs to everyone.
I believe BlackBox and FluxBox are both written on top of Xlib. I've hacked around with the source code a bit and Xlib looks pretty unwieldy. Good thing there's Gtk for all my application needs =)
True story.
I've used linux for years, but still get confused when people bring up this subject. I can't make heads or tails of all the different X's being bandied about. Half the time I can't tell if it's a group of people or a program.
X11, x.org, xfree86, X Consortium, X Window(s?), not to mention freedesktop.org which is commonly mentioned in the same breath - i'm sure i'm missing some.
I'm sure there's others that would appreciate an unscrambling of the relationships between the x's
Textbooks and Open Educational Resources
This is all political bollocks from Havoc. What do you expect?
Every single X program uses xlib directly or indirectly. So GTK always uses it, and QT uses it except when using a framebuffer directly or using some other underlying mechanism (like non-X11 Mac, IIRC).
Chances are that X isn't what's crashing for you, but rather some program running under X (unless you have hardware problems, a bad driver, a corrupted X server, or something like that). X is also generally quite fast, but most programs (such as any that use GTK or QT, except for really recent ones) use it extremely badly.
Actually, what is generally slow about X is that is doesn't have the drawing primitives that modern interfaces want to use, so they have to implement them inefficiently with the available primitives. Present development is helping to rectify this situation, however.
It IS modular, you idiot.
Actually, dBus is a very small bus. It get a full sized bus, you need to integrated it with Linux.
(Ya, Ya, I've got way too much calculus on my mind these days....)
Gdk easy versus Xlib? In your dreams. Have you ever tried raw Xlib? Gdk? Anything that uses gobject and the typical G-overengineering approach is awful.
And X is NOT slow.
He is right about X not being slow. The problem is the perception thats X is slow. X is what is visual to the user, users either blame KDE/Gnome or X.
Take a pre-emptive low latency linux kernel and run X on it, its like night and day, its smooth, fast, which proves its not X but the kernel.
Windows cheats and loads the gui extremely fast, but if you watch your hardrive light, and tool tray, you will noticed things are still being loaded in the background. The system is busy for a few more seconds. You can load an application, and it waits till after the services start.
So, X seems slow compared to other OS's.
1. Long delays to get into KDE/Gnome, and actually use the system.
2. Slow response on user input.
3. Multitasking, switching apps pause the system.
4. Loading directories in ICON/Image view takes longer than windows.
5. Lindows has everything running as Root for a speed boost.
I predict we will see pre-emptive, low lantency kernels as standard on Mandrake and Suse. Preemptive kernels are now standard on 2.6.x (well, if you check the box). And even more pre-linking to help boot time.
BSD has the same issues. Apple's X server does seem faster than both Linux & BSD. I'm only running window maker on it, so its not an exact match, but task switching and running gimp does seem more reponsive.
Could the answer be the mach kernel osx uses? Maybe we need a new suite of benchmarks for user interaction. (os+X+wm/etc).
-
I code in my SecondLife
From The DCOP site:
So DCOP does depend on Qt. Also, it is written in C++, whereas the GNOME libraries are almost always written in C (I'm not saying this is better, this is just how it's been done). Until DCOP doesn't depend on Qt and gets a binding to C, I see no reason why the GNOME project shouldn't pursue DBUS. (Had to post as AC because I have bad karma...)
fraggle@yaffle:~$ ldd
libX11.so.6 =>
fraggle@yaffle:~$ ldd
libX11.so.6 =>
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
Now, I know I'm responding to an Offtopic troll, but...
OpenGL is an API for talking to a Vector and/or Raster drawing subsystem. It works for 3d and 2d drawing. Where hardware acceleration for vector drawing exists (ie most modern desktops) OpenGL can send the drawing commands direct to the Video Card, without rasterizing the result first. This means that vector applications (such as SVG rendering) can operate a whole lot faster, and are simpler to code.
Where the application is not running on the same machine as the display, sending GLX vector commands rather than rasterized images can be much faster. Also, it does not load the machine significantly more than having application-side rasterization where acceleration hardware doesn't exist.
So by working on OpenGL (which is mostly a server issue, not an XLib issue), developers are working on SVG, Animated Everything, and faster 2d.
... but this page was the third result in a search for "D-BUS Linux."
Remember the ldd command:
/usr/local/kde/lib/libgt-mt.so /usr/lib/libgtk.so
$ ldd
$ ldd
The output will show you all the libs these depend on. libX11 is included.
Alternately, many people are using crappy video drivers which make things slow (like vesa or fbdev). On my ATI Radeon, with proper drivers, X (with Gnome 2) is as fast as Win 2k ever was.
GTK on the framebuffer is quite nice. Aside from the nice transparency effects in the screenshots, it's really quick. Hopefully we'll see a LiveCD come along soon with GTK on DirectFB so people can evaluate it without jumping through a great many hurdles. I bet a great many GNU/Linux/BSD users don't need or even know about the many features of X11 like network transparency, let alone use them.
:) I could be wrong about that, but it seems to be more modular, and lightweight.
I like to think DirectFB is to X11 as Hurd is to Linux. ( in design - not availability
With that said, congrats to freedesktop.org. They are becoming more and more valuable to our little community every day it seems.
Everyone. Right now, there are two ways to communicate with X-server.
XCB - A new, low-level binding designed for big toolkits like Qt/GTK+ that can handle their own caching, buffering, etc.
XLib - An older, higher-level binding originally released with X.
Currently, almost all apps still use Xlib, as do all toolkits.
A deep unwavering belief is a sure sign you're missing something...
X is slow sometimes, and crashes to often at my site (twice a week)
Impossible! Nothing unix-based ever crashes! You must be thinking of Windows.
Nothing happens when I issue the following command
/dev/fd.o /mnt/floppy
mount
Am I using this wrong?
microsoftword.mp3 - it doesn't care that they're not words...
That ought to make all the "X: no process killed" messages in your logs go away. kill needs a signal to send. ;)
Alas some of the world still doesn't see the benefit of free software. Apparently some people actually use the binary only video drivers from ATI and nVidia. If you do, you'll be crashing a lot more.
Alternately, many people are using crappy video drivers which make things slow
Thanx for bringing this up. I was about to say this exact thing (until I scrolled further and saw your post...).
Throwing a crappy 5 year old PCI vidcard in a box to "try out" "Linux"* will indeed give a person a rather negative opinion of X. Personally, I had a nVidia TNT-2 in this machine and X ran far better than Windows ever dreamed of running on the exact same hardware (dual boot just for testing Windows). Got a lot better frame rates in q3a and RTCW as well. Now I have a gf4-ti4600 in this machine. I honestly have no idea how much Windows likes it, and personally don't care enough to find out, but this machine is really damn fast with teh card in. Had I shoved my old PCI VooDoo 3 card in here (where ever the hell it is), even with this being a PIV-2.4Ghz machine, X would be noticably slower.
* I say "Linux", I'm really meaning anything other than Windows.
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
never? um no - that's not quite right - Unixy OSes can crash in certain circumstances, including faulty hardware. In general though, Unixy OSes crash far less often than microsoft OSes.
A typical unix/linux system running on sound hardware will simply run nonstop, as long as you want - for instance our linux mail/dns servers ran for about 2 1/2 years without a reboot, while the windows servers around them were not only rebooted scores of times, but had the OS reinstalled a few times as well.
Just a data point for your consideration
the worse impression is given by opaque window resizing because there is not synchronization between the window manager and the application.
...
So it works like this:
(a) Xserver send resize command to WM
(b) WM wakes up
(c1) WM draws new windows border and send redraw event to the APP.
(c2) During (c1), the mouse moved again so the Xserver send a new resize event to the WM.
(d) There are now waiting events for the WM and the APP. The system is 'clever' and, most of the time select, the last active process which is the WM. Go to (b) and repeat
So basically, during an opaque resize, the borders are redrawn 50 times per seconds while the count is redraw maybe 2 3 times par second.
Share and enjoy!
Are you Sirius?
Are the people at XFree86 maintaining xlibs also? Will this be imported back at XFree86? The release email says xlibs is actively maintained by fd.o (does this mean it is not actively maintained by xf86.org?), but does this mean fd.o will become the official version (i.e., the version bundled in the mainstream distros)? Or will they be two competing implementations?
IIRC, Debian already uses libXft from fd.o (which is a bit obvious, as Keith Packard is in fd.o).
AFAIK DCOP doesn't depend on Qt directly and has C-bindings. The problem is with depending on C++, and depending on Qt for communicating with KDE-programs. Many KDE-programs uses the Qt-internal structures to stream over DCOP, that makes it very difficult to communicate with them without Qt.
NT4 and above cheat even more than you think. They run the gui driver subsystem in ring 0, same level as the kernel. Happened around NT3.51. This is a lot of where the perception that windows is 'buggy' comes from. A bad video driver in this area can take out a system FAST. Before this the gui was a PIG in NT. It ran at the same level as the user. It was a trade off, Speed for 'stability'. At one time you could actually crash the gui subsystem and restart it. Now where its at if it crashes its BSOD time.
I would be willing to bet Apple did something similar as NT4. But they have an advantage. They have like 4 different video chipsets to support? They can afford to make the gui stable with a bit of time. Windows and Linux have hundreds. So it would take them quite a bit longer to make it work right. Which is why you see things like 'certified' drivers.
With the newer kernels linux giving up more time to user space it should help quite a bit.
Also perception sometimes can work for you. People after about 4-10 seconds start wondering what the computer is doing. So putting something in front of the user is sometimes a good thing for long operations. Even though it will still take the same amount of time or even a tad longer. The user 'feels' like it is faster. Even though you can take a stopwatch out and time it and takes exactly the same amount of time.
I agree with you on the X is not slow thing. That is a perception. Not sure where it came from. I have seen NO numbers that prove one way or the other that X is slow. In relation to what? To take a measurement but have it in no sort of relation to anything is dumb. Even then you have to be carefull as to what you are comparing against.
The way I understand it, Havoc Pennington said that several X.org and XFree86 developers were working together. This was misinterpreted by journalists as the projects working together.
Hmmm.
I'm afraid that your sarcasm detector seems to be broken.
I've been using my binary NVIDIA drivers for years, on a number of different platforms, and only with the earliest releases did I have X server crashes.
A deep unwavering belief is a sure sign you're missing something...
DESCRIPTION
killall sends a signal to all processes running any of the
specified commands. If no signal name is specified,
SIGTERM is sent.
manpages win again
You're lucky then. The smallest of changes to my setup broke mine. I bought a ATI with an R100 because of it, and life has been good ever since.
As in: "Somebody stuck a fork in XFree86, I think they're done." ;)
Please take your Linux-centricity and shove it up your ass, kind sir.
having and understanding a sense of humour is good for your mental health. seriously, is this "i don't get sarcasm" day on /.?
just a data point for your consideration ^_~
Xfce: Lighter than some, heavier than others. Just right.
I'm curious, what kind of hardware have you used it on?
I have used it on:
Pentium II 440LX chipset (Riva TNT)
Athlon XP SiS 730 chipset (GeForce2 MX)
Pentium 4 845M chipset (GeForce4 Go 440)
I don't use Xinerama or TV out very often.
A deep unwavering belief is a sure sign you're missing something...
I don't know, what day is it?
I've read that OSX and Windows XP (perhaps NT/95/98/2K also?) have a "hardware accelerated desktop". Can someone define what that means and how it compares to X? I've noticed that regardless which drivers I use with Linux (built-in or downloaded), my window movement and resizing is (at times) still kind of choppy whereas with Windows, it's instant.
I don't recall the motherboard, it was in a box at my former employer. I contacted nVidia support, who told me I was experiencing a "known bug", and it would probably be fixed in a future release. Three months later, I tossed the card and got one with free drivers.
My next experience with binary drivers in Linux was last month, with the ATI one trying to help a friend who was trying Linux out. (That one was a Gigabyte board with the KT400 chipset) After a week in, he told me "Linux sucks because it crashes more than Windows ever did", and his TV tuner didn't work. I switched him to Gatos, and he's very happy now.
Once bitten, twice shy. Twice bitten, I'm full of spite.
Non!
The headline that got put on the press release was misleading. The reality is that X.Org has been reformed to be more like the GNOME Foundation. There will be open elections to appoint a board. Votes will no longer be obtained through monetary contributions; in other words, any one can have a vote and be elected, no matter their affiliation. The actual information handed out by X.Org should be posted on their site in the next few days, which includes the mission statement and aims of the project.
Some developers that have at one time or another been associated with XFree86 are participating in the reformation of X.org. How that translated into "XFree86 and X.org have mereged" in the headline is beyond me.
Harold
Windows cheats and loads the gui extremely fast, but if you watch your hardrive light, and tool tray, you will noticed things are still being loaded in the background. The system is busy for a few more seconds. You can load an application, and it waits till after the services start.
So, you're saying X by itself is as slow as both Windows AND its services loading up?
I don't know about you, but my Linux services get loaded before X starts up.
Longhorn's GUI will be Direct3D-accelerated. They haven't unveiled the new "3D photorealistic" interface yet and don't plan to until release--to avoid copiers, they claim.
You're kidding, Slashdot got it wrong?
I'm going to go now and boot up my Windows Media Center PC more quickly using Linux!
...Could the answer be the mach kernel osx uses?...
./ about OS X some time ago (search apple section, its a long but very detailed article) where this was mentioned.
Besides having drivers, as others have mentioned, Apple also did some (proprietary: not available for the publick) work on their implementation of the X server. Could be that. I can't be more specific (read: don't know more), but there was a link to an article here on
The worst thing about X is colour management. GDK does it better, but it still isn't good enough. Also, most of the time you just want to draw in RGBA format and X11 is a pig for this sort of thing.
Things That Happen When You Say 'X Windows'
THE OFFICAL NAMES
The official names of the software described herein are:
X
X Window System
X Version 11
X Window System, Version 11
X11
Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).
The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!
You are forced to explain toolkit programming to X neophytes.
Bob Schiefler says, "You should know better than that!"
The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.
Ditto for the controller board for the disk on your new Sun.
Your hair falls out.
xmh refuses to come up in a useful size, no matter what you fiddle.
You inexplicitly lose both of your complete Ultrix Doc sets.
R2 won't build.
Bob Schiefler says "Type 'man X'".
Your nifty new X screen saver just won't go away.
The window you're working in loses input focus. Permanently
-Don
Take a look and feel free: http://www.PieMenu.com
-Don
Take a look and feel free: http://www.PieMenu.com
Someone send this to NASA engineers, they forgot it in Spirit.
X is modular.
George W Bush is a Compassionate Conservative.
Iraq has stockpiled of Weapons of Mass Destruction.
The British government has learned that Saddam Hussein recently sought significant quantities of uranium from Africa.
Nobody ever bothers to check the facts that Bush says in his State of the Union Address, so all emphatic misstatements of fact are purely accidental, and certainly not intended to mislead.
You're Unamerican for suggesting that Bush is a liar.
The Iran/Contra scandal wasn't about trading Arms for Hostages.
OJ Simpson didn't do it.
Got any more good ones for us?
-Don
Take a look and feel free: http://www.PieMenu.com
-Don
Take a look and feel free: http://www.PieMenu.com
But its not. X is very fast. You can run benchmarks yourself. For stuff like bitblits, X is as fast as DirectDraw (quite an accomplishment for a generalized graphics system!) On my machine, X can copy around ~2GB of 100x100 pixmaps per second, which makes for a bandwidth utilization of about ~4GB/sec. That's pretty close to the maximum memory bandwidth of my graphics card, which is 6.4GB/sec.
X has been quite fast in practice too. SGI shipped a very high-performance X implementation. The main issue is that until recently, there wasn't a lot of interest on X machines on the desktop, even that little interest was in the workstation market, where absolute performance matters more than the responsiveness of the UI. Now that there is interest on putting X on the desktop, people are working on making it more suitable for that role.
A deep unwavering belief is a sure sign you're missing something...
X-Windows was designed to be a distributed window system, to operate over the network.
Yet it was foolishly not designed to support extensibility: dynamically downloading code to the server to perform local input processing, feedback and graphics, and to vastly reduce the amount of network traffic.
If your web browser had to perform a round trip to the web server each time you press a key, would you say that's a good efficient design? Nope. Would it matter that your graphics card can blit ~2GB of 100x100 pixmaps per second? Nope.
-Don
Take a look and feel free: http://www.PieMenu.com
I assume you're not the real don hopkins, because he would know that X is modular...
In 1988, I helped develop the NeWS driver for UniPress Emacs. James Gosling wrote UniPress's version of Emacs, as well as the NeWS window system itself. UniPress Emacs ran quite nicely on 4Sight. Emacs downloaded code to handle all the pop-up menus (pie menus or linear menus -- you could decide) and text selection feedback locally in the server.
After Emacs draws the text on the screen, it downloads a short array of numbers telling the server how many characters wide each line is, so the code running in the server knows just what it needs to give local text selection feedback.
So when you press down and drag to select text in emacs, the selection feedback is instantaneous even if you're running over a low speed dial-up connection. When you release the button or move the cursor outside of the scroll region, only then does it send a message back up to Emacs telling it to select the text, or initiate autoscroll.
How would you do that in X-Windows? Please explain your approach to extending the X-Windows server to support local text selection in emacs (and local pop-up menus while you're at it), without any unnecessary network traffic?
-Don
Take a look and feel free: http://www.PieMenu.com
Ok I'm thrilled about this! So can anyone tell me, what or why I'd want to use these libs? (-:
Gamblers Forum
What about a unified OO system?
Mozilla & OpenOffice use separate systems.
Seems overkill.
Use 1 CORBA system, built XFree upon it and then Mozilla, OpenOffice.
That's how Quartz Extreme works, the entire screen is rendered by OpenGL, and the windows themselves are OpenGL textures. This is a lot faster (on modern video busses and cards) than trying to do all the eyecandy and GUI-related tricks on the CPU and drawing to the video card.
What I can't wait for from OSX, Longhorn, and is an OpenGL/DirectX rendered display that also implements a vector-based system, so I can run my 19" display at maximum resolution and get finer, smoother text and widgets, not unreadably small ones.
The way display managers should work in this day and age is to set the maximum resolution that works on your display, pop a rectangle on screen and say 'measure this rectangle with a ruler and enter it's real legnth in this text box'.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Who modded this up? It's 90% hooey!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
The correct troll is "I don't use Linux... you insensitive clod!"
Such a friendly community.
IMHO, every major C project should use glib
..which is why DBUS should *certainly* not depend on it, if they want the C++ projects like KDE to use it. Using Glib in KDE is pointless, since you have Qt which can do everything GLib can do already, arguably better.
This is hogwash. DBUS is written in pure C (not C++), it does not depend on GLib *OR* Qt. It just ships with bindings for GLib (and soon Qt as well).
What are you talking about? Look at the API documentation for dcop, and pay attention to everything with a Q in front of it, things like QString, QCString, QByteArray, QDataStream, etc. These are all from Qt. You can tell this yourself, because they all link back to Trolltech's documentation. If you are more adventurous you can look at the dcop source in kdelibs-3.x.y/dcop and see that it directly relies on Qt.
Actually I DO use nvidia drivers - best drivers available for linux BTW. and I just don't see the crashes, sorry - it's solid, on 2 machines at home and 1 at work - and that's giving X a good workout - mozilla all day, OpenGL screensavers when I'm away from my desk, occasional quake 3 arena, ut2003, videos with mplayer, lather rinse, repeat - and no crashes.
WTF? The post you referenced was talking about DCOP being written in C++ and depending on Qt. It later implied that D-BUS was written in C (like the rest of GNOME).
RTFC
I'm not flame baiting, it depends what you're using to say it's fast.
I ran X on a 300mhz computer, i use blackbox (you can't blame desktop) X takes sometime to load.
Now a second proof, run Xfree 3.3.6 4.1.0 and 4.3.0 , run top each time, and you see how bloated it became, 4.3 use at least 4 times more memory than 3.3.6. that dramaticly reduces speed on a 128MB machine (mine) and is a nightmare for a 32MB one (i administer 4 of them, poor country).
A lot of friends have similar machines to mine: about 350mhz 128ram
If developers use high end machines and not real word machines, anything will be fast for them, even MSWindows XP
Although the KDE implementation of the dcopserver and the kdelibs client libs both use Qt data types, dcop data is carried over libICE (which is an X lib), and the wire protocol is also quite easy to deal with from C-only - unless you want to send a complicated Qt object to a KDE app (ie, something more complex than a simple string/int/bool/struct of such - QPixmap is the one that occasionally comes up). It would not be terribly hard to write a C-only client lib (instead of the existing C bindings that still indirectly use the KDE implementation) that didn't use Qt at all, and writing a C-only dcopserver would be easier than something entirely new.
Nothing fundamental about DCOP relies on Qt, just the current implementation (understandable since it came from KDE - same as it would use glib if it had come from GNOME). Rewriting things that your toolkit provides for free is bad practice, though keeping them out of your wire protocol is good for compatibility and future-proofing.
On the other hand, freeing DCOP from X would be harder, since libICE is a more fundamental dependency. And one of the cooler possibilities of dbus is the prospect of hooking in kernel events, events from other system daemons, etc. So on the whole dbus looks like it has some promise, if enough of the new possibilities it opens up for integration between GUI and non-GUI tasks actually materialize..
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
What happens when DBUS is speeding? It doesn't get pulled over! Thats because DCOP is too slow to catch DBUS!
How on earth did you get X to run that slow?
X/Linux on my 600 MHz PC at home ran faster than Windows 2000 on my old 850 MHz PC at work.
X/Linux on my 600 MHz PC at home runs faster than Windows XP on my new 2400 MHz PC at work.
Best of luck to you when nvidia's support stops, Xfree upgrades, and you've got no driver though. No source is no good.
You are quite incorrect, sir.
It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!
The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.
So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.
Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.
The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.
You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.
Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.
HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.
You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.
X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.
What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.
Take a look and feel free: http://www.PieMenu.com
X-Windows has Fanatics. NeWS has Freaks.
IBM-PC has Fanatics. Amiga has Freaks.
Flash has Fanatics. SVG has Freaks.
Fanatics all agree with each other, follow the same popular trends and religions, and support the status quo. Thus: X-Windows Fanatics. IBM-PC Fanatics. Flash Fanatics.
NeWS Freaks, Amiga Freaks and SVG Freaks have a lot in common, and tend to share a special bond.
-Don
Take a look and feel free: http://www.PieMenu.com
Well gee, maybe then we'll all revert to the nv driver instead?
-Don
What, you were't refereing to me? But I've been waiting for years to use that line!
Take a look and feel free: http://www.PieMenu.com
And 1 + 1 = 4, as 1 approaches 2.
-Don
Take a look and feel free: http://www.PieMenu.com
Hahah, no, Mach sucks donkey ass. The slowdown in performance given heavy IO based benchmarks (like compiling things) is noticeable. Mach-O is one of the most primitive binary formats around.
No, the reason the MacOS X GUI feels fast is that it's entirely double buffered and given priority over practically everything else on the system. The freedesktop.org X server has double buffering working nicely, but it's not ready for wide-spread usage yet.
As a server, Linux is more stable. As a desktop, Windows (2k or XP, not 9x) is more stable. This is why I use Linux on my servers and Windows XP on my desktop. (However, I intend to switch to FreeBSD on the servers and Mac OSX on the desktop when I get the chance.)