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."

Comments

But are they doing it right?

[ArmorFiend]

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.

Can someone tell me, are they doing it the right way, or the all-software way? The right way uses the innate RGBA capabilities of the video card (probably through OpenGL) to do the compositing. The software way is good to have if the computer in question doesn't have a decent GPU, but if it also doesn't have a decent CPU, slowness is going to ensue.

If people want things to look and work like Mac OS

[Anonymous Coward]

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.

Re:Translucency vs. transparency, and depth percep

[DreadSpoon]

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.

they don't like the underlying technology

[penguin7of9]

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.

Why KDE and Gnome -reduce- bloat.

[Balinares]

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).