Slashdot Mirror
Not Just Eye Candy At Freedesktop.org
Jim Gettys writes "While Keith Packard's eyecandy at freedesktop.org, including drop shadows, translucent menus and windows with alpha channels is nice to look at, and in some ways useful, *much* more important
is that the same facilities are useful for
thumbnailing, screen magnifiers, and arbitrary transforms of applications on their way to the screen, just to name a few of the potential
applications. So enjoy the eyecandy, but remember, too much candy can rot your brain. And if you want to
avoid fattening your brain, you can come help us
make this ready for prime-time, and work off
the candy you ate and pitch in at freedesktop.org."
For background, see this earlier Slashdot post about Freedesktop.org, and the brief description below.
An anonymous reader sums up this effort to revamp X: "The new X server features full support for transparency, and has window-level image compositing among other things. It allows applications to present alpha-blended content to the screen. A new X Visual was added to the server. At 32 bits deep, it provides 8 bits of red, green and blue along with 8 bits of alpha value. Applications can create windows using this visual and the compositing manager can take those contents and composite them right onto the screen. The X server project holds sources to build an X server separately from a full X distribution."
Looking at screenshot number 3, I think the fellow's got a few bugs to work out.
Bu-dum-chee!
Thank you! Thank you! I'll be here all week! Try the buffet!
Image saved before slashdotting, Here
... I mean, look at Apple. They've built most of a business around being cool, sexy, and user-friendly. This is a triumvirate for the company, and with the unix-based OS-X, they'll be expanding into hardcore geek territory as well :-)
:-)
I even wrote eyecandy (the visualisation applet) on hostip.info - it's a trade: I show you something pretty, you put in your city. Or not. Your choice, but hopefully the eyecandy helps sweeten the deal
Simon.
Physicists get Hadrons!
The objectives of Xouvert and the freedesktop.org Xserver are different. Xouvert is intended to be an experimental "bleeding edge" branch of XFree86 with opportunities for developers to contribute easily and will remain in sync with XFree. Xserver on the other hand has no connection or relationship with XFree and is wholly an alternative (not a fork ... this code is based on Keithp's own XDrive server which has a brand new core, not XFree86, although some code is reused I believe). In other words they are in fact separate projects.
I'm not sure exactly how the Xouvert folks respond to this, but I believe they are interested in eventually collaborating with this effort in the future, from, my discussions with a couple of them.
And no, it's not just FB/Vesa. There are servers available for r128, mga, mach64, and a couple of older cards (S3 savage/trio and trident).
Am I a hipster-doofus?
I take it you've not used Windows in the last few years then. Take a look at the menus and toolbars in Wordpad, Visual Studio, Office 2003, Windows Media Player and Encarta.
What? They're all different? How dare those people not use the builtin toolkits - what are they thinking?
I think that really you don't understand the Windows architecture (which is really quite similar to X except for no network transparency and a kernelized WM), otherwise you'd realise that multiple conflicting toolkits happen all the time there.
This is even true of MacOS X. There are some well known incidents where it was shown that different apps in the MacOS X base distribution reinvented the same widget multiple times over.
"and the ability to run programs remotely is good, but now days for the average desktop user, this is not very practical,"
This is a complete non-issue. By default, X doesn't allow connections from outside so you can't use it unless you really *want* to use it.
And local applications doesn't communicate using a TCP socket, but through shared memory and Unix Domain Sockets (which are as fast as shared memory, at least on Linux), so performance problems for local apps are gone.
Network transparency doesn't stand in your way. It doesn't bother you. But when you need it, it's there.
And you people should look beyond the home desktop. Think about the corporate desktop! A server serving hundreds of thin clients can save a lot of money. Many, many people today rely on X.
Network transparency *does not* block desktop acceptance.
For your viewing pleasure, I have obtained an ASCII-art mirror of the screen shots:
----------
|* |
|* |
|* |
| |
|========|
----------
The issue is not really the speed increase (although yes, it will be faster). The point is that this will give you *TRUE* alpha channel-enabled visuals. What KDE and a couple of other projects like the Enlightenment DR15/16 series have done in the past is a "pseudo-transparency" hack done by grabbing the root pixmap and using it to blend. By using a compositing manager and adding true 32bit ARGB visuals, a window can say exactly how transparent each pixel should be, and the compositing manager combines everything together to produce the final display. Semi-transparent windows are overrated: this gives you a LOT more potential for snazzy effects (for starts, how about shaped windows that have antialiased edges?).
Am I a hipster-doofus?
I've noticed the look of the screenshots at this site. It seems so many people want things that look and work like Mac OS X in the freeware world nowadays. Then why are so many more people going with Gnome and KDE? Why don't more people just support the GNUstep people instead? I think NeXT and now Apple has proven the world won't fall apart if you use Objective-C instead of C++. If you go to the http://www.w3.org/ site you'll even see that the first web browser was written in Objective-C. Also, OpenStep exists as a standard so it sure will make easier to port commercial applications written in Cocoa to the Unix world.
I'm wondering how long before we see this in XFree86.
:)
It probably won't go into XFree86. The freedesktop.org X server contains a rewritten core and relies on many X extensions that the XFree86 project is really not embracing. Despite the good work the XFree86 team has done over the years, they have a long history of hesitation and, even worse, conflict with those that would take XFree86 in a non-standardised direction.
I applaud the new efforts on freedesktop.org, especially by the evergreen Keith Packard, and this is what we need to see in the FLOSS world.
X11 is one of the few areas where there is no real competition between projects. Linux vs. BSDs (vs. each other) or KDE vs. GNOME. It's healthy; it pushes the projects to higher levels of progress. Once freedesktop.org's X server is ready for mass consumption (hopefully not too long) then this 'lack of competition' changes.
FLOSS will see a whole new world of graphical coolness as Window Managers and Desktop Environments add Compositing Managers to produce awesome effects using freedesktop.org's X server and the group of projects supporting it.
The freedesktop.org X server intermingles with things like Cairo and lots of other exntensions. Conversely, XFree86 seems to fight any hopeful extensions.
What will happen is that in a couple of years, many DEs and WMs will ship with a 'feature X requires freedesktop.org's X server and will not work with XFree86' and XFree86 will lose backing and momentum.
The only downside to freedesktop.org's X server is that it will no longer run well on a 20mhz 486.
Yeah, I don't care either.
Free Gamer - Free games list and commentary
I, for one, welcome our new alpha-channel enabled translucent overlords.
It has translucency? I have yet to see that implemented. Everything I've seen so far is only varying levels of transparency. I'm only seeing alpha channel implemented, no options for a scatter channel which would define the degree of scattering of the image as it passes through a foreground image.
Ah, I can't fault you. The site itself regularly misuses the term "translucent". Free lesson: if you can make out details, particularly able to read text, it is not translucent, it is transparent. Transparency is a continuum from completely transparent to opaque. Translucency is not part of that continuum. It is different, like looking through a frosted shower door, where you can get the sense of color and motion, but where details cannot be determined. Photons get scattered by the medium resulting in a loss of perceptable detail.
I'd applaud a system that implemented a scatter channel for true translucency. Trying to read text while other text is showing through it is difficult. A moderate amount of translucent scatter applied would be less distracting.
Now think, what if you could apply a visual blurring to windows that aren't in the foreground/under the cursor? Surely that could help focus the user on a task. (There'd need be some control to allow multiple windows be in perfect focus on occasion.) Simulated depth perception to enhance the window stacking model.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
In the long run, KDrive will become the standard: it's a much better server. KDrive does share much code with XFree86, but it has major cleanups and simplifications. It will need more driver support (though this is much simpler in the KDrive architecture) as well as 3D support before it is ready to take over, though.
In the short run, the right answer is to fold the changes back into XFree86. This should be no big deal technically: there's nothing terribly KDrive-specific about them. Politically, it may be harder: the reason that Keithp was ejected from the XFree86 project was essentially for trying to change things. :-)
The XFree86 DRI project server is on freedesktop.org, and will probably have these fixes well before the XFree86 core server. This server is likely the immediate future of XFree86 anyhow.
I think we need to talk to people from KDE, Enlightenment, Gnome, and all of these groups and as a combined effort build the first and default composition manager.
That's what freedesktop.org is. It's a collaboration between GNOME and KDE to develop a set of interoperable standards. For example, you may have noticed that both KDE and GNOME can use the same ".desktop" shortcuts and that ".desktop" files have completely replaced the ".kdelink" files that KDE used to use. Now if GNOME would come up with some sort of (God forbid) STANDARD on how their foot menu works, we might even be able to automatically install icons. Right now, nearly every distro does something different with the way the foot menu works. At least KDE figured it out and has been standard from version to version.
Javascript + Nintendo DSi = DSiCade
Actually, KDrive runs better on a 20MHz 486 than XFree86. It's much smaller, and has things like a shadow frame buffer VESA mode that make it work well with pathetic graphics HW. I've used KDrive on an 8MB 386 to good effect.
Of course, you won't want to use the fancy compositing managers on such a box, but at least you can have some kind of window system on it instead of just being stuck with console mode.
X11 isn't like the stuff Microsoft or Apple churn out. Microsoft and Apple just hack something together, throw it out, and call it a "standard API". It's easy. It's quick to market. And it locks people into proprietary APIs and has all sorts of other problems.
X11 is a protocol, not an implementation. As part of defining protocol extensions, people build a reference implementation of the protocol extension. It makes perfect sense to build the reference implementation in software. Hardware vendors and implementors can then build hardware accelerated versions of it and compare it with the software implementation.
This approach has worked very well. It means that X11 has remained backwards and forwards compatible over more than a decade and that X servers have been able to take advantage of new hardware technologies as they have come out.
Note that Apple is not using the "innate RGBA capabilities of the video card" to its fullest extent either. Furthermore, even good 3D cards may not do the right thing for 2D rendering--2D desktop rendering is not simply a subset of 3D rendering.
And, of course, you can very well write a compositing manager to do this. That's the beauty of this extension set and architecture - the X server doesn't tell you how to render things. It just provides the means to let you do it. You could even swap composition managers on the fly, I'd imagine, or just tweak settings there-of, or whatever. Just like you can do with a window manager.
Then why are so many more people going with Gnome and KDE? Why don't more people just support the GNUstep people instead?
Easy: while a lot of people like the look of the Mac, they don't like the underlying technologies: DisplayPDF and Objective-C. Personally, I think those technologies are obsolete, inefficient, and cumbersome.
I think adding transparency to X11 is a technically much better solution. It is language neutral and transport agnostic. It also has the virtue of being backwards compatible. And it doesn't require people to throw away their existing X11 software--there is a lot more X11 software than OpenStep or Apple software.
X11 will also get server-side stored vector graphics based on SVG. Again, same functionality as DisplayPDF but more standards compliant and a better design.
Also, OpenStep exists as a standard so it sure will make easier to port commercial applications written in Cocoa to the Unix world.
In what sense do you believe OpenStep is a "standard"? Where are the standards documents? Where can you even get an implementation?
It seems that right now, we have GNUstep and Cocoa, two similar but incompatible implementations, together with some copyrighted API documents.
Note, incidentally, that few of the features that make the Macintosh API visually appealing (shadows, transparency, etc.) were pioneered by Apple, and historically were implemented without anything like Apple's software infrastructure.
There, I would like to point out why something like KDE exists to -reduce- bloat, paradoxical as you may think it.
First of all, a LOT of any given KDE app's functionality resides in the libs. Heck, you can write a simple Web browser in 10 lines of code... This means that to start that app you'll need to load all sorts of libs, which accounts for some of the ~25% more memory a full KDE desktop takes over WindowMaker, as the parent post points out.
Only, and there's the tasty part, once the lib is loaded, it's loaded for all the apps that will ever use it. Ergo: the more code is shared by apps, the less bloat you get down the road.
While this -does- mean you get a bit of an overhead at startup, any additional KDE app running takes up considerably less additional memory than a similar app re-coded from scratch.
I routinely have 10 to 20 browser windows (tabbed and not tabbed) open at a given time, with a mail client, newsreader, IM app, music app, a variety of applets, an IDE and countless terms, and the system doesn't even flinch. Try doing that with as many GUI apps all reinventing their own wheel.
Oh, and as for speed, turn off the eye candy and KDE runs all sweet on a simple Pentium (yes, I did try it).
Note, I name KDE here because that's what I use most, but the same can be said for Gnome (to a lesser extent maybe; last time examined the Gnome architecture it encouraged custom code somewhat more, which is not a bad thing either, mind).
-- B.
This sig does in fact not have the property it claims not to have.