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."

Comments

this sounds like a great idea

[fizz]

its about time someone does some decent work on the actuyal framework of the xserver, because right now, most limitations are not due to the window manager, rather the server.

FreeDesktop.org at SCALE 2x

[irabinovitch]

Seth Nickell will be speaking about the freedesktop.org project and his work with GNOME.org at the Southern California Linux Expo on November 22, 2003. SCALE 2003 will be held at the Los Angeles Convention Center. More information is available on their website at http://www.socallinuxexpo.org

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

[Mitchell Mebane]

Heh. For a moment there, I thought you meant FreeDesktop.org's X would be getting Scale2x support. :P

Mirror Early, Mirror Often

[Scalli0n]

For your enjoyment in case this server is /.'ed:

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.

without altering existing X protocol "too much"?

[lplatypus]

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...

cool, now give me media pipes

[ikoleverhate]

cool! decent opengl integration will make all those little flashy transitons and funny shaped windows that mac users have a snap to implement! x finally becomes less about boring rectangles, and becomes truly fun to hack ;) Lets hope this gets support from enough different groups to make it a standard. And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components! (ok i'll go back to dreaming)

Re:cool, now give me media pipes

[julesh]

X already supports funny shaped windows. Have you never run xeyes?

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:without altering existing X protocol "too much"

[Short Circuit]

Assuming xlib isn't statically linked, I don't think there'll be too much of a problem. I'd even venture a guess that simpler applications wouldn't be affected at all.

How about high-DPI monitor support?

[swordboy]

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.

Re:How about high-DPI monitor support?

[ikoleverhate]

>They will be rendering the window system and applying it as a texture as fast render to texture paths become more common on vid cards, this is becoming a very good idea. If individual windows are blitted to textures and the desktop is reassembled from these windows textures, surely that would be a way to pmplement all the cool extensions and still ensure old X apps don't break? Because the X app doesn't know it's being rendered to a texture...

Re:How about high-DPI monitor support?

[natbudin]

IIRC, you can change the DPI in XFree86. There should be a setting for it in your display manager's config file.

Re:How about high-DPI monitor support?

[Anonymous Coward]

Sorry mate, you're wrong. When I change resolution with my XFree86 the fonts stay the same size. The font sizes are calculated based on the dimensions of the monitor. If your fonts were unreadable you had configured something wrong (your distro had configured something wrong, whatever). In this case Windows has been light years behind X for a long time.

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?

[spydir31]

Try this on,
If using gdm, open /etc/X11/gdm/gdm.conf with your favorite editor, find the following,

command=/usr/X11R6/bin/X

append -dpi 100 or whichever you prefer.
HTH

Re:How about high-DPI monitor support?

[julesh]

Its a reference to the fact that the bitmapped fonts are only available in those resolutions and might have to be scaled for other ones. Chances are, you aren't actually using any bitmapped fonts any more (most modern apps don't bother, the only one I ever use that does is xterm), so it shouldn't actually affect you. Give it a go and see.

Re:How about high-DPI monitor support?

[cymen]

The obvious solution to your problem is to buy 200-300 19" "monitors" (we're actually talking about LCDs, right?) and donate one or two to any X hacker you can find. Your problem should be documented with numerous workarounds and possibly fixes within a couple months.

Re:How about high-DPI monitor support?

[4of12]

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.

Good idea, but not new

[Chris_Jefferson]

The main principle here seems simply to be for the X-server to store each window, wether it be visable or not. At the moment if you stack windows on top of each other the X-server forgets what is on the covered up bits, and when the window becomes visable again it is redrawn. This was a good idea back when memory was scarce, because storing X full screen applications could take X*screensize memory. However today with more memory, we can store all those windows without forcing a redraw.

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

[Anonymous Coward]

This is long overdue in X

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

[renehollan]

Yeah, "backing store" was the first thing that I thought of when I read the article and the need to store non-forground windows.

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.

Re:Good idea, but not new

[otaylor]

Likely the GTK+ developer was me. I certainly didn't say that X has no concept of backing store. I may well have indicated that the current X implementation of backing store quite typically does more harm than good. For instance, under some circumstances, X will store arbitrarily large amounts of pixel data *outside* of the windows bounds in the windows backing store. (Having traced through the X server code to figure out why this was happening some years ago, I can authoritatively say that X does have a concept of backing store.)

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.

