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.
freedesktop, xfree86, and the MIT X Consortium have pooled their resources and released software that THREE TIMES AS MANY PEOPLE don't care about!
Who uses Xlib nowdays? I'm not sure GTK/QT depends on Xlib. Correct me if I'm wrong. O'course many of us will like a faster version of X, because X is slow sometimes, and crashes to often at my site (twice a week)
!4fafasf
When will we have a full 3d polygonal interface? I'm betting Sun with their JAVA3d based interface will do it before Keith Packard and Freedesktop people.
People don't exist to serve systems, systems exist to serve people.
Quasi-f1r5t p0zt!! long live teh big pimpin!
Yah whutevah, you knows i be right foo'!! I PITY DA NOOB!!
still use non-bloated window managers like WindowMaker, Blackbox, IceWM, and Enlightenment that don't use the GTK/QT libraries.
We simply are not ready for a next generation 3d interface. If you want that just buy Apple OSX. Right now we need to match Windows on the 2d interface. The hardware isnt ready for 3d, the software developers arent ready for 3d, and you arent ready for 3d.
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!
FreeDesktop needs to spend more time on SVG widgets, and animated widgets, better quality 2d instead of wasting their time with OPENGL and on this 3d crap.
Parent is an arrogant prick/developer dictating what users want.
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.
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.
Xlib, what's it all about? Is it good, or is it whack?
Its going to be even more bloated now that I hear they want to piggyback open GL on top of freedesktop. Why cant they make X smaller, more efficient and get rid of all the bloat? Make it modular.
Now that's putting your work where your mouth is. If only those FreeBSD.org assholes would follow and stopped flaming Matt Dillon.
Brett Glass
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.
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.
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?
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....)
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...)
... but this page was the third result in a search for "D-BUS Linux."
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...
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.
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.
As in: "Somebody stuck a fork in XFree86, I think they're done." ;)
stop spewing catchphrases you WORTHLESS SHITSTAIN
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.
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
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!
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
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
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.
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!
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
-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