Slashdot Mirror
New X Proposal on Freedesktop.org
Bytal writes "Havoc Pennington (of Red Hat and GNOME fame) seems to have a very interesting entry in his blog on the development of a new extension to the venerable X server going on at freedesktop.org. More specifically it seems to provide for most things that people have clamoring for (alpha blending, flicker-free window compositing and switching, as well as even OpenGL integration) without altering the existing X protocol too much."
But did anyone notice that this sounds a lot like Avalon and DX10 in the M$ world?
I'm not flaming what Mr. Pennington is saying, but it does sound awfully similar. Although it will make the X experience a bit nicer, IMO.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
How much is "not too much"? Any modification may be enough to break an existing X application. So what will it break?
Thankfully most of my favourite X applications are open source and actively maintained, so if this takes off I suppose they will be fixed if necessary (or at least fixable). An exception to this would be the old Loki games, which are neither open source nor maintained. I suppose this demonstrates one reason why closed source is bad...
We returned a new 19" monitor the other day because it was native 1600x1200. The text was unreadable at that resolution and lower resolutions simply looked like crap. We replaced it with a 1280x1024 bit but that is still on the small side.
The last time that this was brought up on slashdot, most of the arrogant jerks tried to point out that you can "simply adjust the font size in the control panel". This doesn't work for anyone who has tried it.
Longhorn will take a big step forward in this area. They will be rendering the window system and applying it as a texture so that the DPI of the monitor is irrelevant. X will be light years behind if it doesn't do this first.
Life is the leading cause of death in America.
It's really important for me to be able to get to my PC from the lab (as I am doing now) and run all my apps (thank god for switched networks and gigabit ethernet - I'm using 1100k/sec at present, it used to only be possible to use 16 colour mode 800x600 VNC because of network congestion, now 24 bit desktops forwarded over SSH is fine). As such the biggest reason I wouldn't consider jumping to Apple is the fact that on Linux X 'just works' in a networked environment. I can browse local and remote filesystems with no pain at all, and it's very responsive.
If X is going to get the ability to do OS X's flash graphical tricks (the useful ones at least - functionality before form please) then this will make my desktop experience much more plesant, whilst still giving me a stable and predictable environment wherever I happen to be working. Even if the flash tricks are only available locally (at least until the college upgrades to terrabit ethernet...) it'll still be a pretty big bonus.
Beep beep.
Aqua is based on Display-PDF and is resolution independent. That was a really smart move by Apple because resolution is only going up. Even if there were small problems with resolution being to low on laptops (don't think so) this will go away in the future. All bitmap-oriented window systems will suffer from this design decision increasingly.
At the beginning was at.
You don't understand the X protocol very well. It is actually quite likely that this change could be made without breaking any existing X application. The X protocol is very extensible and well designed in certain ways. This is one of them.
One of the first X protocol extensions was allowing you to have windows that were some shape other than square. It broke no existing X applications at all, and even if it had gone unimplemented until today, that would still be the case.
The X protocol has problems. It is badly designed for WAN links, especially with modern toolkits that draw complicated things for even 'simple' UI elements. Other WAN issues have to do with latency. X really needs a way for toolkits to export some of their drawing functions to the server so they can executed server side. This would fix many latency and protocol verbosity issues.
Need a Python, C++, Unix, Linux develop
What would be really nice is if we could have X11 with integrated audio. There are lots of ways of streaming audio, etc., but that is different.
What I want is that when I log into a remote X11 box using xdm the audio is sent to the local X11 server, just as the video now is. All the processing would be done remotely, and just the video/audio rendering for local hardware would be handled locally.
Best wishes,
Bob
...is all fine and good, but when do we get hot desktops, a la the SunRay environment?
I want to be able to move around my house and just login at any xdm screen without having to shut down the session where I just was, dammit!
Posted with Mozilla
Yes, but how fast can data be read back from video RAM to the processor ? I'm sure some visual effects can be processed by the card itself, but the main processor is also going to need speedy access to that data.
In my (perhaps a little contrived) example, I was using over 64MB of video RAM. I'm sure the majority of people are still using graphics cards with 64MB or less of memory (hard-core gamers being an obvious exception).
Actually, that brings up another question. What does X already support by way of backing-store and save-under memory ? (Excuse me, my memory of X operation is very hazy).
Every X replacement for UNIX has pretty much failed. FAILED. failed.
Why? There is a huge investment in XFree86 in things like drivers. It would take *ages* to implement all of that again.
X was made to be very small, clean, and extensible. It still is today.
"Every X replacement for UNIX has pretty much failed. FAILED. failed."
Thanks in part, no doubt, to people who FUD that those projects will FAIL FAIL YOU'RE ALL DOOMED!
"Why? There is a huge investment in XFree86 in things like drivers. It would take *ages* to implement all of that again."
That something is widely used, alone, is a poor argument for not creating something better. There may be a huge legacy investment in XFree86, but if what Keith Packard says is true, the X project is not accomodating driver updates very well (especially due to the monolithic release nature), which is certainly no way to proceed in the future.
"X was made to be very small, clean, and extensible. It still is today."
X was also designed in an academic environment with wildly different (and smaller) set of requirements than a modern desktop. It doesn't mean shit if X runs great on circa 1995 hardware and window managers.
It's 10 PM. Do you know if you're un-American?
But, why not have the server ask the appropriate client for the necessary window, if needed to do a, *gasp*, software alpha-blend and there being no backing store for it? IOW, just treat backing store as a cache which may or may not be present. Hardware supported alpha blends, of course, *require* both windows to be present.
Then again, I may be talking out of my ass: I've played with X a bit, but am not an X guru, by any means.
You could've hired me.
I have two main workstations that I use daily - my Linux desktop (currently running KDE) and my Windows 2K desktop. I am often having to retrace my steps while on my Win2K box because I try to paste some text and discover that I've forgotten to hit ctrl-c before moving to the next window. I've become used to copying text while selecting it (its not "cut-and-paste" by the way).
Its all dependant on what you're used to. And I have found myself going to some lengths to get my Windows machine to act more like my Linux environment.
Sure, fonts can be scaled just fine. But that's not the only user interface element that needs to be scaled.
....
Here at work, we have several of those IBM T22[01] displays. 24" diagonal with 3840x2400 resolution. I haven't done the math, but I think that's somewhere around 200 ppi. That's way too fine to do everyday work on.
So you scale up the font size. Great. What about images on web pages? What about the size of your scroll bars? What about toolbar buttons? What about
You see the dilemma.
Until there is a display technology like Quartz Extreme or what I hear rumor of in Longhorn (or a proposal like this, which could conceivably scale all X11 content), very high ppi displays are going to suffer serious usability problems.
Yep, X is so bloated that my little Agenda PDA with 8 MB of ram and a slow 66 MHz processor runs it just fine. And it's sharing that memory with a linux OS and a bunch of apps (I'm usually running 3 or 4 X apps at a time on the thing). And yet it's still snappy, despite the slow processor. BTW, this isn't some stripped down version of X -- it's the real deal. Granted, it's not running at a super high resolution, and the screen is a mere 16 shades of gray, but if X were bloated as you say, it wouldn't matter.
For every post, there is an equal and opposite re-post.
Well to be fair it didn't exactly work with window managers that didn't know anything about shaped windows. It didn't cause the WM to not work, but it pretty much caused the managed windows not to be shaped (except I think uwm which didn't reparent windows...). So it could be said to have broken a tiny handful of programs ("almost all X window managers").
It definitly broke as few things as such a change could have though. Just like future changes are unlikely to break anything that doesn't use them except in a lot of cases they will require help from window managers (lest you get partly transparent windows in a fully opaque window border for example)...and I expect there may be a few other places where the new and the old don't interact very well (for example if a second attempt is made at fixing cut and paste).
It is still hard to imagine a scheme where that sort of extention broke nothing though.
The bold font is to make sure respondants like you read at least the most important parts of what I said, but I see from the reply it didn't work.
I'm sorry but you are displaying your total ignorance of the design of X and making completely unjustified and incorrect criticisms in
I'm displaying an ability to make logical inferences. If the authors of StarOffice, OpenOffice, Mozilla, KDE, Gnumeric, and Gimp were all unable to comprehend the X mechanism for clipboard exchange, then it's safe to say that mechanism is either too difficult or too weak to use in a major application. Or are you claiming that the developers of all those projects are stupid and too lazy to make a compatible product?
For a rebuttal, just point me to me one or two famous X11 applications which make correct use of this powerful clipboard, because I can't seem to find any my own.
Please read the design documentation for X before you post about X again.
Frequently X11 defenders fall back to this line, failing to understand that an inability to be comprehensibly documented is itself a design flaw. I have in fact read hundreds of pages of X11R6 documentation, a painful ordeal I have no stomach to repeat soon.
is really as simple as following the very clear guidelines in the excellent explanation by Jamie Zawinski written many years ago.
That's offtopic. The only thing JWZ explains is how to avoid confusing users about "Am I merely selecting text? Or copying it to the clipboard, overwriting previous clipboard contents?" That is not the issue I am complaining about. He only mentions the issue of supporting non-ASCII datatypes in a brief "extra credit" section on content negotiation, where he provides no explanation beyond a reference to some emacs source code. (Humorously, another poster in this thread has held up emacs alongside xterm as examples of major X11 programs that implement the clipboard wrongly)
PS. "Shigoto" means paid work. If someone were paying me, I'd be willing to slog through the ICCCM. For your jibe, I think gekimu would be more appropriate. Although it's attractive to consider arubaito, which (to non-Japanese) brings with it the hyperbolic image of toiling in a death camp.