Discussion summary

[binux]

Let's summarize the discussion that this is going to trigger:
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

[Outland Traveller]

The remote display capabilities of X are one of it's strongest suits. I only wish it worked with opengGL accellerated apps.

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:Excellent!

[joltguy]

Actually, I was thinking it sounds more like Apple's Quartz Extreme than anything else. Although I guess since Quartz already served as the "inspiration" for Avalon, our comments are compatible. Whatever the inspiration, this will be a nice leap forward for X.

This would be cool...

[Realistic_Dragon]

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.

Extra Memory Usage

[mickwd]

"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."

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

[Erik Hensema]

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.

Re:Extra Memory Usage

[mickwd]

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).

Re:Extra Memory Usage

[IamTheRealMike]

I am not an expert but I'll answer as well as I can.

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

[image]

What are the memory implications of this ?

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 to a video card is rapidly becoming negligible relative to the total cost of the card.

You can even ignore the compression of the data itself (Apple's approach of today) -- by the time an X implementation like this is available, there will be enough users with effectively limitless video RAM to easily store the contents for a double-buffered very high resolution display.

So while I too have plenty of machines with 8MB video cards and I won't be running these X extensions on those machines, I have little doubt that in a year or two time it will be hard *not* to buy a card that could support this. And this, I believe, is a good thing.

Think about how few fundemental changes to the X architecture have been made to take advantage of the vastly improved video cards of today. This is a project that is actually forward looking and will use the capabilities of the hardware that we will all own tomorrow, whether or not we realized we wanted it today.

Re:Extra Memory Usage

[10Ghz]

Yes, the *new* cards. What about older cards? Lots and lots and lots of people are still using old cards.

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

[Hard_Code]

I am consistently amazed at how myopic and conservative some old school open source projects are these days. The X old guard are seriously skirting making X completely irrelevant if they do not become more open and start adopting things that real users want. It takes money to make money, and it takes cycles to save cycles (i.e. it takes more resources to more efficiently save more resources). I can't believe there is resistence to an optional extension that would bring X more up to par with modern desktop environments like Aqua/Quartz.

Re:Extra Memory Usage

[cK-Gunslinger]

Do you expect your grandma to open her box and install a new graphics card?

No more than I would expect my grandma to update her X Windows library to incorporate new buffering extensions.

Re:Extra Memory Usage

[4of12]

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

1. it's VRAM, not your precious other RAM.
2. X is buffering images to speed things up for you

Re:Extra Memory Usage

[PainKilleR-CE]

Additionally, any AGP-based video card will be able to raid the system RAM when it needs more memory.

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 reality is that the graphics card does more processing in games than the CPU, and it will be able to do so much more quickly if it has a lot of local RAM available instead of having to recover the space every time it needs to load a new model or map.

Additionally, the average system RAM is slowly increasing in off-the-shelf systems, to the point where many of the people I work with are thinking that 1GB isn't unreasonable for system RAM. This isn't really being driven by system requirements so much as the general feeling that people have that they should get more for the same price they paid a few years ago, and with RAM prices significantly lower than they were a few years ago, it's not hard for OEMs to give it to them. Sure, MY 2k and XP boxes need 512MB (actually, my 2k box only has 256MB, but it does need more), but the average person doesn't spend their day sitting in front of Visual Studio, either.

Of course, you are correct in that many people have the on-board video that runs off of system RAM, but again, how many of those people are actually using 512MB of system RAM? Additionally, if Linux is trying to move towards a more desktop-friendly environment, how many average users that would be looking at Linux would be using 512MB of system RAM?

Re:Extra Memory Usage

[drinkypoo]

I don't see a need to frequently read the information back from memory. Applications which do graphics operations are either keeping a copy of their bitmap locally, or generating the bitmap from vectors kept locally and then writing it out to the screen (a bitmap). Applications are not frequently going to need to read back from screen memory, because they already know what's there.

Now it is true that there are still people using 2MB, 4MB, 6MB, 8MB cards which could benefit from some of these advances, for example storing the window contents in video memory, since they can do a very fast bitblit to copy that rect into screen memory. However those people can use an implementation of all this in software, where the graphics are stored in main memory, and they should not experience any slowdown, only greater memory consumption. Which, of course, is the state of things today. Meanwhile it is nearly impossible to get a machine with less than 32MB of video memory today, and most everyone has at least 16MB now. (At least, if you have any kind of 3d accelerator.) It takes a bit under 8MB to store a 1600x1200x32bpp screen in video memory, leaving the rest for the most active applications (assuming no full-screen double buffering.)

If you DO decide to store everything in video memory (again, not going to be feasible on the older machines) then you get whatever bus bandwidth you have available to do it with. With modern machines (AGP4x and 8x) this is going to be essentially a non-issue for most X users. The only time you really blast your bus is when you're transferring large textures that have to be sent right now. It is hoped that X will one day end up using more of the video card's functions to do window compositing, minimizing the amount of data which must be sent. Even pixel shaders have a place here, for little things like drop shadows. (If you have a pixel shader engine which is otherwise idle, you might as well use it to draw your eye candy.)

64MB is plenty of ram, it's enough for eight full 32BPP 1600x1200 screen images and then some, or enough for a fully double-buffered display and a bunch of applications. Even 32MB is pretty healthy, it's not until you get down to 16MB cards (like say, the banshee) that you have problems.

Anything new enough to be an interesting desktop box, where you will want to burn power on eye candy, is going to have AGP graphics. You can get (crappy SiS) 64MB AGP video cards for under $30 shipped these days (at least in the US of A) so I'd say that's not a serious issue. Remember, this is the future we're looking towards, not the past. For all those old machines, you can always run older versions of XFree that don't do this stuff. Oh sure, you can't run the bleeding edge software, but who's trying to run the latest software on their old hardware? I defy you to get a significant amount of work done on a 386 running GNOME2 :P

Aqua has this (Display-PDF)!

[null-und-eins]

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.

maybe this is a good place to...

[3seas]

....mention any other open source that can be used as an example of already existing functionality that is like this or can contribute to it, perhaps directly.

Not getting into the programming details but AROS is open source Amiga clone I believe having some of this...

Shrug

Ill advised

[amightywind]

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:without altering existing X protocol "too much"

[Omnifarious]

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.

Is there a new X logo out as well?

[Zanthany]

I seem to be seeing a new X logo as well from the slashdot page:

slashdot.jpg

It's so simple and plain. It just might work!

Re:Is there a new X logo out as well?

[Anonymous Coward]

There's something wrong with your browser. It looks like IE.

Re:without altering existing X protocol "too much"

[dmiller]

Fortunately the X protocol can be extended without being replaced. OpenGL (GLX actually), Xrender, XVideo and the XSHM (the shared memory extension) are all examples of extensions that have been added without breaking old apps. Parts of X may be crusty, but overall it is pretty well designed.

XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.

Clarifying Vector-based display

[MarcQuadra]

You don't seem to understand the problem the way it was meant. I have a big monitor, I like to run at high resolution, but text is TINY, so I make the fonts bigger, but then everything is out-of-whack in terms of widget sizes and images.

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

[Darren Winsper]

Here you go:

http://www.cairographics.org/

Integrated Audio.

[Robert Frazier]

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.

[TheRaven64]

I agree. The protocol exists, but it is not yet implemented by XFree86.

Re:Integrated Audio.

[RdsArts]

Yes, it makes far more sense to have the graphics system act as the server for audio as well, instead of another server. I mean, it's not like there are any networking audio servers out there.

Turning X into Quartz

[mdxi]

...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!

Re:I don't understand the fascination with X

[fault0]

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.

15" laptop with 1600x1200...

[tjwhaynes]

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...

[swillden]

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 can automatically produce the "right" thing in an unanticipated situation is non-trivial) but the almost infinite configurability of X is a strength, not a weakness.

