Slashdot Mirror
RandR Support on XFree86 4.3
Gentu writes "Great news from our favorite windowing system: [Hewlett-Packard] engineers committed a new extension to XFree86, called RandR. XFree86 4.3 (to be released in late 2002/early 2003), will have the ability to truly resize (not via the pseudo-resize CNTRL+[+/-] command), rotate, reflect and change the refresh rate of each screen of an X display on the fly. And KDE seems to be the first desktop environment to add support for the RandR extension."
Now how will I prove my 3733T skillz?
Overrated / Underrated : Moderation
And it will work?
The statement below is true.
The statement above is false.
Hrm, neat. so what though? What does this really mean? Will it make Linux/BSD closer to being "ready for the desktop?" How is this going to affect your average user?
Keith Packard provided GNOME patches a couple weeks ago.
ChangeLogs:
2002-10-04 Havoc Pennington
* src/display.c (event_callback): do XRRUpdateConfiguration()
if we have RandR extension, else poke in Xlib's screen struct to
update the screen size.
* configure.in: fix a bogus overwrite of cppflags,
add a check for RandR extension
2002-10-07 Mark McLoughlin
Support RandR extension by resizing the toplevel panels
if the screen size has changed. Based on patch from
Keith Packard - #94561. Requires gtk+ HEAD.
* basep-widget.[ch]: (basep_widget_screen_size_changed):
* foobar-widget.[ch]: (foobar_widget_screen_size_changed):
resize the toplevels when the screen size changed.
* multiscreen-stuff.c:
(multiscreen_screen_size_changed): re-initialise and request
a resize on the toplevels.
(multiscreen_support_init): connect to the "size_changed"
signal on all screens.
(multiscreen_reinit): re-initialise the monitor geometries.
I would like to be able to redirect running xwindows applications. Let's say I am running a copy of bzFlag, or some other type of productivity application. Wouldn't it be good to be able to transfer the running application to a different computer if I suddenly have to change terminals?
Is changing bpp on-the-fly also covered by this new (très cool) extension? I skimmed through the announcement but could not find anything about this. Anybody know if color depth switching is planned?
Reminder: find a new sig
The rotation is for people with pivoting monitors which can swap between landscape and portait views, I assume.
Mirroring may be reflection, but it could also be mirrored video for multihead setups.
It brings new life to tired, old, porn?
X is a lot better than many competing efforts. For starters, it works, is in wide distribution, and has a huge suite of apps. Unlike, say, Berlin, or any of the other "Let's replace X" projects (Berlin, to its credit, at least works. Most alternatives are SourceForgeWare with a few Beavis and Buttheads dissing X withou anything to replace it).
X gives you a base. You can reimplement everything X already does to get the features X doesn't have, or you can implement extensions to X, or rewrite core parts, to correct the faults X has. Guess which is less work?
> Is faults seeem to overshadow its many features.
Well, that sounds like pretty gratuitous judgement to me. Would you please care to enumerate 'Is faults'[sic] ?
X might not be perfect, but it does the job. We can't allways break things so they get better easily.
Propose a better solution, implement it, make an easy migration path, become rich and popular and get all the chicks. (That's the Profit!!! part)
A message from the system administrator: 'I've upped my priority. Now up yours.'
IF your monitor was on it's side it could be pretty handy. Also if you were using a mirror to view you screen it could be useful too.
I'm not saying most people will do this, but most people don't run multiple monitors either.
Life is too short to proofread.
What a rip off! Turns out this rotate feature is not a free rotate but fixed 90 degree increments!
Pfff! And I wanted to have my aterm at a weird angle.
graspee
Why do these "when will we replace X" trolls resurface every time there is an X story? And why do people keep modding them up?
So far, we have great 3D acceleration, direct video, anti-aliasing, and now dynamic sizing/resizing in X. And all with excellent performance that is equal to or better than the performance offered by Windows. And we retain the network-centric features and flexible, modular configuration that make X so powerful. And all of this while maintaining backward compatibility over a decade-and-a-half of software.
We'll replace X when it makes sense to do so and not before. Right now, there is no better (or even close to equal) solution.
STOP . AMERICA . NOW
How did this comment get to a 5? This person does not understand software development. If you need some more information on why we should not "replace the X windowing system alltogether", read this.
What does Mac OS X use? Something different. Maybe we (the rest of the *nix world) should see HOW MUCH they gained from doing that - it may be that rewriting a lot of apps (or doing some sort of backwards compatibility mode) would be worth it.
My server
This would be incredibly useful in situations with LCD projectors projecting from behind the screen, so everything has to be mirrored for it to appear correct to people viewing it from the front
They (essentially) use Display PDF, an evolution of Display PostScript. There is no X server. What they gain from that is, well, a pretty GUI. One that does not have many of the useful features of X (no remote windowing, which matters when you're seling Xserves). More importantly, it has none of the X software, which means people have had to hack a working X server onto the platform - Apple refuse to - and run them there. If all you want are the pretty effects you can get from Display PDF, you can go contribute to one of the projects adding Display PostScript to X. There's not much that uses it, but you can have it.
Which means Apple may have a Unixish personality of their Mach core, but out of the box, no Unix GUI tools work.
And if you think Apple, who routinely sue people for producing OS X look-a-like themes would stand for you cloning the Quartz API, you can pass me some of whatever you've got.
Finally X is getting the same features that most other operating systems have had for a decade... It may sound small, but these are the things that make systems easier to use for the average joe, and goes a long way in usability.
You'll note if you read some of the correspondence around this that various members of the GNOME team (and presumably KDE) are adding a control-centre gadget to do exactly that.
When, oh God, when, will people RTFA,
...fuckin' kids these days...
or just the post, for christsakes.
The feature you're asking for is exactly
what this extention allows.
Don't become a regular here -- you will become retarded.
I think that the long life of X speaks to how well it actually was designed. The modularity of the X core has allowed for over a decade of innovation to occur WITHOUT hindering backwards compatibility. Can you say that about the past 10 years of any MS code base?
1) dialog
2) kcontrolmodule
3) notification
4) popup
Your WM will want to understand it, and your toolkit should understand it. But if you read the paper, you'll see they have solutions to help apps that are unfamiliar with the extension cope with their world changing underneath them.
I can still see Gnome and KDE menus paint across the screen chunkily -- yes, this is on a P-4 machine with whizzy graphics cards, a gig of RAM, etc.
Perhaps your setup is faulty. On my system (Athlon 900 with 1GB of RAM - granted I have a GeForce 4...) the KDE menu pops in, with no redraw at all. And this is in 1600x1200, 24bpp.
Honestly, XFree86 has never seemed slow to me. It does seem to be the weak link as far as system stability is concerned, though: X has been involved in nearly every one of the (few) system hangs I've experienced.
Reminder: find a new sig
I then reclicked it, and there is no perceptable painting whatsoever. It's either there or it isn't. I can click over and over on it, and it pops back and forth (if I do it quick enough, I get a flicker effect and I think I can see where it is painting, but I'm not sure if it's just a optical effect of flipping back and forth).
KDE caches it's menu, and does a rebuild when you click it after n seconds of activity (the value is in a Properties panel somewhere, iirc). My guess is that the "repainting" is actually KDE rebuilding its menu after a period of inactivity.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
You obviously don't know what you're doing, have misconfigured, etc.
I have a set of boring-ass old PII/400 workstations with 128MB memory here running original GeForce256 cards using the NVidia driver. Everything in KDE -- window decorations, menus, anti-aliased text, scrolling content -- draws instantly, just as it does in Windows. There is none of the 'paint across the screen chunkily' problem you describe. Maybe it actually is the drivers. Did you ever think of that?
And on this same network, there are two headless Slackware 8 servers on which I often log in to KDE remotely. This is only a 10 megabit network and yet the KDE desktop works wonderfully; there are no real slowdowns whatsoever compared to the Citrix clients I've used elsewhere on the campus network.
Something is clearly broken on your setup.
STOP . AMERICA . NOW
Reasons why this is good:
Applications that work best in a specific resolution or color depth. Particular examples are any games; Most 3D games, such as Unreal Tournament or Quake 3, give you the option of changing the resolution or color depth; the obvious advantage to this is that if you have a low-end video card, setting the resolution and color depth low will increase the framerate. If you have a high end video card, you obviously will want a higher resolution for greater detail. I keep my desktop at 1280x960, but prefer to run games in 1024x768 with Quincunx antialiasing (I have a GeForce 3).
Another important application is web design. A well-designed web site should look good at any resolution; however, since one can't intuitively know how a page will look at every resolution, when designing a page it is convenient to change your resolution on the fly and take a look at it.
And then, of course, you have applications that *require* a specific resolution. This isn't as much of a problem with UNIX, but in the Windows world you will likely encounter programs designed for older setups that will fail to run if you don't have a specific bit depth or resolution. Even some more recent applications have this restriction; for example, the Windows SNES emulator zSNES requires that you run it with 16-bit color depth (at least, it did the last time I checked). Starcraft requires that it run at 640x480.
So, just because you don't have any reason for this, don't say it's useless. I've been wanting this feature for ages.
Karma: Terrifying (mostly affected by atrocities you've committed)
"and now dynamic sizing/resizing in X."
Everyone is treating this like it's some super great accomplishment. Windows has allowed this since Windows 95, and the Mac since System 7.x.
Well, not exactly... What we're saying is that all the faults in useability/functionality that you may have been able to say X had are slowly and surely being whacked out. That they happen without disruption at all in compatability is a sign that there is no fundamental reason for these flaws, they are simply there because they haven't been done yet.
True, but when Windows Terminal Server came out, that takes a back seat. Try running an X11 session over a slow network link vs. a Windows terminal server session (especially over Citrix ICA) and let me know how it goes.
Depends... are we running it through ssh, telnet, or vnc? Vnc sessions are about as snappy as TS (minus the unfortunate remotely-rendered mouse of vnc). Of course Vnc suffers from the same advantage as TS, which is that it can render everything locally and compress and transmit the results.
But certainly X could use improvement in this area. That doesn't mean it won't come, or that we need to -start over-. It could be as simple as another extension.
The enemies of Democracy are
Cut and paste has been fixed for years. Buttons aren't X's problem. If you have a problem with the button focusing behavior of your desktop, file a bug report.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
For example, you should be able to tell an application running on your handheld computer to use a nearby desktop display, keyboard and mouse, or a projector on the wall. This should not require stopping and starting the application. You should be able to go home, and decide to import applications you left running at work. There are obviously security, authentication and authorization problems left to work out, but these are generally independent of the base window system.
Holly network is the computer, Batman! I gotta think about that one, but I'm sure it will not be comming to platforms that are still trying to extort per seat licensing and worry about more than one person running a word processor at one time. How's that for "ready" for the desktop"?
MMM, don't like frame buffer, it's been slow. The article talks about this frame buffer being faster than other frame buffers, but that does not make it as good as non frame fuffered servers, no?
Thinking over. Your turn.
Friends don't help friends install M$ junk.
Actually, I think it just shows that up till now, it's not really been that much of a required feature...
But now that we have more and more normal desktop users at least considering Linux, it's become more pressing.
I think you'll find that from deciding to do the work, to actually finishing did not take very long at all, in the scheme of things....
Advanced users are users too!
Dude, you've got it all wrong. People often say that Quartz is almost like Display Postscript, but it's not at all. Display Postscript involved creating actual postscript code and sending it to a postscript intepretor for display on the screen. Quartz does not do that. However, it does share almost the same exact API as Display Postscript did, so I can understand the confusion.
Anyhow, Display Postscript was not intended to be an extension to X11, that came AFTER it was implemented on NeXT. Remember OpenStep on Sun and HP, thise systems only had Xwindows, so a XDPS system was needed for them only.
Another point, XRender works very similarly to how Quartz does. That is, clients draw in a pixmap and ask the Server to draw it (vs. asking the Server to just draw it). The WindowServer in OS X is kinda like a XRender only X11. Drawing commands are not sent to the WindowServer, only the client's pixmap of what their windows should contain is "sent" (shared really) to the Server. Hence, a lightwieght Window Manager.
Mirroring support... I can imagine the pranks already...
Unsuspecting boss: Eeeeek! My computer just got a virus! Fix it!
Me: Sure... [types a command]... all fixed.
Boss: That was amazing! What would I ever do without you?
Me: About that raise I was asking about...
I'd really love to run XaoS in 8-bit mode and use colour cycling while still having a 32-bit visual
for everything else. Is this good enough for that?
-- Tom Rathborne
I find it amazing to be reading posts from people whose memory of computers start at 95B. The original 95 required a reboot after a screen change, slick...just like every version of Windows before it.
I can see why this kind of feature would be important for Windows users. Afterall, if you had to reboot every time you changed your resolution you'd never get anything done.
Cut and paste faults are BUGS in individual applications or toolkits. The XFree86 maintainers cannot fix these bugs by changing X, because X already does the right thing.
/really/ care.
In every serious X app you should be able to do both of the following:
1) Cut, Copy and Paste things through the system clipboard using menu options, keyboard shortcuts etc. as appropriate. e.g. Ctrl-X for cut in most GNOME, KDE apps. This works almost exactly like Windows.
2) Quick copy using the middle mouse button, select text in any application, then press the middle mouse button to paste that text in any other application.
If they don't work in your favourite apps, check for a new version. If that doesn't work either, file a bug, post to the mailing list, write to your democratic representative or complain ABOUT THE SPECIFIC APP on Slashdot. If you aren't specific no-one can help you.
Caveats:
Old KDE (pre 3.0) and Qt (ditto) apps (e.g. Opera and many installs of KOffice) don't work because Trolltech screwed up. Upgrade
Venerable old xterm doesn't have Cut/Copy/Paste menu items (most users don't even know it has a menu) so you can't use the clipboard only the fast copy feature. Use one of the many other modern terminal apps if you
Earlier (e.g. few months old) stable releases of Gnumeric make the same mistake as Qt2.x. Upgrade to the latest release.
GNU Emacs (but not XEmacs) has totally bizarre clipboard behaviour unrelated to any standard, principle or sense of reason. Use XEmacs or complain to your favourite Emacs maintainer.
XML causes global warming.
Coders everywhere can always use more R&R. This means we won't have to offer additional vacation time.
Which means Apple may have a Unixish personality of their Mach core, but out of the box, no Unix GUI tools work.
Good point. The Mac has no GUI tools and Unix's GUI tools are world-renowned. Mac users are clamoring to use those Unix GUI tools. or was that vice versa?
cpeterso
This extension, together with other X11 features, has a much grander vision: letting applications move seamlessly across displays and devices. This requires defining standard protocols by which different implementations can interoperate and communicate. It also means coming up with standards that work across a wide range of devices.
I frankly don't know when, or even whether, X11 will be able to deliver on this vision--it's hard and there is still a lot of work left. But I do know that few other systems are even trying, and that functionally, X11 is already far ahead of the alternatives. For all their visual glitz, Windows and MacOS, for example, are just minor variations on the "applications running on my desktop" theme.
But, I think its impact is being overblown, at the cost of ignoring features which have existed in Xfree86 (and X11 in general) for some time.
Of course, changing the display resolution itself has always been possible using control-alt-+/-, but without resizing the desktop.
Full screen games can run at any resolution and color depth supported by the hardware, and included in the XF86Config file, regardless of the desktop resolution, on almost any recent card, if the program itself supports the existing DGA extensions.
Real-time mode line (ie, refresh rate, dot clock, etc.) tweaking has always been possible with xvidtune and other utilities (the very nice PowerDesk tool with Matrox cards, for instance, which is GPL'd).
What this does is allow resizing (and less significantly, rotation, reflection, and other similar permutations) of the desktop itself without restarting the X11 server.
Moreover, this does not automatically mean that an easy to use Windows-style control applet will exist--this is a separate task, as it should be in the Unix tradition, but one which these extensions will make closer to possibility (notwithstanding, I can't see why some tool like this hasn't been developed already by one of the large commercial distributions using functionality already present--see the PowerDesk applet I mentioned above for an example of how this should work).
"(Man) tries to live his own life as if he were telling a story. But you have to choose: live or tell." --Sartre
The Mac solved a much simpler problem: given a proprietary GUI toolkit running on a single machine, let people rotate the screen. You can do that with a quick hack.
X11 is a protocol, not an implementation. People can't just go in, hack the XFree86 implementation, and be done with it. If you add something to X11, it needs to be defined, discussed, and then implemented. People need to think about lots of different kinds of possible hardware and scenarios. That takes time.
When will somebody free the world of X11 and write a light-weight fast and efficient graphics layer for Linux,
Have you done a "ps" on your Mac lately? Have you done any kind of graphics benchmarks? X11 runs rings around the Macintosh display system, both in terms of performance and in terms of memory footprint.
but I strongly believe 2/3 of the functionality of the X11 architecure is just a big waste of time and disk space
Oh, and what functionality would that be? Please tell us.
Besides, do you think that putting a PDF or Postscript interpreter into the display server is the epitomy of efficient design?
and now dynamic sizing/resizing in X.
Everyone is treating this like it's some super great accomplishment. Windows has allowed this since Windows 95, and the Mac since System 7.x.
Windows has never had -- and still doesn't -- rotation, which the XRandR also provides. Cool, now I can tilt my monitor on its side and view things in portrait mode.
The Mac supported this with certain display hardware (the Radius Pivot comes to mind), but most Mac hardware (of System 7 vintage, anyway) didn't support any resizing, dynamic or otherwise.
I can click the [Windows] start menu and it draws instantly. I can still see Gnome and KDE menus paint across the screen chunkily -- yes, this is on a P-4 machine with whizzy graphics cards, a gig of RAM, etc.
Then something is seriously fucked up with your Linux/X server configuration. I'm typing this on a P-III 550 with 512 MB RAM and a Matrox 200 graphics card, and "instant" is the word I'd use for the graphics. On a P-166 with 64MB and cheap S3 ViRGE graphics, it's a little slower to start drawing a menu, but once it does start the menu appears quickly, none of this "chunkily" stuff.
Makes you wonder why all those thin clients that boot Linux + X11 do it not to connect to an X server, but to run Citrix's ICA client for Linux to connect to a Windows 2000 server.
Umm, maybe because Windows 2000 server doesn't speak X Windows? (So, how do I set the DISPLAY variable in Win2K?)
-- Alastair
Rotation is used, for example, on the iPAQ PDA,
so that you can choose either landscape or
portrait mode. It is also useful on tablets,
some other circumstances.
Keith and I discussed mirroring when we originally
designed RandR, but couldn't come up with a
plausible need.
Then at a conference, someone came up to me and
said they wanted to implement a Heads-UP display
using a Laptop on their dashboard.
I said: "Sold!".
So we implemented it.
- Jim
I see, it is somewhat confusing because most people have never used a lightweight window manager. OS X has a 20K process called "Window Manager", all it knows how to do is keep track of where windows are, where the mouse is, keystrokes, etc. It is the clients responsibility to actually draw stuff. The client asks the Window Manager for a shared piece of memory to draw to. When the client is done it tells the server and the server then blits this pixmap and keeps it in memory for later use (double buffering). This is basically what Xrender does. Note that it is the client which also draws the window frame, decorations, etc, there is no "Window Manager" like there is on X11.
Now, the clients do have access to PDF intepreters, but they run in the client only. no "code" is sent to the server. This is the fastest way to do this. ala XRender stuff. Of course, this type of graphics system does not work with remote connections.
I thought XRender prevented remote display functionality?
X11 is ok, but something like quartz does it so much smaller, simpler, and faster.
OK, maybe there is something wrong with me, but all I can think of with rotate and resize is the following:
:-)
Rotate screen to view centerfold...
Resize pants.
I'm a bad bad person.
fair.org counterpunch.com truthout.com indymedia.org salon.com
eff.org guerrilla.net debian.org gentoo.org
-1 Redundant
+1 Well Deserved
Do you have a habit of smoking somethign when you use X?
I'm typing this on a Dell Inspiron 7000. Pentium 333, 190 MB ram, 4 MB ATI video card. Both Windows and X take a second to read the menus and render them the first time, but that time is nearly equivilant. Afterwards, X renders instantly.
However, I don't notice a load-time on my other machine (XP 2000+, 768 MB DDR, MSI GeForce4 Ti 4400).
Are you running an old version of Nautilus? I don't think even that would do it, but that's all I can think of.
Sure, like everything, X has it's problems, but I prefer flexibility and configurability over the simplistic, inflexible crap from Microsoft that passes as a desktop.
~Dalcius
Rome wasn't burnt in a day.
A very good article, but there are a couple of points I would like to make:
Free software development has a different set of standards to work by than commercial software. What this article says is probably true for commercial software, but there the motivation is to make it work and sell it. Free software is different in that selling isn't a factor. Usage is nice, but the most skilled open source programmers are artists. And it shows! We may not have produced a full MSOffice clone, but I'm writting this from a Linux box in Galeon, using Mozilla. I don't have Windows on my machine, and don't want it - Linux is an excellent system. Mozilla is a tremendous piece of work - in my estimation, the rewrite has done a lot of good. Yes we had to wait, but in the end it produced results.
Maybe the results are not so good for Netscape the company, but Netscape the browser is a lot better off. In free software, the program means more than the company, which is a very foreign mindframe to corporate types. Understandable.
But that's why people are interested in a total redesign of X - we don't have to care whether or not it takes five years or ten, whether we will have enough market share to pay costs. It's developed as a hobby by people who love doing it. We aren't sweating timelines or market share. Berlin is very slow, and may or may not ever replace X, but so what? They like developing it, it undoubtedly has advantages and flexibility, and may someday change the world of free software. Same with GNU Hurd or EROS. Totally cool ideas, total rewrites of everything, not fully developed but really neat and potentially very useful.
So while it wouldn't make sense IN A COMMERCIAL SETTING to replace X, in the artistic world of free software it does. And since both X and whatever replaces it can be maintained and work together (Both DirectFB and Quartz can handle X running alongside them, for example, and if Berlin can't yet it will surely be able to) we can be backwards compatible and functional while reaching for the stars feature and style wise.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
It's also possible that people may want to run XMAME and other such emulators on a monitor which has been rotated and placed inside a cabinet (or other display mount). While XMAME and other emulators may allow games to be rotated during emulation (usually one of the game's options), by allowing X to rotate the screen, it wouldn't depend on the emulated game to provide the rotation and it would provide consistancy among game orientations.
...and that's the way the cookie crumbles.
Anyway it was the boss's birthday and the night before he carefully locked his office and set traps in the door so he could tell if anyone had been in .... the next morning he comes in, everything seems OK, he checks the door, his chair, his desk, doesn't find anything ... sits down to work with his computer .... nolthing happens .... about 1/2 an hour later he realises his screen is slowly getting greener and greener ... aha he thinks looks in his system folder, removes a couple of suspicious INITs and reboots, it comes right ..... about 1/2 and hour later kit starts going green again .... he pulls some more stuff, reboots again, but no luck .... he's just about to reformat his disk and reload the OS when lunch came around and we explained ....
Of course reloading everything wouldn't have done him any good ... we'd burned him a custom ROM for his graphics card
In that sort of world, it's a lot easier to specify how big you want things to be than to specify how many pixels anything should be.
There are a lot of people whining about X (myself included). Most people say X is (take your pick) bloated, slow, obsolete, inefficient, or hopeless. Now some of these individual claims may have some truth to them, but the fact is that X despite its knarliness, works, and it works today. There isn't any real alternative, and it can continue to be extended for a long time.
But people who say such things about X are missing the point. X is ugly, in the same way that x86 is ugly. I think the analogy is a very apt one. Both are rather old designs, both are the most prevalent, both have had to be extended numerous times (and successfully), and both work, and work quite well. But neither one will get any design awards: the only thing we're doing at this point with either of these is leveraging the existing code base (i.e., the millions of x86 binaries on the one hand and X applications on the other) and avoiding duplication of past work by building something from scratch. And frankly, I think both are beginning to reach the end of the line: the further we go, the more effort we need to expend for an increasingly marginal return.
For the x86 example, Intel perceives this, and wants to jump ship now, even though its replacement is not as robust, fast, or powerful as its last top of the line. Once again, people who point this fact out are missing the point: Intel is laying down a roadmap, to service a broader goal of an architecture it can grow with for the next decade or more.
Why can't we do the same with X? It's going to get harder and harder to grow with X, so lets lay some groundwork now for a window system we can grow with for the next decade or more.
I am shocked and amazed that more comments are not mentioning Berlin, that is, Fresco. Do people not know about this? This is the only project I've found that has half a chance of being a suitable replacement for X. There's a framework there, a coherent vision, and even a basic running system. This isn't vapor, folks, or are these people a bunch of anti-X whiners with no code to back up their pointless bitching. They're not FUD-mongers; at least listen to their well-balanced (I think) justification as to why they're working on this project. It's quite easy to see that they're not at all motivated by hatred of X, but by a desire to design an elegant and network-transparent window system.
Why don't we have more of that nowadays? Half the OSS movement seems to be driven by hatred of Microsoft (or simply closed-source software), rather than love of elegant, useful, robust code born of honest work. At some point someone is going to have to worry about more than simply getting things done as quickly as possible, be-damned-how-it-works, and think more about design and the way things should be. The former type of attitude breeds stuff like MS Windows. Is that really what you want your windowing system to become? If something isn't done before long, X is going to be just like Windows: pasted and taped together and building on a merely serviceable codebase. This, I think, would be a great injustice to X. Let it die a peaceful and honorable death now, rather than a violent and hate-filled one later when it becomes so horrible, so monstrous, that the issue of replacing it is forced upon us and we throw its head on the guillotine.
Remember that at its inception X itself was merely a design framework by people who wanted to do a windowing system the right way. That X has served so well for so long is a testament to that foresight. But please, let us have the foresight to know when to design something new on that same basis, learning from what we have done. A rejection of the code does not mean a rejection of the vision or of the talent that bore that code.
Who cares who did it first.
What's important is that both KDE and Gnome will be able to support this feature in the next 0.x version, which is great!
This isn't a friggen pissing contest...
"Can of worms? The can is open... the worms are everywhere."
Hey Limey, next time the Germans want to invade your asses we're gonna let 'em!
Um, if I were a limey, I would be using metric. Americans are the only people still using Imperial units like inches.
You could do every single one of the things you mentioned with DGA in XFree86 4.0 already.
Of course, you can't run in a windowed mode, but if you're running a game, it's a fair bet that you aren't running windowed.
May we never see th
However, centuries passed (of computer time, which is rapider than the Julian calendar) before this fundamental capability appeared. Microsoft Windows(tm) has done this since 1996 (or earlier?). Apple surely did it long before. The fact that it took so long led me to doubt the soundness of the X11 system design- either no one else noticed those obvious deficienies (unlikely!), or the vast complexity of the protocol prohibited the creation of new functionality without the developer first learning each little secret of the large xfree86 codebase.
We now see that the latter interpretation was somewhat correct, as this paper explains that the creation of RandR was possible only due to new software (TinyX, etc) that isolated the RandR guys from needing to deal with all of the complexities of X itself. Of course, the relentless increase in processing speed (fruit of Moore's Observation) helped too.
I hope that changes like this have "lowered the hackivation energy" enough so that XFree86 can quickly get some other useful improvements added- within a short time, it might be possible to regain a little Wow Factor over the Microsoft and Apple GUI interfaces. I'll list some improvements I'd like to see. The RandR writeup mentioned some of these, hopefully the same team is already planning work on them) Others of these things can be done already, but with awkward, unstable configurations, or through VNC. We need these capabilities in popular linux distributions, and without VNC's least-common-denominator slowness.
- Migrate a program from one Xserver to another We should be able to use a utility program or a window-manager icon to select a window to send elsewhere. This should be possible from a remote command line login as well (so that if I wander into another person's office I can show him either a single program I'm running, or my whole desktop). It should be your option whether or not the program permantently relocates to the new server (or returns when the window is dismissed). This brings up another feature,
- Run the same program on multiple X displays aka xfork. Operator's choice as to whether the remote display is read-only, or also accepts input. The default should be read-only, unless the toolkit has coded support for this feature, in which case it should default to allowing the remote to provided logically read-only input only (scroll around in the window, but not change the document).
- Lock your desktop without locking the Xserver When I run xlock, it shouldn't only allow MY password to reactivate the display- other persons should be able to walk over and login as well. I can either wait for her turn to be up, or find another Xserver and use the above features to migrate my display to my new desk. This is a natural match for X11's capabilities, but one that Microsoft got last year. *nix has to catch up quick!
- Dynamically reassign input devices Now that a user can change his resolution without restarting X, he should be able to do the same with his input devices. Boot your computer without having any mice installed, get to X, run mozilla to see a web-page on how to configure your Wacom table, and get that working, without needing to restart. (Linux does this to some extent with things like symlinks in
/dev and the /dev/input/mice devices, but it could be better).
- Resurrect the multi-headed display In ancient times, one computer would run 16 interactive sessions on terminals attached to its serial ports. Those capabilities were lost as displays became more complicated and PCs and fat clients emerged. But now, with the rise of USB peripherals and multiple active PCI video cards, commidity hardware could again support this functionality. On an Athlon 1500, I should be able to install a 2nd video card, 2 usb mice, and one usb keyboard, and get a fully independent GUI desktop. (Yes, this usage is a geek stunt- its real-life utility will be bounded by the length of a VGA cable)
- Support joysticks in X This should be an easy one, right guys?
- And many more Any ideas?
An interesting consequence of some changes like this is that users might tend to leave X11 programs running for weeks at a time, with virtual memory becoming like a form of application serialization/persistence. That could have negative implications for efficiency and design. ("Oh, I don't need to put XMMS in my startup folder, I just left it running from last year")(I've heard Microsoft's Netmeeting software does something like this. Probably just a screen scraper, but still a workable feature.)
An application would define a property, WM_MENU, on any window that needs a menu. The property would be a list of menu items, each similar to the structs used in just about every windowing system, and allowing recursive definitions of other menus by pointing to other window properties. Applications wouldn't have to respond to the menu events, only to the final selection. The advantages would be many.
- Applications could be smaller, since they won't have to manage the menus.
- Applications, especially those running remotely from the display server, would seem more responsive to the user because the menu would be handled locally.
- Best of all, window managers could offer more choice in menu bars.
Right now, every X11-based system has to use Microsoft's look-and-feel for application menus. If the WM handled menus, the WM could offer choices, such as putting the menu bar along the top of the display. Or by changing one preference, you could implement pie-menus in all of your applications. Or someone could come up with something even better!Nothing for 6-digit uids?