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."
I'll have my eyecandy... (Score:3, Funny)
Slashdot API (Score:3, Funny)
So much for Xouvert... (Score:3, Insightful)
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.
Re:So much for Xouvert... (Score:5, Informative)
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).
Re:So much for Xouvert... (Score:3, Interesting)
Eww, a whole new server? I hope there's more code sharing against XFree86 rather than less.. it would seem a tremendous waste to have to reinvent and maintain that particular wheel.
Even for someone as renowned as Keith.
Re:So much for Xouvert... (Score:5, Informative)
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.
Ok does this new X support my video card? (Score:2)
Re:So much for Xouvert... (Score:3, Informative)
Buggy system (Score:5, Funny)
Bu-dum-chee!
Thank you! Thank you! I'll be here all week! Try the buffet!
But are they doing it right? (Score:5, Insightful)
Re:But are they doing it right? (Score:3, Informative)
I would post the link, but freedesktop is slashdotted.
Re:Who is going to build the composition manager? (Score:5, Interesting)
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.
Re:But are they doing it right? (Score:5, Informative)
We will probably see a lot of window managers get composite managing built in, but there is also likely to be a few compositing only manager, which will work with your favorite window manager.
So in the end it is up to the manager to uo decide how to do the compositing.
Re:But are they doing it right? (Score:2)
I beg to differ: You do not *have to* use hardware acceleration to get good performance if software is done right [slashdot.org]. And from my understanding, the actual
Re:But are they doing it right? (Score:5, Interesting)
For a non-speculative example, OpenGL's glDrawPixels draws rasters from the lower left corner, whereas most UIs like to draw from the upper left. You can change it by calling glPixelZoom( 1.0, -1.0 ), but in many cases this knocked the gl driver from 1-1 pixel mapping into floating point transforms (basically it started using software to scale the image by some floating point value). A few phone calls to nvidia, 3dlabs, sgi, and intergraph later, and their drivers started special-casing for a -1.0 y pixel zoom, and our software sped up by a factor of about 1000.
In the far future of Moore's law we will not have GPUs at all, merely CPUs with power to burn. So in that sense I agree with you that hardware is/will-be not needed. Now I haven't done any graphics programming since machines hit 1ghz, so that far future may be now.
Re:But are they doing it right? (Score:3, Interesting)
In the far future of Moore's law we will not have GPUs at all, merely CPUs with power to burn. So in that sense I agree with you that hardware is/will-be not needed. Now I haven't done any graphics programming since machines hit 1ghz, so that far future may be now.
Actually, from what people at SIGGRAPH kept saying, graphics cards are outpacing Moore's law. If that continues we'll have amazing vector processors and rasterizers with a dinky little CPU telling them what to do.
Re:But are they doing it right? (Score:2)
Yes, they are. (Score:5, Informative)
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.
Re:Yes, they are. (Score:3, Informative)
Also, in Win2K and XP, the selection rectangle has a filled in center that is alpha blended, if the video card supports it - it is done in hardware.
Re:But are they doing it right? (Score:4, Informative)
The current implementation is software only, and
runs at usable speed.
So I expect when we start using the alpha blending hardware, we'll run like a bandit...
Image mirror of translucent X server (Score:4, Informative)
XVideo support? (Score:2, Interesting)
Re:XVideo support? (Score:2)
Good question. I'd also be interested in hearing XP/OS X users answer the same question.
Can anyone comment on this?
Re:XVideo support? (Score:2, Funny)
I can, but not intelligently.
Re:XVideo support? (Score:2)
Re:XVideo support? (Score:2)
Works no trouble under OS X (on a 12" Powerbook, at least). I often do my coding using a transparent terminal, vi and a DVD running underneath.
Cheers,
Ian
enough with the candy! (Score:2, Funny)
If translucent windows can "fatten your brain" (er..?) then is ratpoison [sourceforge.net] the Atkins Diet? Someone else help me out with abusing this metaphor some more.
Re:ratpoison (Score:3, Funny)
long live ratpoison!
Bashers should stop whining and stop contributing (Score:2, Insightful)
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. An
Re:Bashers should stop whining and stop contributi (Score:2)
Of course when the comunity yells loud enough for a particular feature, some determined hacker will eventually act, and things will get done. Look at the amount of noise generated in favor of font anti-aliasing, someone listened, took the time to do it, and now the community has one less thing to bitch about
Grounds for a unified unix gui (Score:2, Redundant)
Re:Grounds for a unified unix gui (Score:5, Informative)
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.
Re:Grounds for a unified unix gui (Score:2)
Ask your average Linux user about the greatest things in Linux. Chances are that maybe 1/10 can be done inside a windowmanager.
Re:Grounds for a unified unix gui (Score:4, Informative)
However, given that it's a good design for a GUI program to communicate with the GUI layer using sockets, then you get the ability to run commands remotely almost for free, with the only extra work required being the security & authentication system.
Re:Grounds for a unified unix gui (Score:3, Interesting)
I'd go and participate in E17 [enlightenment.org]. Enlightenment as a wm rocks, but E17 looks like it's got all of the desktop goodies + the fine wm.
Judging by the amount of time they're spending, they could probably use the help.
Re:Grounds for a unified unix gui (Score:2)
Unless you happen to be running Panther, in which case you *can* have both.
Sounds good... (Score:2, Insightful)
Re:Sounds good... (Score:5, Informative)
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.
Re:Sounds good... (Score:2)
In general, you have to go way out of your way to make a Mac OS X app look fundamentally different from other Mac OS X apps. If you're using the modern frameworks, you can even easily tinge the native interface with your own identity and still look native OS X. You _can_ use a custom framework to make things look completely different (you can also do
Re:Sounds good... (Score:2)
I wish. That'd make my job a lot easier. In fact on Win32 there are multiple versions of the same toolkit. Browse through MSDN some time, and notice how half the controls have special features or replacements that are only available on certain versions or if IE >= whatever is installed.
Toolbars are a good example of that. What is native? The
Re:Sounds good... (Score:2)
The problem is that there are no system menus at all in X. Everything is just
Re:Sounds good... (Score:2)
It's very difficult to implement in practice, but it's an ideal to strive for.
Re:Sounds good... (Score:2)
Still, Linux is all about choice - if you want a consistant feel, you can always stick to only installing apps that use one toolkit or download RedHats Bluecurve or something.
Re:Sounds good... (Score:2)
I've been using Gnome since it first became stable enough to run a terminal, and I've never looked back.
HOWEVER, I run some apps that are KDE-only as well. I've never seen a problem in doing this.
OOo is, IMHO, the klunkiest, least usable of the desktop applications for UNIX/POSIX systems that I've seen (well, ok if you want to compare to ghostview that's another level of unusability). I use Gnumeric when I need to read or write a spre
Re:Sounds good... (Score:2)
Don't screw it up for the rest of us.
Re:Sounds good... (Score:2)
What do you expect? Now, can we all just standardize on English? Can we all just start using Common Lisp for all our programming needs? Can we all start using metric?
You can ask all you want, but really what's the point? Let's deal with the realm of the possible here.
Re:Sounds good... (Score:2)
Re:Sounds good... (Score:2)
Re:Sounds good... (Score:3, Funny)
Guido in a thong. brrrr!
Check your spelling for crying out loud! I nearly benastied myself!
Eyecandy is important :-) (Score:5, Interesting)
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.
Re:Eyecandy is important :-) (Score:2, Insightful)
Re:Eyecandy is important :-) (Score:2)
Yeah, but it's the coolest 4% [wired.com].
Incidentally, what kind of market share does say, Dell have? Or Gateway?
Re:Eyecandy is important :-) (Score:2)
Simon.
Mmmm Candy! (Score:4, Funny)
oh that reminds me of something.... oh yeah! THIS [yimg.com]
alpha blending in x vs wm (Score:4, Interesting)
Re:alpha blending in x vs wm (Score:3, Interesting)
Re:alpha blending in x vs wm (Score:5, Interesting)
Re:alpha blending in x vs wm (Score:3, Informative)
It's not a matter of transparency being implemented at a lower level- transparency isn't really implemented at all at this point.
Re:alpha blending in x vs wm (Score:3, Informative)
Re:alpha blending in x vs wm (Score:2, Informative)
I don't know the answer, but I can make an educated guess. A lot. And I mean a whole crapload faster.
If the server does not support alpha, then the only way wm to blend things is to ask X politely for the background, do the compositing in software, and send it back to X to draw. In fact, in many cases the only "background" you can ask X for is the desktop background, which means that semi-transparent window
Re:alpha blending in x vs wm (Score:3, Informative)
The speed with depend on whether the X server has hardware support for blending.
The prototype doesn't; it is, however, fast enough to be useable even doing it all in software with a Vesa server, so I think we're ok on performance.
Nice, but... (Score:2)
But it seems to me that this will just lead to a more fragmented user environment. X has always had the problem of "applications behaving differently." So now, some are going to support the imaging model, and others won't.
From a user's point-of-view, that sucks.
If you want a killer desktop environment, work on the user interface. Not the imaging model.
Re:Nice, but... (Score:2)
No accelerated drivers?? (Score:2)
Re:No accelerated drivers?? (Score:2)
Re:No accelerated drivers?? (Score:4, Informative)
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...
Slashdotted (Score:5, Funny)
----------
|* |
|* |
|* |
| |
|========|
----------
Mirror Here (Score:4, Informative)
Re:Mirror Here (Score:4, Informative)
http://www.forkqueue.com/freedesktop.org_keithp_sc reenshots/ [forkqueue.com]
Am I the only one? (Score:3, Interesting)
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.
Re:Am I the only one? (Score:2, Interesting)
I cant think of any eye candy advances (in windows XP, lol!) that help my productivity. Even looking at apples amazing new features doesnt impress me. The pseudo 3d user switching effect has already been done on a linux WM (when moving workspaces). Expose etc doesn't seem to give any more advantages than normal abi
fvwm? try icewm (Score:2)
Most people install the distro and use Gnome or KDE. Some may install
Re:Am I the only one? (Score:2)
Unless its a really good reason, I can't go back to aliased-fonts.
And since I read/write text, they are eye-candy I use all the time.
Why KDE and Gnome -reduce- bloat. (Score:5, Insightful)
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 [xmelegance.org]... 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 [gnome.org] either, mind).
That's not eyecandy... (Score:3, Funny)
Anyone know who this is?
If people want things to look and work like Mac OS (Score:5, Insightful)
Re:If people want things to look and work like Mac (Score:2)
use objective C if they haven't got a gun pressed to their heads is a mystery to me.
Re:If people want things to look and work like Mac (Score:3, Informative)
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.
Re:If people want things to look and work like Mac (Score:3, Informative)
they don't like the underlying technology (Score:5, Insightful)
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.
Re:If people want things to look and work like Mac (Score:2, Informative)
Cascading menus... same old same old (Score:2)
When do we get a new screen-size "menu" system that lists all the commands in one convenient overlaid window, just like, well, the Web Site Directory portion on yahoo.com's main page? How about something new and useful ins
Re:Cascading menus... same old same old (Score:2)
Cascading menus aren't ideal, but they provide a way to divide up functionality so that it can be quickly scanned visually by a human.
Re:Cascading menus... same old same old (Score:3, Interesting)
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
All that is missing (Score:2, Interesting)
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 applicatio
Well expert, since you know what to do, DO IT. (Score:2, Insightful)
Re: (Score:2)
Parse and Edit (Score:2)
For example, parsing the content and editing it on the way to the screen. How long before it's used for pop-up advertising?
-kgj
Hardware supported by these development versions? (Score:3, Interesting)
Re:See OSX (Score:3, Funny)
Re:See OSX (Score:3, Insightful)
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
Re:In other news ... (Score:2)
Re:How long before it hits XF86? (Score:5, Informative)
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 [xfree86.org] 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 [cairographics.org] and lots of other exntensions [freedesktop.org]. 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.
Re:How long before it hits XF86? (Score:5, Informative)
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.
Re:Mirror... (Score:2, Funny)
Simon.
Translucency vs. transparency, and depth percept'n (Score:5, Interesting)
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.
Re:Translucency vs. transparency, and depth percep (Score:5, Insightful)
Re:FreeDesktop != GNOME (Score:3, Informative)
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 thei
Ummmm....Yummy Troll!! (Score:3, Insightful)
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 O
Re:Dropshadow bug (Score:3, Interesting)
A simple change to make it more realistic would be to increase the transparency based on the difference in Z. This