New X Proposal on Freedesktop.org 395
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."
this sounds like a great idea (Score:4, Insightful)
FreeDesktop.org at SCALE 2x (Score:5, Informative)
For a free exhibit hall pass use the promo code 'free'.
For 50% off a full access pass use the code 'sctek'
Re:FreeDesktop.org at SCALE 2x (Score:3, Funny)
Mirror Early, Mirror Often (Score:3, Informative)
2003-11-03: New X
The freedesktop.org X hacking is low-profile unstableware at the moment, but one particular proposal interests me the most. Here is how I understand it, I'll probably get it wrong:
The idea is to make the X server model-view. The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times. For each window, the default view copies the window's contents over the contents of the parent window. This results in the same user-visible display you have today - but you could implement alpha blended windows by alpha compositing rather than copying each window into its parent, since we now have the parent window's contents.
To this we add the ability for a "compositing manager" to replace the default view for a given window, using the aXe and XDamage extensions. The window manager might be the compositing manager for toplevel windows, for example.
If a window has a compositing manager, it will not be composited into its parent automatically; the window is invisible until the compositing manager does something. An external compositing manager could emulate the default built-in compositing manager by using XCopyArea() (or alpha-aware equivalent) to copy windows into their parents.
However, a more exciting compositing manager might apply embellishments/transformations to the window contents prior to drawing them, possibly drawing them using an API such as OpenGL. For example, you could add drop shadows. Or you could do effects similar to fast user switching or Expose. Or you could double-buffer the entire screen as a whole making workspace-switching, opaque resize, and other tasks flicker free. The compositing manager is rendering a scene in which the window contents are one element, so the possibilities are endless.
Note that the window contents stay entirely on the server side, the compositing manager uses regular X protocol requests to manipulate them.
Apps other than the single compositing manager can also use the damage extension; possible applications include VNC (desktop sharing), magnifiers, pagers with thumbnailing, and so forth. The compositing manager is a special kind of view in that it disables the default paint of the window to its parent, and is thus responsible for replacing that default paint. But there can be any number of extra views of a window.
There are a lot of little complexities and open questions here, but the idea is pretty interesting. I'm waiting for something I can try out to appear in jhbuild so I can make metacity super-leet.
Re:Mirror Early, Mirror Often (Score:2)
without altering existing X protocol "too much"? (Score:3, Interesting)
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...
Re:without altering existing X protocol "too much" (Score:3, Insightful)
Re:without altering existing X protocol "too much" (Score:3, Interesting)
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.
Re:without altering existing X protocol "too much" (Score:3, Interesting)
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 manag
Re:without altering existing X protocol "too much" (Score:5, Informative)
XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.
Re:without altering existing X protocol "too much" (Score:2)
Re:without altering existing X protocol "too much" (Score:3, Informative)
Hmmm... closed source is bad because open source hasn't found a way to support it properly? That doesn't sound right. There will always be proprietary software, and OSS needs to get along with it. Breaking proprietary software all the time is not helping spread the adoption of Linux, because most people do need to rely on at least some proprietary software (even if that is just drivers).
cool, now give me media pipes (Score:4, Insightful)
Re:cool, now give me media pipes (Score:2)
Re:cool, now give me media pipes (Score:5, Insightful)
The only problem with it is that almost all toolkits other than Xlib don't actually support it, so you have to hack around at a low level to use it, but its there, and if toolkit implementors bothered, it would probably become easy to use, too
And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components!
You mean some kind of graphical pipeline, where one application transforms the graphical output of another one, and so on? There are graphic libraries available today that allow this kind of operation, but generally they don't operate well with GUIs (i.e. they run with one window that all of their output goes to). My only question is: what would you do with it? I can see that an ability to shrink or enlarge a window might be handy, but that's a much simpler task than the possibilities of what you're suggesting allow for...
Re:cool, now give me media pipes (Score:2)
How about high-DPI monitor support? (Score:5, Interesting)
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.
Re:How about high-DPI monitor support? (Score:2, Insightful)
Re:How about high-DPI monitor support? (Score:2, Informative)
Re:How about high-DPI monitor support? (Score:5, Informative)
Re:How about high-DPI monitor support? (Score:2)
Even xterm can use non-bitmapped fonts. You can type something likeand there you go.
High ppi displays (Score:3, Interesting)
Here at work, we have several of those IBM T22[01] [theinquirer.net] 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 t
Aqua has this (Display-PDF)! (Score:4, Interesting)
Re:How about high-DPI monitor support? (Score:4, Informative)
However widgets etc. are not generally vector based and thus can look tiny (esp. @ 1600x1200), in this region Longhorn could jump ahead of most free software you use with X. However, all this needs is the toolkit people (GTK, Qt, etc.) to make their toolkits vector based and this will cease to be a problem.
I don't think you deserved your mod points personally.
Re:How about high-DPI monitor support? (Score:4, Interesting)
all this needs is the toolkit people (GTK, Qt, etc.) to make their toolkits vector based
IIRC, SVG icons are starting to be supported by both KDE and Gnome.
More SVG applications and more capable SVG authoring tools could be a really great impetus for migrating X away from the bitmap-centric universe.
Re:How about high-DPI monitor support? (Score:2)
My experience of running X on 1152x900 on a 17" monitor suggests that this is an appropriate resolution that doesn't cause too much issue; 1280x1024 should be more than fine.
I've driven 17" at 1280x1024, and depending on your applications everything works OK. X is a l
Clarifying Vector-based display (Score:5, Informative)
What we're talking about is a VECTOR-based display, so 'increasing the size' won't make it any less readable. In a vector-based system EVERYTHING gets scaled up, you could run the big monitor at 1600x1200 or 512x384 and the elements on the screen would be the same actual size (meaured by a ruler) but the higher-res monitor would just look a hell of a lot better.
Now there ARE some issues that need to get worked out for this, a web browser, for example has to be prepared to have a bitmap GIF 'blown up', and it has to be done well enough to look decent but not take too much CPU power.
NEXT had this, Aqua has the underpinning of it, I think GNUStep is coming along with it, Longhorn is going to have it. I don't see the XFree86 folks picking this up, I think the toolkit folks and KDE/GNOME will have to implement it themselves because the XFree folks are really conservative.
Re:Clarifying Vector-based display (Score:3, Informative)
http://www.cairographics.org/
15" laptop with 1600x1200... (Score:4, Informative)
My experience of running X on 1152x900 on a 17" monitor suggests that this is an appropriate resolution that doesn't cause too much issue; 1280x1024 should be more than fine.
I've driven 17" at 1280x1024, and depending on your applications everything works OK. X is a lot more customisable than MS Windows: you can actually change almost any screen font in use in most situations.
I run an IBM Thinkpad with a 15" screen at 1600x1200. In X Windows, I use the Xft2 font renderer, rather than the old core X font system, for almost every text string I see. Because I have also set the DPI for the screen to 133dpi, everything remains clear and readable and the fonts are all the correct size. So if the original parent poster was struggling with a 19" screen at this res, they should learn to configure their systems better.
The biggest problem I have with high DPI displays is viewing web sites, which will need browser technology to change in order to be useful.
Mozilla provides two useful functions at the moment, and there is another one almost there. Minimum text size is useful to stop the worst excesses of tiny fonts. Text zoom is an essential function on bad websites. Image zoom would be nice, especially if it simply runs in step with text zoom. Some tweaks would then be necessary to stop pages being limited to the 800 pixel width that some designers have decided is the perfect form factor.
SVG also offers improvements for high dpi screens. I look forward to the day that Moz/SVG takes over the web browsing domination and web designers really push vector graphics out there.
Cheers,
Toby Haynes
Re:15" laptop with 1600x1200... (Score:2)
Re:15" laptop with 1600x1200... (Score:3, Insightful)
Meanwhile, Longhorn will do it automatically, and for older apps. I don't want to have to "learn to configure" a system to actually be readable. Heaven forbid I expect it to be well-designed and readable from the start.
Thereby screwing users who like small text and widgets so that they can fit more on the screen.
Configurability is a *good* thing. You can argue about what the defaults ought to be ("default to readable", like "default to secure", is a good catchphrase but defining a set of rules that c
Re:How about high-DPI monitor support? (Score:2)
No, it just needs idiotic web designers to stop hard coding font sizes.
The web *was* perfectly resolution independent until people started coming up with stupidity like "optimised for 800x600" web pages.
Re:How about high-DPI monitor support? (Score:5, Informative)
If using gdm, open
append -dpi 100 or whichever you prefer.
HTH
Re:How about high-DPI monitor support? (Score:2)
Why doesn't adjusting the fonts size from the control panel work? That's what I do, and it works fine for me. I actually want a 3200x2400 monitor so I can use fonts with a larger number of pixels per letter and anti-aliasing, even for the tiny letters I like in my editing and terminal windows.
Re:How about high-DPI monitor support? (Score:5, Funny)
How about monitors that don't suck ass? (Score:2)
If you're talking about an LCD rather than a CRT, I can see where lower resolutions might look worse, but I don't understand how that could be with a CRT. But if you're talking about an LCD that does 1600 x 1200 at 19", I'd sure like to hear about it, because I haven't been able
Re:How about high-DPI monitor support? (Score:2)
That's because you need to bump up the *DPI* appropriately, not the font size. If Windows detects your monitor correctly, then I think it'll do it automatically - but if not a minute or two with a ruler and the Advanced Display Properties screen should get an appropriately scaled display.
Note than s
Re:How about high-DPI monitor support? (Score:2)
Well, I guess not doing something first means doing it (at least) second, at which point for the period of time between the first person doing it and the second (or whatever) they will be behind.
Not ultimately clear, but I got what he meant.
Good idea, but not new (Score:5, Insightful)
This is long overdue in X, and also as stated makes things like alpha blending, and Mac OS-X style openGL window-dragging acceleration much more trivial, and also for those who like network transparency, won't require resending windows each time they become visable (although adds the new problem that unless you are careful you could end up spending lots of time sending updates to non-visable windows). It is of course nessasary to allow some chucking of hidden windows (because full screen 32-bit images still take up quite a lot of room), but overall its a good plan!
Re:Good idea, but not new (Score:5, Informative)
Uh, this idea is called "backing store" and it's been around since, I believe, X11R4. I'm not sure what this proposal does that's new, other than offer new uses for it.
Given the current bloat of GTK and Gnome when trying to run remotely (even over 100Mbit), backing store is a good thing. When an application lets you turn it on. Which GTK doesn't. Heck, I've even seen a GTK developer claim "X doesn't have any backing store concept." Geez, people, learn your existing technology!
Re:Good idea, but not new (Score:2)
Re:Good idea, but not new (Score:3, Interesting)
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 playe
Re:Good idea, but not new (Score:5, Informative)
Keith's new extension is quite different from traditional X backing store; the obvious difference is the ability to control how the windows are composited to the screen. But there are other differences; the server, for instance, uses only a single backing store buffer for the entire toplevel window, instead of one for each subwindow.
Re:GTK bloat (Was:Re:Good idea, but not new) (Score:3, Informative)
But to be honest, the reason is to prevent bloat. Caching pixmaps uses a lot of memory. For a checkbox, there would be six pixmaps cached (foreground and background palettes for active, inactive and disabled states). This lack of caching doesn't cause a problem for simple controls like checkboxes, because redraws are uncommon.
On some themes, I can definitely see a flicker on slower machines
Discussion summary (Score:4, Insightful)
Whine 1: X is slow and bloated we need a replacement.
Response 1: The XFree86 implementation may be slow and bloated and not the protocol.
Response 2: Come up with something better and we'll talk.
Whine 2: Who uses the remote display capability of X anyway?
Response 1: On local displays X uses shared memory and is fast enough.
Response 2: If 5% of the users need the feature it should be retained.
Re:Discussion summary (Score:2)
It's semi-vaporware at the moment due to Mr. Walther getting stuck in a legal quagmire, but check the list mbox and you'll see that development is proceeding along quietly.
Re:Discussion summary (Score:3, Insightful)
Once you start dealing with a few computers, transparent remote display becomes second nature and indispensable.
Much like the virtual desktop concept, transparent remote display is one of those really GREAT features of unixy desktops that lots of people don't use simply because they don't understand how it can work for them. It's an education issue.
Re:Discussion summary (Score:2)
Re:Discussion summary (Score:2)
While Havoc and other informed developers don't whine, the average Slashdotter does. THAT'S the problem.
This would be cool... (Score:4, Interesting)
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.
Extra Memory Usage (Score:5, Informative)
What are the memory implications of this ?
With many people using resolutions of 1280x1024 or 1600x1200 in 24-bit or 32-bit colour, dual-displays and multiple desktops becoming more common, this could chew up a lot of RAM.
A single, maximised window at 1600x1200/32-bit is going to use 7.5MB, even if it's just a terminal window. I can quite easily have 10 windows open at one time, especially when web browsing (OK, not all maximised, but not all small, either). There goes 75MB of RAM, just for the screen display (let alone the extra memory X uses for pixmaps, etc). If it's constantly being accessed in order to update the display, it won't be easily paged out to disk, either.
Things like tabbed browsers and terminal programs help quite a bit (assuming that the contents of each tab won't be stored in RAM - or will they ?). But not everyone likes using them.
Would someone with more knowledge about the current workings of X care to comment ?
Re:Extra Memory Usage (Score:4, Informative)
Re:Extra Memory Usage (Score:2)
Re:Extra Memory Usage (Score:2)
An average, modern-ish desktop PC is probaby going to have at least 256mb ram and a 32mb graphics card. Just because some people don't have the required computer doens't mean work shouldn't be done for those that do.
Re:Extra Memory Usage (Score:2)
Yes yes a new card is cheap etc. etc. But the average user doesn't know how to install a new graphics card! Do you expect your grandma to open her box and install a new graphics card?
Re:Extra Memory Usage (Score:3, Insightful)
Then those users keep on using the "old" X, instead of this "new and improved" version. No-one is forcing them to use this new system, they can go on using the old system as long as they wish. But since there are lots and lots of people who could and would use this new feature, then why not do it? Because there are still some old geezers with vid-cards that have 4MB of RAM in 'em?
Re:Extra Memory Usage (Score:4, Insightful)
No more than I would expect my grandma to update her X Windows library to incorporate new buffering extensions.
Re:Extra Memory Usage (Score:2, Insightful)
Modern video cards are shipping with 128MB standard and 256MB for the high end, and that's likely to increase in the next year, probably to 512MB for the high-end. 64MB is pretty much the low-end today, and you can find 32MB or less on cards here and there, but they're not going to save you much money over the 64MB cards. Some people think it's insane for a graphics card to have that much RAM, but the reali
Re:Extra Memory Usage (Score:4, Interesting)
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).
Re:Extra Memory Usage (Score:3, Insightful)
Now it is true that there are still people using 2MB, 4MB, 6MB, 8MB cards which could benefit from some of these advances, for
Re:Extra Memory Usage (Score:2)
Re:Extra Memory Usage (Score:3, Informative)
The server can simply store the information in the video RAM, where it belongs. As long as the data fits in video mem, it won't cost you any main memory.
Excellent point.
Anyone that's run "top" and exclaimed "Hey! X is using up about XXX MB of memory!" should understand that
Re:Extra Memory Usage (Score:5, Informative)
What are the memory implications of this ?
The reason keithp is going to be buffering each node in the window tree is for memory reasons - buffering entire toplevel windows is far too expensive. It involves two extensions, aXe and XDAMAGE to work correctly. I believe XDAMAGE is partly useful for reducing the work needed to implement eyecandy effects, but it's all new to me too so I'm prolly wrong.
Secondly, MacOS X gets around the memory requirements partly through heavy use of video RAM and partly through compressing and decompressing toplevel windows on the fly (as far as I know). I wouldn't be surprised if the new X team take a similar route.
Finally, I don't think OpenGL will feature in this. OpenGL is a neat 3D API but not so great at 2D work - we seem to be heading towards using XRender as our low-level 2D API with Cairo providing a Quartz style drawing system on top. That doesn't imply speed loss - both OpenGL and XRender are abstractions over the hardware acceleration engines of the card, so there's no reason why XRender based apps could not get the sort of speeds we associate with 3D HW accel (even if today it doesn't reach those speeds). The advantage of going the Xrender route is that it's much easier to mix and match the old style and new style rendering (note how OpenGL requires you to set it up for a particular rect but XRender can just be used as a standard drawing op).
Like I said, no expert, keithp is the canonical source for this, but that's what I've gathered from reading and listening.
Re:Extra Memory Usage (Score:3, Insightful)
I think there is one thing we've learned time and time again -- today's memory considerations become largely irrelevant tomorrow. Yes, someone here mentioned that people today do still have video cards with 8MB or 16MB of video RAM. However, more and more people (largely driven by gaming "needs") are running cards with 128MB, 256MB, etc. A Moore's-esque law is in effect here as well (though not as extreme as with CPU cycles). The cost of adding a bit more RAM
Re:Extra Memory Usage (Score:3, Insightful)
Re:Extra Memory Usage (Score:2)
maybe this is a good place to... (Score:3, Informative)
Not getting into the programming details but AROS is open source Amiga clone I believe having some of this... [aros.org]
Shrug
fixed link Re:maybe this is a good place to... (Score:2)
I also like what freedestop is doing with dbus, as it reminds me of the Amiga IPC usage that AREXX makes use of.
Ill advised (Score:3, Insightful)
This seems to be a band aid solution and complex as well. With OpenGL being so prevalent why not create an X replacement entirely upon it?
Re:Ill advised (Score:2)
Re:Ill advised (Score:2)
Is there a new X logo out as well? (Score:5, Funny)
slashdot.jpg [aaronahles.com]
It's so simple and plain. It just might work!
Re:Is there a new X logo out as well? (Score:2, Funny)
Integrated Audio. (Score:3, Interesting)
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
Re:Integrated Audio. (Score:3, Informative)
Turning X into Quartz (Score:3, Interesting)
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!
Re:Turning X into Quartz (Score:2)
You specify the vncserver as the X server (running on any of your machines) for your applications, and you run a fullscreen xvncviewer on the machine you are sitting in front of to access the vncserver.
It may not be a perfect solution, but it works.
Backing store? (Score:5, Informative)
All I ever wanted from Xwindows... (Score:5, Insightful)
Alpha blending should be miles and miles behind the development of a window system that actually works.
But, this looks to be more typical X development. No brake pedal, but you can shift gears via the steering wheel, the stereo, or a series of buttons on the sunroof; it has 539 airbags, each requiring a different pressure to go off, and there's a seatbelt interface for every previous seatbelt in existance. Plus it has the most efficient 46 horse power engine ever made, even though opening the glove compartment causes it to stall, or at least backfire.
~Wx
Re:All I ever wanted from Xwindows... (Score:3, Insightful)
Cut and paste on X is so b
Re:All I ever wanted from Xwindows... (Score:2)
When you are going to post such shamefull confessions, you should use "post anonymously", that is what it is there for...
There are as many reasons to love X as to love a dead goat (I call her "molly").
Re:All I ever wanted from Xwindows... (Score:5, Informative)
The X11 clipboard is already quite powerful [tronche.com] and supports a broad array of selection types, not just ASCII. A lot of apps only support ASCII, but that's not X11's problem. If any toolkit or app is reinventing the wheel by implementing a whole new clipboard, that really is quite brain-damaged.
Re:All I ever wanted from Xwindows... (Score:4, Informative)
Almost any shortcoming in X11 can be fended off by saying "That's not an X11 problem, it's outside the scope of the design". That's not a valid defense. Complaints like that are a sign that although the design may have been implemented acceptably, the design itself is flawed; the scope was too narrow to account for what's needed by a GUI system.
The practical proof of the quality of an arch is the applications that run on it. And practically, non-ASCII clipboard contents in X11 suck. I've just pulled several major desktop apps off Debian Linux and tested their clipboard compatibility.
You can't paste spreadsheet rows between OpenOffice and Gnumeric. You can't copy an image from Gimp and paste it into OpenOffice, Abiword, Kword, or Gnumeric. (Of those 3, only Gnumeric will recognize that the clipboard has anything in it, but it reads it as ASCII junk). An image will copy from Kword to Kword, but not into Gimp, OpenOffice, or Abiword. For every pair of apps I've tried in the past 10 minutes, none could paste an image between each other. Even copying a picture from Kword to Kspread doesn't work! (You'd think that those applications were written by the same team, and would share clipboard protocols)
The only successful copying of images between different applications that I discovered was, rather bizarrely, from Mozilla into OpenOffice. That one surprised me. (Mozilla to Kword does nothing. Mozilla to Abiword crashes)
Re:All I ever wanted from Xwindows... (Score:3, Interesting)
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 m
Re:All I ever wanted from Xwindows... (Score:3, Insightful)
Re:All I ever wanted from Xwindows... (Score:4, Informative)
Re:All I ever wanted from Xwindows... (Score:3, Informative)
Whenever X11 is discussed, someone brings this up and I give the same reply.
Copy and paste works in X11. It works the same way as MacOS or Windows. You can select text, copy it via a menu item or a keyboard shortcut, select over more text in a different application, and paste in the original text with a menu item or keyboard shortcut. That's it. Pretend there is no middle mouse button and everything will work like you expect.
Now, you're
Re:All I ever wanted from Xwindows... (Score:2)
The problem is that dragging and selecting text is used in GUIs for o
Re:All I ever wanted from Xwindows... (Score:2)
Ummm, the simple solution here would be to use a terminal that supports CC/CV pasting? Gnome Terminal does, and I use it all the time, for the exact reason you've articulated.
The X clipboard does need some more standardised media types, but most of the problems people see with it are buggy or broken apps these days...
Re:All I ever wanted from Xwindows... (Score:2)
Think again. Little is right with the current cut-buffer. Support is not standard accross apps, it confuses select with cut-and-paste, cannot cut non-text objects in any standard way, and on and on..
Re:All I ever wanted from Xwindows... (Score:5, Interesting)
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.
"Compositing" (Score:2)
Venerable? (Score:2, Insightful)
Ray tracing (Score:2)
X Double Buffer Extension (Score:3, Informative)
For an excellent example of how to do double-buffering in X, please read the source code (here) [philou.ch] for the XSpectrum spectrum analyser [philou.ch] (despite its age XSpectrum still runs faster than the newer gspectrum).
Jojo on UI (Score:3, Funny)
From: francis@ircam.fr (Joseph Francis)
I would like to propose that all GUI designers eschew anything actually resembling visible display of an interface, and simply ship a library, and a loose 'conceptual' discussion of what effects the display should provoke, according to a psychological or astrological model of the user's personality (Jungian, Freudian, or Dosteyevskian), their latitutude and longitude, and blood sugar levels. It should be completely up to the user to specify a display (I believe POSEUR is addressing the shipment of design-free GUI design for user-transparent configuration: open, scalable, and extensible, the problem is almost PN complete). Sample KIT (using a paradigm of an application which extracts semantic nets from French Literature in Translation):
1. Parameters: none /Utopia/, and a well-fingered /Neuromancer/
2. Two thick libraries, with enforced single-entry SlowRead(). and a single NoExit() for enforced modularity.
3. Copy of More's
4. One copy of Italian Vogue Summer collection '82
5. Default Interface Processor (DIP) to generate a user-configurable default interface upon which one can generate proposed target 'research' examples.
6. One copy of USA Today and Time (tm) magazine to be used for sample non-default graphical layout guidelines.
+ XYmorph (tm): a new easy-to-use open extensible and scalable system for randomly per/mutating user interfaces. A manifestation of the concept of both stimulated healling and scatter-brain i/o in order to most quickly reach suboptimal interface design with the least amount of effort on the part of the designer or the user.
+ Quagmire: a CD-rom collection of over 4 quadrillion possible interfaces generated for a Unix(tm) open, extensible, and scalable graphical C-shell-feel-good-alike system. Meets ANSI, K&R, A&P, S&H
+ and other stamped standards in continental US.
+ boraX: a user-configurable interface cleanser. Open, extensible, and scalable, it removes all traces of design constraint from simple structured systems and creates flat-design mazelike idio(syncratic/pathic/syncretic) systems of fresh and clean code.
Sample concept discussion:
The pointer (I hesitate to use such a loaded word: for users who object to object orientation and simplistic Western-philosophy views of dichotomatic (not diatomaceous or deciduous, though wooden feelings might be appropriate for Environmentally friendly X displays) subject/object distinctions might prefer to discuss 'object compliment', or even 'compliment' (as in Complimentary beverage or Complimentary sugar-coated dry-roasted 100% genuine Virgina grown goober peas just the way they grew them in olden times) in order to provoke an awareness and create a more extensible scalable and transparent user environment for those who aren't really worried about domain/range distinctions in disjunctive noun mappings) should respond to a click (which is to say a simple tap, of varying duration depending upon the physical capabilities and inclinations of those who might be inclined to acutally depress the open, extensible, and scalable button on a mouse (though those of us who object to laboratory research mechanomorphization of living entities prefer to call 'mice' 'clickers', thus preserving the dignity of what we all must recognize is part of a larger Gaiaen web of life (which is, I must remark, open, scalable, and extensible, life that is, not the mouse) and metonymically convolving form and function into the open, scalable and extensible nomenclature of X).
XBorges.
One longs for the day when the responsibility of programming computers falls squarely on the shoulders of the users, where it belongs; they are provided with a set of infinitely configurable instruction codes, on an open, extensible, and scalable n-bit bus, and their task before setting upo
Re:Excellent! (Score:2, Insightful)
Re:I don't understand the fascination with X (Score:4, Interesting)
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.
Re:I don't understand the fascination with X (Score:3, Interesting)
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 driv
Re:I don't understand the fascination with X (Score:3, Interesting)