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."
Sheesh, evil *and* a jerk. -- Jade
Slashdot made the website translucent.
I don't get why the Xouvert folks didn't just pitch in on this effort. They're almost a month and a half behind their schedule.
/me thanks fdo
Oh well, I'm still getting what I want. Maybe soon they'll be able to add 3D support, as now it's just FB/VESA. Now I'm off to make some debs from the CVS.
So Microsoft can copy Apple, but X can't? That's not far at all.
Fred
"A fool and his freedom are soon parted"
-RMS
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
Do translucent windows sitting on top of video playback work with accepatable speed?
If translucent windows can "fatten your brain" (er..?) then is ratpoison the Atkins Diet? Someone else help me out with abusing this metaphor some more.
Slashdotters are always complaining about that X is slow/bloated/outdated/old/must be replaced/etc/etc. Yet X is slowly improving. Nonetheless, that doesn't stop people from complaining.
Now that I've seen thousands of Slashdotters complain about X, and it seems alpha transparency is finally progressing, I can only conclude one thing:
Don't listen to the whiners!
Really, *all* those people do is whining and bashing, and *nothing else*. No constructive criticism, no suggestions - just whining and bashing. And while people are wasting times whining and bashing, real developers are making real progress.
This is it. Slashdot has lost my respect. I will never listen to the whiners and bashers again.
I think it is time we make a more userfriendly, windowmanager-specific GUI for Linux/FreeBSD/etc that will be accepted by the masses and seen as "Linux", maybe make it official, this is the perfect grounds to get it accepted by the masses, making a unified interface for linux and other derivatives, then see if it is accepted. Make it like windows where all you see the whole time is the user interface, to make it better for the desktop world, some say that choice is good, and the ability to run programs remotely is good, but now days for the average desktop user, this is not very practical, and choice is becoming randomness since there is no standard user interface guideline for Linux. Lets make someone like MacOS X for x86, but based on Linux: fast, easy, etc. I could help with UI development, etc if anyone is interested in starting a project, I'm not much for coding though. Linux needs somthing original. I know, I posted this in the past, but I am wanting to get the word out.
Sig: I stole this sig.
I mean, you have to use Mozilla or a Mozilla-derivative for web browsing (Konqueror is nice and all, but the last time I tried it extensively it still felt toy-like, and Mozilla is the cross-platform standard I am used to and want to use). But that forces you to use Gtk - so forget about KDE, you need to use GNOME. But now you have to use the awful mismatched GNOME apps. Then what about the OOo monstrosity? The toolkit, widgets, fonts, etc. don't seem to match anything else on the desktop. Why does this just never happen in Windows (even OOo doesn't exhibit these awful characteristics in Windows - yes, this is a rhetorical question, I understand the technical reasons and they all indicate major flaws in the X architecture to me)?
Keith P, you are doing the right thing. I wish I had more time, I'd pitch in and help out with this project, since it might allow me to actually use X without clawing my eyes out some day (or coping with atrocious performance when you hack in all the eye candy on top).
... 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!
So enjoy the eyecandy, but remember, too much candy can rot your brain.
oh that reminds me of something.... oh yeah! THIS
Do not look at laser with remaining good eye.
oh man, this is probably the greatest usenet post I've ever seen.
long live ratpoison!
Since I can't get to the freedesktop site right now, I'm curious about the speed increase when the alpha blending is done by the X server instead of by the window manager. The one screen shot I did see(only because someone mirrored it) had gnome with semi-transparent windows. I'm not a gnome user, I use KDE and I know it handles transparent windows and menus. But how much faster and snappier will the response be with the transparency done at lower level?
For your viewing pleasure, I have obtained an ASCII-art mirror of the screen shots:
----------
|* |
|* |
|* |
| |
|========|
----------
at http://www.herrvinny.com/sdmirror/
Don't get me wrong, if you have fast hardware and are trying to convert grandma from "some other environment" go for it, but for me personally I will take lean, mean, and quick any day of the week.
I Am My Own Worst Enemy
expose (application name display upon mouseover)
thumbnailed snapshot of applications on the dock
transparent terminal (though i prefer iTerm)
shadow intensity indicating the front most app
THIS is eyecandy!
Anyone know who this is?
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
Hmm, this looks promising. Now all that is needed is for someone to write either a compatibility layer to bring the XFree drivers over to the freedesktop.org Xserver including GLX compatibility, make the Compositing Manager use OpenGL and eureka we have GPU based compositing.
This is close to the features coming in Longhorn, where the windows are to be considered textures rendered by the GPU.
Now my personal dream is still to see a combination of this and a high level protocol/server in which the applications and window managers send in calls where they ask for things like a button or a menu and include the data, while the rendering mechanism (the widgets) rest on the serverside (allowing for a central repository of widgetsets and almost guaranteed consistency of the UI). Custom widgets could then be implemented as either "server-side" extensions ala the scripts/executables that make up a webapplication or as client side components which are allowed to send drawing instructions to the server. It is intriguing to think about the possibilities of letting each window own a thread and socket connection (as in a modern webserver) to the application so that they can all update their own "scene" concurrently (almost anyway) and then the central compositor/renderer renders these changes from the existing application/windows tree.
A person is smart, people are deeply stupid
I do not care much about the new eye candy if I cannot use it and I do not really want software based hacks. Can this eye candy work with my ATI or Nvidia card?
People don't exist to serve systems, systems exist to serve people.
The first web browser was World Wide Web and written by Tim Berners Lee. Mosaic came out some years later.
I don't think this is the issue anymore - the extensions used for this translucency don't require any driver changes, as RENDER (or any other rendering method/extension) can be used.
;-)
Here's to hoping XFree86 gets these extensions. Having an X server that doesn't work that well for the hardware most people are using is going to limit how many people can use these new extensions...
You seem to have everything planned out, you have a roadmap, why don't you start working on it right now?
People don't exist to serve systems, systems exist to serve people.
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?
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
Getting over square brackets was very easy for me, especially since the corresponding semantics in Objective-C are much nicer for writing complex programs in fewer lines of code. The resulting return type from an [object message] expression is always the generic object type, and you are free to send the resulting object any message...if it won't respond to the message, it's quiet about it...even if that object is NIL. (Thank the maker!) Of course, if you want stricter type checking, you have that option too...but at least Objective C gets out of your way when what you really want is to be maximally expressive while being minimally verbose.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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.
> the fact remains though that kde has been throwing hacks into their desktop for ages with no real substance.
Fake transparency is certainly a hack, but the GNOME folks are as guilty as the KDE folks for using it. Both KDE and GNOME support fake transparency in their terminal apps. GNOME supports it in it's panel, and KDE supports it in it's menus. Other window managers even support fake transparency in their titlebars (like kahakai, afterstep). Tell me how again how KDE has thrown more hacks into their desktop versus others?
> And as far as kde goes with adopting standards they tend to be very against taking any freedesktop work and using it although i guess they may have other reasons than "its the KDE way or no way" D-BUS comes to mind as one such standard.
Uhm, there have been around fifteen standards put out by freedesktop.org. KDE has implemented nearly every single one. You provided one example (D-BUS), that isn't, but might I remind you that D-BUS isn't part of GNOME, or xfce, or ROX either. There has not been a firm agreement or disagreement on the KDE side to use D-BUS or not, because it could only be done in KDE 4.0, which is still a bit far off.
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.
In order to play with this X server, what hardware does one need (i.e. what hardware does the current CVS version support?)
John_Chalisque
You're assuming the only choices are to present 5 commands at a time or to present all commands in one big long list. There are other ways, you can present a screen-full of commands divided into small groups, each group presented in its own section.
Look at real menus in restaurants. Some restaurants have a lot of food choices, but the choices are presented under different sections, appetizers, soups, salads, noodles, etc. Once you find the right section, you can find your favorite food easily...
Now think about those menus that go on for pages, you have to flip back and forth between pages just to find the proper section. Other menus are presented as one big page (double-sided perhaps), to find the proper section you quickly scan the large-type headings and take it from there, it's just as easy minus the page-flipping.
Cascading menus are like multi-page restaurant menus. I'm saying that we now have enough space on the screen to present single-page menus (or perhaps 2-page).
Another example, say you're looking for the shrimp-noodle soup but you're not sure which section it is in. For the multi-page menu, you have to flip flip flip to the soup page, check there, then flip flip flip to the noodles page, check there, and so on. For the single-page menu, you quickly scan for the possible sections and look in each, if the particular meal doesn't jump out at you, you still have all sections in front of your eyes so you can locate another meal that is close to what you want.
This is like the preferences command. You never know if it's under File, Edit, or Tools, you have to visit each drop-down menu in turn. If all commands were presented in a single sectioned page, you'd have an easier time finding it. Furthermore, on subsequent visits, the visual clues of that particular menu help you remember where the preferences command is.
Another example, toolbars became popular about 10 years ago. Why? because, on one hand it was a one-click deal, and the other hand they presented all the commands at once (divided into small groups of course). Their only problem: because of space limitations, they use icons which get to be cryptic. With today's bigger screens and faster cpus, we can pop-up a giant version of the toolbar but with text to make it more usable.
yes, linux had transparent terminals way before OSX(before it existed even...). it was one of my reasons for switching to linux way back when... i don't remember the thumbnailed apps in enlightenment, but i love the dock implementation, particularly when you have dock magnification maxed out. you get a nice clean representation of your app as you mouse over. how did it work in enlightenment?
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.
It actually took into account the stacking of windows, and would draw a shadow that represented the window's "height above desktop" - so a window that was on top of a large stack of windows would have a severely offset shadow, and one on the bottom of the stack would have a minimally offset shadow.
Also - the shadow-casting onto windows beneath also took into account the relative height differences.
The end result was an *amazing* feel of 3d, on a crappy old 7.14MHz 68000. We should definitely be able to do better on today's marvels.
Something like http://www.freedesktop.org/Standards/menu-spec maybe?
Troll, indeed, but, I'll bite.
RedHat hasn't said Linux is an impossibility on the desktop. They've said it isn't ready now. Of course, that's a judgement call, and presumably RedHat's judgement is strongly influenced by the fact that they haven't been making a profit selling shrink-wrapped RedHat in the consumer channels. (My totally insubstantiated guess is that no one, including Microsoft, makes money selling shrinkwrapped operating systems to consumers. Apple might clear a profit on their annual $129 OS X upgrade, but it's an exception because it is wedded to their hardware market.)
Lots of folks apparently believe RedHat owes something to the Linux community and that they've done a nasty by dropping consumer sales. Well, I suppose they do owe something -- they didn't write all that code themselves. But, that's in the nature of the GPL, which stipulates that RedHat gets to pay off its GPL debt with source code, not by stubbornly staying with a profit-less product.
RedHat is a business. Their obligation to make a profit and pay dividends to their stockholders takes precedence over any alleged loyalty to the Linux community.
What they do with Fedora bears watching. I've been using it since Fedora Core was released and it really is "not bad". If Fedora turns into a really innovative kind of Linux, rather than an easily installed Linux with legible fonts, Good Things may happen.
-- Slashdot: When Public Access TV Says "No"
Your personal, subjective views on Objective-C without supporting materials does not add weight to your proclaiming your stance is fact.
The syntax to Objective-C that draws from Smalltalk-80 flows grammatically and is quite self documenting.
C++ on the other hand isn't designed to be self documenting and doesn't discourage poor grammar practices.
This is true for sharp shadows. But for fuzzy shadows that are being shown here, the correct result from such a diffuse lighting source would be a lighter and wider shadow. It turns out that identical shadows are actually a pretty close emulation because the lightening and widening of the fall-off curve approximately cancel out, and there is obvious speed benefits of implementing them this way.
A simple change to make it more realistic would be to increase the transparency based on the difference in Z. This would improve it far more than changing the width would.
If the "compositing engine" has access to programmable OpenGL shaders there are hacks that can be done that will make very accurate diffuse shadows.
The problem is is that the current implementation of the features in KDE is very inefficient -- lots of hacks, etc to get "transparency" that doesn't work properly a lot of the time. The freedesktop project rocks because it places all of these functions in the compositing level, which means that any x app can use them, without relying on one specific windowmanager. There are lots of performance gains to be had with this new method, as all of the actions are handled once, at the server level, instead of on a toolkit-by-toolkit basis.
Marxism is the opiate of dumbasses