Also, OverlyCriticalGuy, you need to be more critical of your own arguments: comparing current-generation X to MS vapor is fallacious.

Backing store?

[10Ghz]

How is this different from backing store?

All I ever wanted from Xwindows...

[zerocool^]

...was to be able to cut and paste between applications. A unified API for a clipboard system that uses a unified set of keys to cut and paste.

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...

[groomed]

I love X... but I have to admit that you've hit the nail on the head. It's astonishing how bad cut and paste works between applications. It really only works for text, and then only if the text is flat ASCII. Because it's so bad, many applications have their own, internal version of the clipboard, and you're never really sure whether you're manipulating X's clipboard or the internal clipboard, or what information makes it onto X's clipboard and in what form. It's a total disaster.

Cut and paste on X is so bad, that I use it so little, that my expectations have sunk so low, that I've basically forgotten how it is to have a clipboard system that does work. Thanks for the reminder.

Re:All I ever wanted from Xwindows...

[_Sprocket_]

...it confuses select with cut-and-paste...

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.

Re:All I ever wanted from Xwindows...

[tuffy]

I love X... but I have to admit that you've hit the nail on the head. It's astonishing how bad cut and paste works between applications. It really only works for text, and then only if the text is flat ASCII. Because it's so bad, many applications have their own, internal version of the clipboard, and you're never really sure whether you're manipulating X's clipboard or the internal clipboard, or what information makes it onto X's clipboard and in what form. It's a total disaster.

The X11 clipboard is already quite powerful 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...

[jbolden]

Its not cut and paste but OLE (object linking and embedding) that you probably really like. Microsoft spent a fortune to get that to work. Its highly non trivial and given the way X works we may never get that at the X level. Now within desktops (i.e. within KDE or within Gnome) you may very well get that within 2 years.\

Re:All I ever wanted from Xwindows...

[ParisTG]

Luckily the clipboard problems are simply a lack of standardization between applications. The freedesktop.org people are working on a spec to fix this, and already (afaik) most of KDE and GNOME apps, among others, follow the spec. It's only a matter of time now.

Re:All I ever wanted from Xwindows...

[Permission Denied]

...was to be able to cut and paste between applications

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 going to run into certain problems with certain ancient applications and toolkits that do not implement this correctly. Most notably, QT 2.x did this wrong and xterm does not allow you to "copy" as you expect (there is no copy menu item or shortcut). I think GNU Emacs also does this wrong. These applications and toolkits are actually fairly rare, but xterm and emacs are pretty popular programs.

Details: X11 keeps track of a clipboard and a selection. The selection is generally inserted whenever you middle-click. Middle-clicking does not paste from the clipboard - you have to use a menu item or keyboard shortcut to paste from the clipboard. Like I said, pretend there is no such thing as middle-click and cut and paste will work as in MacOS and Windows as long as you don't use xterm (instead use gterm or kterm or whatever the KDE/GNOME equivalents are called). Whoever told you that middle-clicking pastes misinformed you; no XFree86 documentation tells you this.

Please don't tell us we need a "unified API" for cut and paste. We have one, it works and all new applications use it. If you want to go and fix xterm, go for it, that's some real nice code for you to play with :) If you want to fix GNU Emacs, go suggest this on the emacs mailing lists and see how far you get :)

Re:All I ever wanted from Xwindows...

[Minna Kirai]

A lot of apps only support ASCII, but that's not X11's problem.

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...

[Minna Kirai]

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.

Venerable?

[ynohoo]

I've heard many adjectives used about X windows, but this is the first polite one!

Re:I don't understand the fascination with X

[Hard_Code]

"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.

Re:without altering existing X protocol "too much"

[whereiswaldo]

I suppose this demonstrates one reason why closed source is bad...

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).

High ppi displays

[SeanAhern]

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.

Re:I don't understand the fascination with X

[Virtex]

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.

X Double Buffer Extension

[Wills]

I see there are people saying again that X cannot do flicker-free graphics because it lacks double-buffering. However, I'd like to point out that X has had the Double Buffer Extension since about 1994.

For an excellent example of how to do double-buffering in X, please read the source code (here) for the XSpectrum spectrum analyser (despite its age XSpectrum still runs faster than the newer gspectrum).

Re:without altering existing X protocol "too much"

[stripes]

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,

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.

Re:GTK bloat (Was:Re:Good idea, but not new)

[Brandybuck]

Having written a few Qt/KDE themes, and perused in depth dozens more, I have to admit that Qt is mostly the same way.

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, while on others that appear to be more complex, I see none. For example, Liquid is a pretty complex theme with blended gradients everywhere, but it makes extensive use of caching, so it has a smoother redraw than some simpler themes.

Of course, if this becomes a problem for non-cached themes, it's simple to fix, because of the way Qt is architected.

Jojo on UI

[SimHacker]

Jojo on UI

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
2. Two thick libraries, with enforced single-entry SlowRead(). and a single NoExit() for enforced modularity.
3. Copy of More's /Utopia/, and a well-fingered /Neuromancer/
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