X.org and XFree86 Reform

Good for everybody by Mork29 · 2004-01-23 02:04 · Score: 4, Interesting

give credit to -- individual contributors rather than continue to view X development primarily as a corporate activity.

I like this alot. Functionality to the desktop is something that Unix and Linux both need to see loads of improvement on to help spread it to a larger market. I also like to see the OpenSource community coming together and joining into larger projects that can do more, rather than see hundreds of smaller projects all going in the same direction seperately. Bringing lots of brain power together gets stuff done.

Re:Good for everybody by Erwos · 2004-01-23 02:28 · Score: 3, Informative

You can already do that, provided you've got the appropriate resolutions in your XF86Config. Do a search on "XRandR" - the hooks are indeed there. IIRC, Ximian had a program that did just this.

-Erwos

--
Plausible conjecture should not be misrepresented as proof positive.
Re:Good for everybody by cxvx · 2004-01-23 02:35 · Score: 2, Informative

KDE supports this (this is only possible because the underlying xfree 4.3 supports it offcourse).
See this dot.kde.org post about it.

--
If only I could come up with a good sig ...
Re:Good for everybody by dinivin · 2004-01-23 03:19 · Score: 2, Informative

That doesn't change the actual resolution, just the displayed resolution. You still have a desktop of the same physical size.

However, xrandr does do what the parent poster wants.

Dinivin
Re:Good for everybody by Tack · 2004-01-23 03:21 · Score: 3, Insightful

Try CTRL + KeyPad+ or CTRL + KeyPad- to cycle back and fourth between the different resolutions.
I find that simpler than "Click desktop -> Properties -> Advanced -> Tick new resolution -> Apply -> Yes, we are not dead -> Ok". But that's just me.
Stop complaining :) You get a long way with knowledge....
Except that those two tasks perform different things.
Jason.
Re:Good for everybody by timeOday · 2004-01-23 03:23 · Score: 4, Informative

This is not correct. CTRL+KeyPad+ doesn't change the desktop size. It does change the screen resolution, but then your desktop is smaller or larger than the screen, so it will scroll when you go to the edge of the screen. This simplifies things because the window manager and apps don't even know about it. You also can't change color depth this way.
As somebody else mentioned, the real answer is the new XrandR extension. But he talked as if it were mature and fully integrated, which it isn't. In truth it may or may not be available depending on which video driver and window manager you're using, and it's not that widespread yet (ymmv).
Re:Good for everybody by Mikkeles · 2004-01-23 03:53 · Score: 2, Interesting

"Functionality to the desktop is something that Unix and Linux both need to see loads of improvement on to help spread it to a larger market."

I would like to have the ability to open different windows with differing resolutions. I could use this in scientific visualization and I think it could be handy in photographic work: ultra resolution for the image and ordinary for the control panel.

(I believe the Amiga had this, but I never needed to use it back then, so I'm not sure. I also don't know how much of this ability was due to Agnes, Paula, and Denise (i.e.: the hardware) rather than the software.)

--
Great minds think alike; fools seldom differ.
Re:Good for everybody by Haeleth · 2004-01-23 05:37 · Score: 2, Insightful

Um, maybe the fact that so many people want it means that it *isn't* such a rarely altered setting?

Maybe the fact that both Windows and MacOS make it very easy to change resolution and colour depth might be taken as a hint that usability experts agree that it's worth making it easy?

Just because this is the way Windows works doesn't make it bad, either.

Hopefully... by rongage · 2004-01-23 02:05 · Score: 3, Interesting

Hopefully, they will work out a SINGLE standard for getting copy/cut and paste working correctly.

I can't tell you how infuriating it is when you go to copy a page of text from, say, openoffice.org, and paste it into a webform in Mozilla - only to find that perhaps the first half a paragraph out of 6 made it over.

--
Ron Gage - Westland, MI

Re:Hopefully... by TheRealMindChild · 2004-01-23 02:12 · Score: 4, Insightful

The issue is that the philosophy of X (at least from what I see), is that is plays the role of a graphic server. Nothing more. "If you want copy and paste, write a deamon to manage it" type philosophy.

This is the one case where I say I like the Windows way better then the Unix way.

--

"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Re:Hopefully... by IamTheRealMike · 2004-01-23 02:25 · Score: 5, Informative

I can't tell you how infuriating it is when you go to copy a page of text from, say, openoffice.org, and paste it into a webform in Mozilla - only to find that perhaps the first half a paragraph out of 6 made it over.
This has nothing to do with X and has everything to do with a long standing bug in Mozilla, which fails to use the X clipboard correctly. Mozilla on X has always been secondary to Mozilla on Windows/GDI, and unfortunately it shows here badly.
Here is the buglink: http://bugzilla.mozilla.org/show_bug.cgi?id=56219, you'll need to copy/paste to stop bugzilla being Slashdotted (don't bother if you aren't interested or able to understand the technical details).
Basically Mozilla does not properly support the ICCCM protocols and as is often the way with Mozilla the bug has been blocking on one or two overworked people for a very long time.
An object lesson in why inventing your own toolkit is a silly idea, IMHO....
Re:Hopefully... by arvindn · 2004-01-23 02:30 · Score: 4, Interesting

Yeah.
There are lots of "X sucks" flamethrowing morons around who have been told a million times that (for example) network transparency doesn't have overhead when both client and server are on the local machine.
But the parent's complaint, IMHO, shows one of the genuine weak points of the "mechanism, not policy" philosophy of X.
The gist is this: the X designers were faced with the choice of whether selecting text would copy it to a buffer or would merely mark it as selected. All window systems which were designed with a human user in mind would have found it a no-brainer -- copy the text to an internal buffer, since that's what the user intuitively expects.
Not X.
X merely marks the text as selected. That's because it avoids unnecessary network transfer in case the application is running remotely. The second reason is that it enables "content-type negotiation", between the copying and pasting programs. One of the consequences is that if you select text and close that program then that data is gone! This is unexpected data loss, as bad (to Joe Enduser) as your os randomly deleting files on disk.
Note: I'm not saying X made the wrong choice, just that the choices it made aren't very suitable for normal desktop use.
The second consequence of this is that programs (in practice, widget toolkits) that implement copy-paste must all need to agree on a common protocol/format etc. to make things work. And of course, we all know how good open source developers are at doing that. (Its not their fault, just a consequence of the fact that its made of various indepedent projects and not one company).
So that's why nothing can happen right in the desktop linux world without freedesktop.org. Its the standards effort that sits on top of all these disparate pieces and tries to bring some sanity to the whole situation. And I would say it has been going extremely well. Keep it up guys!
Everyone say a little thanks to Keith Packard, please.
Re:Hopefully... by hanssprudel · 2004-01-23 02:43 · Score: 3, Informative

But X already supports all this. The problem doesn't lie with X at all, it lies with application support for the excellent standard available. X.org cannot help that people are writing applications and toolkits that run on X yet do not do cut-n-paste properly or fully.

An important note: highlight and middleclick is not the same as copy-paste. X has a system for cut/copy/paste beyond the more often supported middleclick "dragging". And yes it supports data of every type, not just text.

The level where somebody needs to do something about cut-n-paste is not X.org, but Bruce Perens Userlinux initiative (is that still alive?) If I were in charge of Userlinux I would refuse to include any application that doesn't fully and properly support cut-n-paste.
Re:Hopefully... by Alioth · 2004-01-23 02:47 · Score: 4, Insightful

That's not right (at least in terms of cut and paste). The X server handles it. Select with the left mouse button, paste with the middle. No messing with the keyboard. Works the same with every app.

The modular approach of X is one of its great strengths, not weaknesses. The same specification (X11R6) has scaled well enough that it hasn't needed reworking in over a decade. The Windows GDI seems to change whenever the wind blows.

--
Oolite: Elite-like game. For Mac, Linux and Windows
Re:Hopefully... by Mr.+Slippery · 2004-01-23 03:04 · Score: 2, Insightful

All window systems which were designed with a human user in mind would have found it a no-brainer -- copy the text to an internal buffer, since that's what the user intuitively expects.

This is obviously a strange new use of the word "intuitively" which I've never encountered before. Highlighting text intuitively implies making a copy of it? Absolutely no way.
It's not a question of intuitiveness. It's a matter of people having gotten used to the (braindead and ugly) Windows way of doing things.
Cut-and-paste works fine for me between the applications I use: GNU Emacs, Galeon, Sylpheed, OpenOffice, and gnome-terminal.

--
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Re:Hopefully... by Otter · 2004-01-23 03:16 · Score: 4, Insightful

Works the same with every app.
Except that, as the original poster noted, it does _not_ work between any two apps. I know this is the zillionth time this exchange has taken place here, but just because you don't use a combination of apps for which it doesn't work doesn't mean that those of us who need to paste from, say, Kate to rxvt are making up stories.
And, of course, copy/paste isn't a clipboard, copying anything but ASCII text almost never works, ...

--
What I'm listening to now on Pandora...
Re:Hopefully... by freeweed · 2004-01-23 03:29 · Score: 2, Funny

a long standing bug in Mozilla, which fails to use the X clipboard correctly...you'll need to copy/paste to stop bugzilla being Slashdotted

But I'm using Mozilla on X, you insensitive clod!

--
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
Re:Hopefully... by twistedcubic · 2004-01-23 03:54 · Score: 2, Interesting

One of the consequences is that if you select text and close that program then that data is gone!
This is not true. Your assumptions are wrong, but I won't get into it. Nevertheless, you have fooled a lot of people here.
Re:Hopefully... by Tinidril · 2004-01-23 04:02 · Score: 2, Insightful

Actually I find the fact that Winders tries to bring the formatting with to be very anoying. Most of the time it doesn't work right, and causes all sorts of behavior, Esp in Word and Outlook.

If Linux does get this feature I hope that there will be two different paste methods, to past with or without formating.

--
XML is the best data format; unless your data needs to be read or written by a human or a computer.
Re:Hopefully... by Crispy+Critters · 2004-01-23 04:48 · Score: 3, Informative

>> One of the consequences is that if you select text and close that program then that data is gone!
> This is not true.
I just tried this. Open 2 xterms. Type ls in one, highlight a filename, close the xterm. Middle click in the other xterm, and the text appears. So it is not always true that the data is gone. (Probably some of the time.)
I would add that it has never occurred to me in using X for 15 years to highlight text, close the app, and try to paste the text. Why do that when you have a multitasking OS and a window manager?
Re:Hopefully... by ichimunki · 2004-01-23 05:05 · Score: 4, Interesting

It's a hard problem to solve because it requires content negotation. If I select and copy a graphic in a web browser and try to paste it into a pure text editor, what should it do? Nothing? Should it paste the ALT text? How about the longer description text if there is any? Should it paste the URL of the image? Should it attempt to use OCR on the image to convert it to textual data?

I can think of lots of content negotation problems with text, too, especially styled text. What if part of the style is unsupported? What if the style is the result of a named style using a name that both applications support but the visual rendering of that style is very different-- should it attempt to mimic the rendering or should it use the style as named? (Quick example would be copying some text from one HTML document to another where both used CSS for styling-- which style sheet's H1 definition would be used for headers?)

And FWIW, while I like left-drag-select and middle-click-paste sometimes. I find it annoying too. Because it fails miserably at replacing on the fly. Once you drag to select text to paste over you have wiped the clipboard clean.

For a fantastic demonstration of the real problem. Go into GNOME-terminal. Select some text. Press ctrl-c to copy (since that's the standard shortcut). Whoops. You just killed your running process if you had one. :)

--
I do not have a signature
Re:Hopefully... by ratboy666 · 2004-01-23 05:41 · Score: 2, Interesting

X is a graphics server. It is *not* a "desktop" in the sense of Microsoft Windows.

To make X into a desktop, we have to add a window manager, an operating system (with all that entails), etc.

An example -- I run X on a system. I use it as a terminal. The window manager runs on another computer, as do all of my applications. Indeed, they run on three computers (or more).

Each of the "windows" is displayed on my terminal, and I have a single keyboard and mouse. Using X, it looks like I have a single big computer, and not three (or more) different ones.

This IS a coherent environment. And, it has had time to be tested and proven.

So -- we have "coherent". A broader definition than the one you probably meant...

Performance. The X clients do not need the resources of a local X server. Thus, the boxes running in my "coherent" environment generally do NOT have monitors, keyboards, mice of their own. Indeed, the only box I have that HAS another monitor has a variety of TVs (I do set-top box work). Performance is higher because these boxes do NOT have to waste resources on a GUI. *That* task is moved to other machines.

Given that the "remoteness" is important, the "lack of change" is also important. An X server is an X server.

My X server is cygwin, running on Windows 2K (company mandated -- I must also run Outlook). Clients are on a custom processor (Xilleon), Linux (Intel), or SUN. I shouldn't care WHICH machine originates the X to the server -- I just want the graphics.

Given that this works, and that X has proven itself, why throw it out? *YOU* may not need the support, but *I* do. If you don't want X, go with Microsoft or Apple. If you need to run X, you can always throw on an X server. Be happy that the X code is portable enough to allow this to work reliably (and its free/Free).

Ratboy

--
Just another "Cubible(sic) Joe" 2 17 3061
Re:Hopefully... by Frater+219 · 2004-01-23 07:04 · Score: 2, Insightful

Terminal programs don't support standard desktop keys anyway, this is no issue. Ctrl-home etc. won't do what you expect either. Just forget about trying to get traditional terminal shells to obey desktop keys and write a new terminal program that does.

It's a bad habit to respond to a post without reading the whole post. As I mentioned, the Mac OS X Terminal.app is just that -- "a new terminal program" that behaves correctly in a GUI environment, including supporting the GUI keyboard commands, including "copy". KDE's Konsole and Gnome's gnome-terminal also attempt (with a lesser degree of success) to work with rather than against the GUI.
I'm not talking about making new GUI environments compatible with xterm. I'm talking about making new GUI environments' terminal emulators more compatible with (1) existing terminal-based programs, and (2) the GUI environments themselves.
Why does Terminal.app fit better with its surrounding environment (Mac OS X) than Konsole fits in its (KDE)? Because, for all its features, Konsole (which I use) has to forego some of the surrounding environment's standard keystrokes because they were chosen in such a way that they conflict with necessary terminal keys.
Konsole doesn't trap Ctrl-C or Ctrl-X; this fact makes Konsole better as a terminal program than if it did, but worse as a KDE application (because KDE does use Ctrl-C for "copy" by default). If KDE's defaults had been chosen in such a way as not to conflict with terminal keys, then Konsole would not need to deviate from the KDE standard behavior -- just as Terminal.app does not deviate from the Macintosh standard behavior.
Re:Hopefully... by Kent+Recal · 2004-01-23 08:37 · Score: 2, Interesting

Well, it seems to be hard to write such a daemon, or does anyone else know why nobody has come up with one, yet?

I mean there is a demand. And if I could only find any usable documentation that gives me hints only on how to approach the problem (I'm not familar with X internals) I'd probably try to write one myself.

The fact that there isn't already one out in the wild tells me it's either not possible or really hard to do?

I imagine something simple like screwing the whole middle-click idea (its way too flaky for my taste and I don't like loosing my clipboard when I select something else) and just implementing CTRL-C/CTRL-V properly.

That's nice, more of that by Daath · 2004-01-23 02:06 · Score: 4, Insightful

It's nice. Now we need the big desktop systems to agree on common ground, make a "base" system that they can develop each their own systems on ;)

--
Any technology distinguishable from magic, is insufficiently advanced.

Great for *nix by Anonymous Coward · 2004-01-23 02:06 · Score: 2, Insightful

Theres no sense in having talented people work on different projects trying to complete the same task. This is great news for the X interface.

Window Manager?? by GigsVT · 2004-01-23 02:06 · Score: 3, Troll

What the fuck is the "X Window Manager"?

I'm seriously confused now.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.

Re:Window Manager?? by peope · 2004-01-23 02:14 · Score: 5, Informative

I think the parent wanted to point out that the window-managers are not part of the X-server.

The window-managers are apps running on the X-server.

Although. I cannot read anybodys minds =)

UnitedX by RAMMS+EIN · 2004-01-23 02:07 · Score: 4, Insightful

I hope this means we're gotting one GOOD X server, instead of one that has the drivers but not the features, and one that has the features but not the drivers.

I still believe the Right Thing is to have an efficient system for local display, and a widget-based protocol (a la PicoGUI) for remote display, though.

--
Please correct me if I got my facts wrong.

Re:UnitedX by RAMMS+EIN · 2004-01-23 03:00 · Score: 2, Interesting

I was hoping somebody would come up with a thoughtful post rather than just slamming me (like the other poster did). I know that X is considered efficient, the point is that it doesn't show.

If I drag a window across the screen, my CPU load goes up to 100%. Resizing a window takes ages. uncovering prviously covered portions of a window on XFree86 sends expose events, causing redraws, which is somehow slow. Playing a movie (or any other pixel-based thing) doesn't give me a decent framerate. All this is better under other systems (BeOS, Windows) on the same hardware, using unaccelerated VESA drivers.

Thus, X is not efficient for local display. I am not saying that it is because it can display remotely. I don't know why, it's just slow.

As for remote display...it strikes me that I get a more responsive UI when using VNC than when using X. That doesn't speak in favor of X, either. I count myself lucky that there are so many good command-line apps and tools.

--
Please correct me if I got my facts wrong.
Re:UnitedX by spitzak · 2004-01-23 04:53 · Score: 2, Informative

These problems are caused by bad design, in particular the seperated Window manager and programs.

Windows also has Expose events, thought they call them WM_PAINT, and they work the same way. However even the earliest version of Windows would freeze all update to any windows while you dragged a window around and would preserve the area hidden by the moving window, so once the area the window was sitting on was repainted (you can certainly see this, it looks just like X because they did the same brain-dead "erase" action and it turns white), you could drag the window quite quickly. Modern Windows has backing store for all the windows so WM_PAINT is not needed except for resize and when the program requests it.

Both of these can be added to X without much trouble, though it looks like only Backing Store is going in.

No amount of speed is going to fix the resize problems. They are caused by two different processes drawing the window border and the window contents. I have looked at ways of synchronizing this and things do not look good, even if I assumme new calls are added to the X server. We need to make the window borders be drawn by the application. The "Window manager", if it exists at all, is strictly for managing icons or taskbars, it would send a "you are being opened/iconized" message to applications, and they would respond by unmapping/mapping windows.

And yes, I know this means the window borders can look different between programs, and that dreaded boogyman of "inconsistency" will be raised yet again. But really, lots of media players already use override-redirect and make fake window borders, and I have NOT seen people "confused by inconsistency". This argument is really a scam by people who want to write the toolkits, rather than work on hard stuff like fast and powerful rendering models.

Remote display of some X programs is really bad due to the fact that they draw everything with images because it is too hard to get the graphics they want with the (quite awful) X drawing primitives. Basically they are acting like VNC in a window, except X has no image compression, so of course this is worse. This can only be addressed with new and powerful rendering models so that you can draw transparent images. IMHO "sending widgets" is a mistake and will cause more communication: check out how many methods you need to create and control a Qt widget, and compare that to how many graphics calls you have to do to draw it.
Re:UnitedX by RAMMS+EIN · 2004-01-23 08:34 · Score: 2, Interesting

``No amount of speed is going to fix the resize problems. They are caused by two different processes drawing the window border and the window contents.''

It doesn't have to be that way. If the server keeps a copy of the contents and either knows how to draw the decorations or keeps a copy of them too, then it would be one process that does the drawing.

Also, I wonder if what you said relates to x86 in any way. I have heard someone say that context switches are comparitively slow on x86. Might the sluggishness come from that?

``And yes, I know this means the window borders can look different between programs, and that dreaded boogyman of "inconsistency" will be raised yet again.''

Not even necessarily. If applications call some library function to draw the borders, the library could ensure consistency.

``IMHO "sending widgets" is a mistake and will cause more communication: check out how many methods you need to create and control a Qt widget, and compare that to how many graphics calls you have to do to draw it.''

I can't imagine it costs more to send one message when a widget is created, one to attach a callback, and receive one message when the callback is triggered than it costs to send all the messages to draw the wizard, draw it differently when the mouse moves over it, yet different when it is clicked, etc. etc.

What I have in mind is something like HTML: you send the user interface once, and you only hear back from the user when they take certain actions. Now, web interfaces are a bit limited, because the server can't send events to the user, but I guess you get the idea.

--
Please correct me if I got my facts wrong.

Get the name right! by dabadab · 2004-01-23 02:08 · Score: 5, Informative

It's called "X Window System" and not "X Window Manager".
It is so mostly because it is not a window manager.

--
Real life is overrated.

X again by Apreche · 2004-01-23 02:09 · Score: 5, Insightful

Ok, how many slashdot stories do we need where half the people support X and half the people want something new, or a re-write. This is what it comes down to. X has a lot of great features. X forwarding over ssh being the premier reason I use X. It's probably a feature I couldn't live without. But if linux wants to transition to being a desktop OS for everybody X wont cut it. It's just too big, slow, and full of features desktop users don't need. Directfb is more like what desktop users need, but not quite. That's all there is to it. Linux is about choice, and right now X is the only truly reliable choice for any sort of gui stuffs. We need a real alternative to X for those who don't need the features.

However, as a user of X, I think it's great these sites are joining forces. OSS is about collaboration, and the more they work together the better the end result will be. And if everyone works together they will follow the same standards like the ones from freedesktop.org programs will be much nicer. gaim easily going into the system tray which I put in my xfce4 taskbar is an example of freedesktop.org standards at work. If everyone followed them, imagine what we could do.

--
The GeekNights podcast is going strong. Listen!

Re:X again by dabadab · 2004-01-23 02:16 · Score: 2, Interesting

"It's just too big, slow, and full of features desktop users don't need. Directfb is more like what desktop users need, but not quite."

If you really would have taken the time to read the previous X stories on /., you would have known by this time, that X is neither big or slow, and the framebuffer approach is not what users really want (and that Windows' model is slowly transforming from the framebuffer to a more X-like approach)

--
Real life is overrated.
Re:X again by echion · 2004-01-23 02:17 · Score: 5, Informative

X is not big & slow -- this is a common misconception. X can run acceptably on iPAQs, Zauruses, and other very memory- & CPU-limited devices.
This tiny version of X is called "KDrive" and it ships with XFree86. Read more about it here and here.
And stop talking about "choice" when you don't even know what choices X offers.
Re:X again by ender81b · 2004-01-23 02:25 · Score: 4, Insightful

While X has alot of features it is also missing a HUGE amount. Just a few examples of the top of my head:

Why in gods name do I need to specify my monitor's vertical and horizontal sync rates? Monitors have been plug n play for years now, why does X not use this info?

Why, to change the refresh rate, do I have to run xconfig instead of just being able to change it through X like windows? If you think this isn't a problem try using X when you have a fixed-freq monitor.

Why are there so many problems with different mice/smooth scrolling?

My final question is wheter anybody on slashdot is running freedesktop's new xserver and, if they are, their experiences with it. I was thinking about installing it on my fedora core install.
Re:X again by Dr_LHA · 2004-01-23 02:34 · Score: 2, Informative

Why in gods name do I need to specify my monitor's vertical and horizontal sync rates? Monitors have been plug n play for years now, why does X not use this info?

You don't, XFree86 has handled "plug and play" (DDC capable) monitors for a while, certainly on PCs I've not had to worry about Horizontal and Vertical refresh rates for a long time.

Why, to change the refresh rate, do I have to run xconfig instead of just being able to change it through X like windows? If you think this isn't a problem try using X when you have a fixed-freq monitor.

Why do you want to change the refresh rate anyway - because it was set wrong in the first place? Thats just a configuration issue. I can't seriously think of any reason why you'd actually want to switch back and forth between refresh rates in normal PC usage. That said it most likely can be done using the RnR extension, which allows you to change resolution on the fly (another pointless Windows concept).

Why are there so many problems with different mice/smooth scrolling?

There are? Name a few.
Re:X again by flossie · 2004-01-23 03:20 · Score: 4, Insightful

Why do you want to change the refresh rate anyway - because it was set wrong in the first place?
Yes. For instance, when giving presentations, it is not always possible to try out the projector ahead of time.

--
flossie
Write now. Defend liberty
Re:X again by Fnkmaster · 2004-01-23 04:48 · Score: 2, Insightful

Sorry, X is slow. Not slow in the sense that you are thinking of (CPU hog) but slow in the sense of screen refreshes, expose event handling, window resizes - all the basic GUI activities feel far less responsive on X than they do on Windows, for comparable hardware. Of course, this statement is loaded with assumptions - many people would say "that's because of that awful KDE or GNOME cruft, try running a real window manager and real apps". And they'd be right in the sense that older, non-Qt, non-Gtk apps, sans the KDE/GNOME desktop environments feel blazingly fast. It's just that's not exactly a useful solution for Linux on the desktop. And don't whine about people who want eye candy, eye candy is a necessary part of a successful modern desktop.

For me, I'd like to see Linux be something that can legitimately be perceived as a desktop alternative. That's going to require the ability to support the kind of eye candy, responsiveness, and aesthetically pleasing, generally meshing GUI widgets that we still don't have today. If this doesn't matter to you, fine, but don't come out with the old Slashbot response that X is fast, X is great, if you criticize X you are an idiot and you don't understand how wonderful and innovative network transparency was 20 years ago, and so on.

"the X Window Manager for Linux and Unix" by nickos · 2004-01-23 02:12 · Score: 4, Informative

From the article

"...the reformed group is working together to bring "not just more eye candy but new functionality" to the X Window Manager for Linux and Unix."

Umm, they mean X Server don't they, or is there suppossed to be some sort of official window manager now? That would be very bad news in my opinion - Linux benefits greatly from the diversity of GUIs that exist for it.

Oh, no, not again by dabadab · 2004-01-23 02:13 · Score: 3, Interesting

Please, let's get off this dead horse.
Cut'n'paste works on X's level.
The problem is (or probably: was) not with X, but with Gnome and/or KDE.

--
Real life is overrated.

Where's Keith? by 4of12 · 2004-01-23 02:17 · Score: 3, Informative

A real welcome development.

But I'm curious where Keith Packard stands relative to all of this; he has talent to contribute substantially to an improved X and has had enough problems with the earlier XFree86 development that he thought a fork was justified.

--
"Provided by the management for your protection."

Re:Where's Keith? by Karn · 2004-01-23 02:33 · Score: 4, Informative

The answer to his question is here

1.11) What is Keith Packards involvement with Xouvert?

Keith Packard is a champion of the move to open XFree86, and supports Xouvert's efforts in that regard. Keith's project is freedesktop.org, and he's expressed interest in bundling with Xouvert's results.

So Keith is right there in the middle of it all.

And according to the Xouvert FAQ, it is not a fork, but more of a public development branch.

--

Why do I keep typing pythong?
Re:Where's Keith? by arvindn · 2004-01-23 03:34 · Score: 2, Insightful

I don't think xouvert is active now. I've been on the mailing list and I don't remember receiving much mail in the last couple of months or so.
Anyway the current development will probably diminish the importance of having something like xouvert.

Of course not... by MountainMan101 · 2004-01-23 02:18 · Score: 2, Insightful

Don't be silly, what this does mean is that small development groups are merging. This will be good for Linux. A unified group, with real direction is essential for our world domination a good OS.

Quick name change by Papa+Legba · 2004-01-23 02:21 · Score: 5, Funny

Now would be the time to strike on a new name change for the system. Since we have two X groups joining and it a new X orginization. I suggest they rename it to "XXX Windows System". I would bet they would see there number of downloads skyrocket.

--
Papa Legba come and open the gate

this should help programming a lot by black+ninja · 2004-01-23 02:23 · Score: 4, Insightful

This should help the guys that actually code down at the X-window level a lot. You will be 'sure' that your skills are transferable between systems, and confident that they aren't going to change relative to each other.

One thing that always annoys me with programming for linux and unix is that include files are always in a different spot. I've spent days hunting for something(yes I know about whereis and assorted utils) only to find out it's name had an x infront of it, whereas on the other system it didn't or it was in another directory. Something stupid like /etc/bin/include/graphics/opengl.

Or one system uses opengl and the other mesa for example, and then your completely lost. The arguement that if you new the systems you were coding for better you would be fine, is ignorant as most people use standard libraries like opengl, sockets.h etc, because they aren't supposed to need to know much about the other os for it to work. Anyways, if the X guys standardize things like the directory structure, and procedure interfaces(although I think there are standards for these) it will make things much easier for us linux at home, unix at work guys.

Cut-and-Paste in X beats the competition... by FreeUser · 2004-01-23 02:26 · Score: 4, Interesting

...hands down.

The problem is (or probably: was) not with X, but with Gnome and/or KDE

Indeed.

X has the most elegant cut-and-paste scheme I've ever seen, certainly vastly superior to Mac OS X and Windows.

Select with the left button pressed, and click with the middle button in the target window to paste. No Apple-C or control-V crap, no need to press any key of any kind. Click-select, click, and you're done.

Once you get used to it, you won't be able to stand the way Mac OS X and Windows handle cut-and-paste.

Gnome and KDE made the extremely boneheaded decision to mimic Windows even when it really doesn't make sense; when the X way of doing things is vastly better. Click to focus as a default? Ugh! Windows-style cut-and-paste? An affront to humankind.

--
The Future of Human Evolution: Autonomy

Re:Cut-and-Paste in X beats the competition... by 10Ghz · 2004-01-23 02:35 · Score: 2, Insightful

Select with the left button pressed, and click with the middle button in the target window to paste.

That can cause serious problems. What if I just want to select some text (but not cut&paste)? It would overwrite whatever I had in my clipboard (or whatever it's called).

--
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Re:Cut-and-Paste in X beats the competition... by CaptnMArk · 2004-01-23 02:39 · Score: 3, Insightful

WROGN!

That is not cut-paste scheme since you cannot cut and paste with it.

What most people mean with cut-paste support is support for CLIPBOARD (explicit copy).

The fact that there are two different and incompatible standards it why X people are complaining.

We need only one standard (by default, at least) and it seems that the market has chosen it: clipboard cut-paste with Ctrl+XCV keys -- alternative standard bindings that work fine even in terminals are Shift+Delete, Ctrl+Insert, Shift+Insert.

Flames away, but I am still right.
Re:Cut-and-Paste in X beats the competition... by scrytch · 2004-01-23 03:01 · Score: 2, Informative

> no need to press any key of any kind

Or ability. Windows, incidentally didn't come up with the idea or design of CUA keys, but Bill Gates thanks you for crediting another invention to him.

It's a decent bit of troll (though "affront to humankind" was a bit over the top), and I bit at first... I just wanted to clear up that bit at first, and also note that while the CUA clipboard can easily emulate the X style by automating some actions (in fact DOS boxes do something a lot like it, shame about that rectangular hilight tho), the way the X clipboard model is designed, it can't emulate CUA without "interrupting" a previously automatic process. Moral of the story, it's easier to automate than to hook.

For maximum confusion, Solaris tends to have both an Xclipboard and a copy buffer behind those cut/copy/paste keys on the sun keyboards. Sometimes you get surprising results from them.

--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Re:Cut-and-Paste in X beats the competition... by adrianbaugh · 2004-01-23 03:02 · Score: 2, Interesting

It overwrites it as the active clipboard selection, sure. That doesn't mean it empties the entire clipboard, for example in KDE if you click on the klipper icon in your system panel you can choose from recent text selections.

Where copy'n'paste really sucks is the almost total lack of support for handling anything beyond text selections. I can easily select an image in exactly the same way and X has no problem with shoving this selection into a copy buffer somewhere, but very few applications are capable of using this. In my view the single most useful step forward for X usability would be if the app designers went and implemented media copy'n'paste handling properly. If I select an image in firebird I ought to be able to drop it into konqueror, gimp, openoffice etc. X can cope but as of now the applications put their fingers in their ears and sing "la la la I can't hear you".

--
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Re:Cut-and-Paste in X beats the competition... by sloptaco · 2004-01-23 05:21 · Score: 2, Interesting
Ummm... I don't think that was the argument. Nothing is inherently "wrong" with ctrl-C Ctrl-v. Think of the two processes and compare hand movements:

X:
1. [Mouse] Left-Click and select Text.
2. [Mouse] Left-Click destination.
3. [Mouse] Middle-Button paste.
Doze:
1. [Mouse] Left-click and select text.
2. [Keyboard] CTRL-C
3. [Mouse] Left-click destination.
4. [Keyboard] CTRL-V
Now, from an objective standpoint (or as ergonomist analyzing the 2 processes) - pretending you are not used to one method over the other - which is better?
--sloppy
Re:Cut-and-Paste in X beats the competition... by phoenix_rizzen · 2004-01-23 05:24 · Score: 2, Insightful

The problem with PRIMARY is: how do you select text in one document, then select text in another document that you want replaced, then paste the text from the first document???

The only way around this is to delete the text you want replaced first, then select the replacement text, then paste it into the correct location. This requires flipping between the two docs/apps/whatevers at least twice. Why??

The vast majority of the time, I am replacing text with previously selected text. Or moving text around. And having the PRIMARY buffer overwritten when all I'm trying to do is select text is a royal pain in the ass.

Selecting (highlighting) text and copying text into a buffer should NOT be the same action.

This is even more of a pain at a console.
Re:Cut-and-Paste in X beats the competition... by Sunnan · 2004-01-23 06:32 · Score: 2, Informative

If you're seriously going to attempt to hold up EMACS as an example of good user interface design, please just stop now.

Emacs has a lot of problems compared to modern day applicions, but also a lot of advantages. It's a nice consistent interface to a lisp system.
But you're pulling a straw man - I only said that that particular keyboard shortcut for clearing the address bar was good because it's not just out of the blue, it's the same as in bash, zsh, most readline/editline applications, most application period - including all cocoa ones.

Right, but this adds two extra steps which require the user to move their hand from the mouse to the keyboard.

And you're pressing C-v with your nose?

The fact that you even need to explain the concept to me shows how much of a mess it all is.

No, it's just that you must've missed something.

Listen: you can forget completely about the primary selection buffer (the select/middle-button thing). You can select copy/paste from the menus, or use shortcuts (most often C-c, C-x and C-v as on Windows) just like on Windows and it will work. No need to spew "go back to the drawing board" bullshit. It works now.

And I can use the primary selection just like I like to do.

I repeat: it works just as on Windows.

If you don't want to have it explained, you shouldn't spread misunderstandings about it.

Think of it this way: you've got a normal clipboard buffer like on windows. You also have a completely unrelated feature that allows you to press the middle mouse button to paste what was last selected. Selecting something does not mess up the normal clipboard buffer.

Article about it on CNN! by Anonymous Coward · 2004-01-23 02:28 · Score: 3, Interesting

Linux needs to fix cut and paste

About time they do this!! by fizz · 2004-01-23 02:29 · Score: 2, Interesting

Its been a while since xfree has done anything innovative at all, and with freedesktop making its rounds very quickly, this could lead to really great things for the linux desktop.

Okkkay... by starseeker · 2004-01-23 02:29 · Score: 4, Interesting

So, how do the new developments at freedesktop.org like XCB/XCL fit into this new picture? I'm hoping the exciting new code can be eventually rolled in more easily now?

--
"I object to doing things that computers can do." -- Olin Shivers, lispers.org

Name issues by mnmn · 2004-01-23 02:32 · Score: 4, Insightful

XFree86 should be for x86 versions of X, or X thats generally run on x86-based OSes shouldnt it? Ideally it should be named XFree which will mean a certain implementation of X, yet architecture-free. XFree86 is already used on almost as many architectures as NetBSD supports.

And if x.org is uniting with XFree86, maybe we can keep it simple and just call it X. I know there are other implementations of X, but since x.org owns the copyright, might as well keep the name simple.

At the least, I would lose the '86'.

--
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky

Thank god by base_chakra · 2004-01-23 02:34 · Score: 2, Interesting

Because lord knows XFree86 has one of the dookiest logos ever!

Yes, there are many more important reasons why the merge is a positive thing, but when I first started using Linux as a teenager in 1994, I loved the X11 logo, and it definitely contributed to my perception of Linux and UNIX. Let's face it: the X Consortium's logo feels clean and elegant, but it looks hard and deadly.

Good news... by kaiwainz · 2004-01-23 02:38 · Score: 4, Insightful

I just hope that with this new, more optimitic outlook, more developers will come on board and contribute new and refreshing ideas to the development of X.

The unfortunate thing with X is that it is so important to *NIX and yet it receives less attention than the kernel. Sure, X11 isn't sexy but it a very important component none the less.

What I hope by the end of this year is a strong cohesive X server development team/community with good links to IHVs and an active programme in place to encourage people with new and exciting ideas to come forward and discuss them.

What I would also like to see is a situation where the X specification becomes more than just what we see today. We need an encompassing standard which not only includes what we have today but flexible enough to adapt to new extensions as they arise.

Along with these extensions, the toolkit communities need to work closer together with X and each other and work towards an X11/Consortium backed HIG of which all toolkits conform to. What I am trying to get at is this, different tool kits are great, each community can concerntrate on developing the strengths of that particular toolkit, however, for this choice on one hand and the adoption of Linux on the other hand to continue, there needs to be a standard set down. Once that standard is set down and the the two, X + toolkits, work closer together and allow better interoperability, the net result should be applications which look consistant no matter what toolkit is used.

windows desktop killer by pleasetryanotherchoi · 2004-01-23 02:39 · Score: 3, Interesting

CNN has a story today in which various people purport that Linux isn't ready for desktop prime time but has a window (rimshot) of opportunity to establish itself therein before the release of Longhorn in 2006.

Might this be a step in the right direction? Your fabled bluehaired grandmother doesn't want to choose between different window managers, etc. Hell, she doesn't know what a window manager is and doesn't want to know. Try to explain various incarnations of X to her and watch granny sizzle.

Re:windows desktop killer by fuzzybunny · 2004-01-23 02:58 · Score: 2, Interesting

Yes, true. However, take a walk around your average company sometime, and try to peek at peoples' desktops.

Notice background images, scrollbar positions, whatever. They like to change things around.

Now, if you're smart, you'll use window managers as nothing more than a logical extension of this--any good display manager lets you choose which window manager (assuming you configured it) to start with. Bundle several decent WMs with, say, kdm, present it as "desktop environment style" or something silly PEBKAC-friendly, and you have a winner.

And the beauty of it is, those of us who want to can still customize shit to our heart's content.

--
Cole's Law: Thinly sliced cabbage

Nothing. by MarcQuadra · 2004-01-23 02:41 · Score: 3, Insightful

It will mean nothing for them. All this is is a consolidation of duplicate functions in administration of the projects, and maybe not even that.

KDE and GNOME are totally insulated from the poitics and even a lot of tht technical issues surrounding XFree86. X11 and the projects that run under it are very different beasts.

Now if users migrated from X11 and started using display projects like Fresco, Y, or even FrameBuffer, the KDE and GNOME teams would have to write a air amount of new 'connector' code and rework some libraries.

--
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails

Re:Nothing. by Ianoo · 2004-01-23 03:52 · Score: 2, Informative

Yes, and GTK relies on the GDK, which has also been ported to Win32, MacOSX, Cairo and DirectFB.

Unix Philosophy by RAMMS+EIN · 2004-01-23 02:42 · Score: 3, Interesting

"If you want copy and paste, write a deamon to manage it"

I agree with that stance, though. The problem is not that there is no support, it's that there is too much support. KDE and GNOME do it differently. Some applications do it differently yet. If I select text in Mozilla and press Ctl+C, it goes to a different buffer than just selecting it. Etc...

My solution would be a module (lkm, library, daemon, I don't care) that handles it for all apps (be they console, GTK, ...), preferably doing it the select and paste way as well as the keyboard way (which could add support for named buffers). U am not writing this, though, because it would merely add yet another standard, and besides, I don't care enough. It works for me as it is now.

--
Please correct me if I got my facts wrong.

Re:Unix Philosophy by somethinghollow · 2004-01-23 02:58 · Score: 2, Interesting

A daemon would only be better than having X or some other program if I could switch over to TTY* and paste. And if we are going that far, maybe copy from the TTY and paste to the TTY or X.

Garbage Collection by RAMMS+EIN · 2004-01-23 02:49 · Score: 2, Interesting

``One of the consequences is that if you select text and close that program then that data is gone!''
Sometimes I think the proponents of LISP-OS are right. Everything in one address space, no unnecessary copying of data or checking permissions.

If you select data, the clipboard obtains a reference to it. Close your app, the reference is still there and you can still paste the data. Replace the reference in the clipboard and your data gets garbage collected.

--
Please correct me if I got my facts wrong.

Clippy the deamon by StrawberryFrog · 2004-01-23 02:52 · Score: 4, Interesting

"If you want copy and paste, write a deamon to manage it"

I've been wondering for a long time why this hasn't happened already. How on earth can it be hard to come up with a daemon that can recieve, store and reguritate small blobs of text or binary data?!?

Best of all, it wouldn't depend on which gui you were using. It could work with all of them. It wouldn't depend on any gui being present all.

With a standard clipboard service/daemon, you could do stuff like cut in mozilla or a KDE app, and paste in commandline vi/emacs or reboot and paste into a gnome app.

--

My Karma: ran over your Dogma
StrawberryFrog

Re:Clippy the deamon by CommandNotFound · 2004-01-23 03:20 · Score: 5, Informative

Ok, responding to my own post, X already handles non-text items in the clipboard, which would presumably be available to all remote clients. The problem is that KDE/Gnome apparently do not use these facilities.

The link I found in a post below is here

Not Slow by SyntheticTruth · 2004-01-23 02:56 · Score: 5, Insightful

I am *so* tired of being say that X is slow. I use X everyday, at work and at home, and never, ever has it been slow. There are some *applications* that are slow, most notable among them OpenOffice running on a Pentium 400Mhz machine, but on my 1Ghz+ machines it's quite nice.

The X Server has never been slow for me, and I really wonder where the myth that running X is slow. I have plenty of apps that run rather speedily on my X boxes that take longer on faster Win32 based machines. (Firebird comes to mind.) And just for the fun of it, I use a PyQT text editor that I wrote to teach myself PyQT -- it's interpreted, gui-based text editor -- and it launches and displayed in under a second on this Pentium 400Mhz machine.

No, X is not slow. The apps are.

I already saw this coming by HAJS · 2004-01-23 03:09 · Score: 5, Funny

It is absolutely clear why the XFree86 team-members joined the X-Consortium:
They wanted this cool x.org mail-adress

And in KDE by brunes69 · 2004-01-23 03:19 · Score: 2, Informative

So does KDE 3.2

KControl -> Desktop -> Size & Orientation

For added convience check the box there that adds a system tray applet.

Re:Hopefully (IDEA!) by gosand · 2004-01-23 03:24 · Score: 3, Funny

This has nothing to do with X and has everything to do with a long standing bug in Mozilla, which fails to use the X clipboard correctly.

Dammit! Why can't the browser just be integrated into the OS?

*ducks*

--

My beliefs do not require that you agree with them.

You are factually wrong by FreeUser · 2004-01-23 03:25 · Score: 2, Informative

WROGN!

That is not cut-paste scheme since you cannot cut and paste with it.

Really? I've been using X for over a decade and have never had any difficulty cutting and pasting with it. Perhaps you are dealing with user issues, and not design issues of the Window system or its applications.

I want to paste (and not cut)? Left-click/hold and select, point at the target and middle click.

I want to cut-and-paste? Left-click/hold and select, tap delete (or backspace), point at the target and middle click.

We need only one standard (by default, at least) and it seems that the market has chosen it

The 'market' hasn't chosen anything, any more than the market had chosen horse carriages over automobiles in 1920 simply because most people were still using the old technology.

Flames away, but I am still right.

Saying your right doesn't make it so, any more than Bush saying there are WMDs in Iraq make it so. Flames aren't required to rebut you: five seconds using X is sufficient.

--
The Future of Human Evolution: Autonomy

Re:You are factually wrong by Luyseyal · 2004-01-23 03:50 · Score: 4, Interesting

Cut-n-paste works under X, but I hate that Move-n-replace is ugly.

Windows:
1) Highlight new text
2) Ctl-x
3) Highlight text-to-be-replaced
4) Ctl-v

X:
1) Highlight text-to-be-replaced
2) Delete text-to-be-replaced
3) Highlight new text
4) Delete new text
5) Paste new text

I'd like to see X do something like this:
1) Highlight new text with left button
2) Keep holding left button and press right button to cut to clipboard
3) Highlight text-to-be-replaced with left button
4) Keep holding left button and press middle button to copy from clipboard

This wouldn't work for Left+Right=Middle, but Ctl-x|c|v would work for those people.

What do you think? I find move-n-replace to be very handy for text editing.

-l

--
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Re:You are factually wrong by Anthony+Boyd · 2004-01-23 06:36 · Score: 2, Insightful

X:
1) Highlight text-to-be-replaced
2) Delete text-to-be-replaced
3) Highlight new text
4) Delete new text
5) Paste new text

I think you've just unknowingly illustrated MY pet peeve with the X system for copy/paste. That is, step 1 MUST be done before step 3. This doesn't reflect my normal thinking -- If I want to copy/paste, I first get the text I want and then I go to highlight the text I want to delete. The problem, of course, is that the system wipes out the text I want when I highlight the text to delete. This system is fragile, easily breakable. Your alternative proposal is stronger. The Mac and Windows methods are stronger, too.

--
My Greasemonkey scripts for Digg &

you whatchamacallit by Sunnan · 2004-01-23 03:35 · Score: 4, Informative

and it seems that the market has chosen it

"the market has chosen it" is and always will be a bullshit statement.

X has both, and it has always had both. They're not "incompatible". Middle click inserts the primary selection, while application can access the clipboard buffer provided by X, for years and years long before KDE and GNOME with things like meny options or keyboard shortcuts. The GUIs use C-c, C-x and C-v just like Windows. (In which language does paste begin with v?)

That you can choose to use the clipboard buffer does not mean that we lazy geeks should be hindered from using the middle-click method. Neither is in the way of the other and they never were (except that for a while one of the DEs had a wrong implementation that used the primary selection buffer for C-c/C-x. This was dealt with accordingly - as a bug).

JWZ explains it nicely.

Flames away, but I am still right.

Not really.

Article seems confused by plcurechax · 2004-01-23 03:38 · Score: 4, Insightful

I seriously doubt that X.org, the new face of the former X Consortium (members like HP, IBM, Sun, XFree86), has merged with XFree86. They have two totally different goals. The goal of X.org is to promote a single X (currently 11R6) standard between different vendors and implementors. XFree86 was and is a member of X Consortium/X.org, and is a specific (Open Source) implementation of the X standard.

The rest of it is too confused for me to make any real sense out of. I suspect that there is some good vibes between members of X.org, freedesktop.org, and hopefully XFree86 - which is a good thing. Key developers of XFree86 (e.g. David Dawes and Egbert Eich) and X.org (Alan Coopersmith) now seem eager to move forward and work together on making better software. Getting people all on the same page and working together is a lot of work, because of different interests and goals, but I think that XFree86 will see 2004 as a busy year with lots of improvements.

I really hope that freedesktop does not widely diverge from XFree86, let it be a test bed sure, but not a competing product.

Wait a minute! Where's "Overly Critical Guy"? by Anonymous Coward · 2004-01-23 03:47 · Score: 2, Insightful

When the XF86 Core Team decided to disband three weeks ago, weren't we told by Overly Critical Guy that this indicated that XF86 was falling apart rather than healing itself and that it was proof that the open source community can't produce sufficiently reliable software?

Where is that guy? I want his insights on how to understand these developments.

Re:Heretical thoughts by Just+Some+Guy · 2004-01-23 03:54 · Score: 4, Informative

That's not heretical - it's ignorant [1]. It's been said time and time again, here and elsewhere, that the networking code in XFree86 is not a bottleneck and replacing it would not speed up the display.

Repeat: removing the networking code would not make X any faster.

So, given that including the gee-whiz features that a lot of us require in our daily usage has absolutely penalty for "average joe's grandma", why would you want to remove it? That's like saying that the average user won't use sed, so RedHat should remove it to make Linux faster.

[1] Webster: "uninstructed or uninformed". I don't know of a "nice" substitute, that is, one without the negative connotations. Don't infer malice. :-)

--
Dewey, what part of this looks like authorities should be involved?

Great name changes, please... by WWWWolf · 2004-01-23 03:56 · Score: 2, Interesting

This is good news, I hope things will change to better over time.

I hope this will also be the end of the "XFree86" name/brand. Let's face it, it's not really that great name - Not couting "GNU Anything", I've always disliked names that push the "free software" or "openness" aspect, so names with "Free" in them always sound silly. The ideology should be in the heart, not the name.

Also, the whole name is a joke on something that hasn't been around for a while. I hear it's supposed to be a pun on "x-three-eight-six" - X386, which was what the project was called until 1992. I'm sure whoever came up with "XFree86" name had a good laugh with fellow developers, but now, over a decade later, this obscure fact has been completely buried in sands of time. No new users find it funny because they have no idea where it comes from - it has turned from silly and odd-looking to just plain odd-looking. Kind of like "DivX ;-)". Yawn.

"X11 Public Implementation" sounds nice and technical, however =)

Forking / Merging by sirReal.83. · 2004-01-23 04:07 · Score: 2, Interesting

If forking is one of the "bad things" that can happen to OSS, merging is one of the "good things." Multiple similar projects, each with their own advantages, merge together to make... damnit, what was that huge robot in the Power Rangers called...

I like it by FreeUser · 2004-01-23 04:28 · Score: 2, Interesting

I'd like to see X do something like this:
1) Highlight new text with left button
2) Keep holding left button and press right button to cut to clipboard
3) Highlight text-to-be-replaced with left button
4) Keep holding left button and press middle button to copy from clipboard

What do you think? I find move-n-replace to be very handy for text editing.

That would be a handy enhancement.

I'd actually like to see something a little more general.

Cut-and-paste works as it is now, but make the buffer a stack (a little app could even display the buffer stack graphically)

Middle-click+number pulls that item from the stack.

Middle click pastes stack[0]
Your #4 (left and middle button) pastes stack[1] (your second cut has pushed it up and replaced stack[0]), as does middle-click+1.

middle-click+11 pastes stack[11],
middle-click+756 pastes stack[756] (if your stack is so large and you remember what you cut 756 steps ago ... but again, here a handy graphical app showing the stack could be handy for such ... expansive uses of the buffer).

This returns keystrokes to more complex cut-and-paste operations, but 1) keeps basic cut-and-paste, copy-and-paste simple the way they are now, and allows for much more expandability in pasting older cuts and doing other complex c by only adding a couple of keystrokes.

--
The Future of Human Evolution: Autonomy

Whither XFree86 4.4? by F.O.Dobbs · 2004-01-23 04:40 · Score: 2, Insightful

Is this going to get stuck in RC-limbo or are they going to finally release it?

Thanks,
F.O.Dobbs

Widget based ineffecient. by Inoshiro · 2004-01-23 05:00 · Score: 2, Interesting

If we were stuck with a widget-based implementation, I'd have to upgrade my X server every time Xlib, GTK+, WxWindows, QT, Motif, Lesstif, etc, changed. That's stupid.

What's not stupid is using the existing protocol, which is fast (it ran well on 10 mhz SPARC machines 15 years ago!), efficient, and easy to compress for slower links.

--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.

I have a feeling... by bonch · 2004-01-23 05:02 · Score: 2, Interesting

I have a feeling your post will be ignored, and the XFree86-heads will continue to call X's system of copy-paste "the most elegant they've ever seen," etc.

Yours is the most level-headed, rational criticism of X's copy-paste system I've ever seen, but as I've said before, X users have this bizarre fear of change and want things to stay the same for another 20 years.

I am with you on the unified server front, but by PotatoHead · 2004-01-23 05:44 · Score: 2, Informative

you are barking up the wrong tree on the local / remote display issue.

The network stuff does not hurt X one bit with the display is local. Your particular X server / driver combination might be slow or not depending on your environment, but that does not mean X is slow.

Changing things now would break a lot of things that do not need to be broken. Everything written for many years now makes use of X. Do you really think we should start tearing into that? Sure, build a compatability layer right? Well, why not just make the changes to X that need to be made instead?

We need X to continue to be a feature of Linux. Not an addon, but a feature. X is what seperates UNIX machines from all the other machines out there. X preserves the multi-user attributes of UNIX at the GUI level.

Most people here bitchin' about X really have no idea what multi-user computing is about. I have written about this many times here before, but what the hell. As many times as it takes...

X allows you to distribute your computing as you see fit. It scales very nicely. It also needs more work to fit in to the single home user experience. This can be done without breaking it or mangling it into something less capable.

Besides, Microsoft would love to see X die. Then they would no longer be at a disadvantage in the display area. Just had another thought in this area. With a Microsoft (and others) system, you need to actually have a copy of a document in order to make use of it. Thus, they are putting in lots of ugly DRM stuff to limit what people can do.

With X, you can give the user the ability to work on a document, within limits you specify, yet not actually allow them any sort of real access to the document in question. How? Set up a machine with a limited set of tools specific to your document access needs. Then remote the display to the users computer. This is possible because of two UNIX multi-user features; namely, X and the ability for a program to SUID and run as its owner, not the user asking it to execute.

Want unified fonts for every machine in the building located in one place ready to use? Host a font server.

Tired of installing basic applications on every last machine? Host them on an application server for everyone to share. Make a change in one place and you are done. No pushing software through the network, no login scripts full of reg hacks and such.

Running a tweaked window manager for some reason? Host it as well.

Have a group of people who all need to use a powerful machine / application combination on occasion, but spend much of their time running normal applications? You could buy them all top of the line machines, or you could buy one really nice machine and let them *all* use it when they want to.

Of course you could just buy them all really nice machines and spend the time to load the application onto all of those machines. Most applications of this type require licensing as well. Getting that license to float across all of those machines takes time and effort as well, not to mention the dollars companies ask for that option.

Or, install it once and let X do your work for you.

All of these things might seem goofy to you if you are running a couple of machines at home, or have never really been exposed to a multi-user computing environment before. Don't feel stupid, check out this actual event that happened to me at SUN a while back.

I was there to install an application, but the admin was sick that day. Since I had flown in, things needed to happen that day. So, I installed the application in the user-space, then gave the others instructions on how to make use of it. (One user had a pretty nice machine.)

The guys were stunned! They said that was pretty cool. They did not know they could do that, somebody should market that stuff. Told them a three letter company was trying hard to do just that.

(Blank stare, then understanding... SUN!)

These guys w

--
Blogging because I can...

I call bullshit by PotatoHead · 2004-01-23 06:03 · Score: 4, Insightful

X is not slow by design. Look at SGI machines, they all run X. Even the really old 30Mhz ones will provide a nice snappy GUI experience and they were made in 91! The linux implementation needs further refinement which is some of what this project looks to provide (finally).

As far as the eye-candy goes, you are right for many casual/home users. With regard to enterprise computing you are dead wrong. People are supposed to be working with their machines. The less that gets in the way of that, the better.

Do we need the work? For sure. Is any of this stuff work replacing X. Not a bloody chance. X plays hard in the enterprise computing space, saving money & time through central administration and effective use of avaliable computing resources. Buffers simply cannot compare.

Network transparancy was wonderful and innovative 20 years ago. Just think, networks were young then and they still bothered to build it. Today, we have networks everywhere, and people call for the removal of the network display feature? WTF! Now is the time to be pushing it because the networks/ OS / hardware are all dirt cheap!

The only reason people say this sort of thing is because of the PC mindset.

X is great today, and it is going to continue to get better. Most of the old slashdot responses are dead on in that regard. Will we get the eye-candy nirvana you claim other systems have?

Given the excellent response qualities of my SGI, running X, I would say it is only a matter of time for Linux...

--
Blogging because I can...

From XFree86.org by Icy · 2004-01-23 06:06 · Score: 2, Interesting

XFree86 has not Merged with X.Org
[23 January 2004]
There are several news items claiming that X.Org and The XFree86 Project have merged. This is a blatant lie. The XFree86 Project remains an independent organisation, and will continue as operate as an independent organisation according to its mission statement. There has been no discussion with X.Org about any such merge, let alone any agreement to a merge.

X.Org is a vendor-sponsored organisation, formed by vendors to best suit the interests of those vendors; XFree86 is an independent volunteer organisation, with a focus on the individual. Therein lies the rub.

Re:Then answer it once and for all by Just+Some+Guy · 2004-01-23 06:25 · Score: 2, Informative

Crappy drawing mechanisms. My understanding is that Gnome and KDE render most of their own bitmaps, then essentially "upload" the prepared image to X. X is not optimized for this sort of interaction. What is does do exceptionally well is accept (non-blocking) a list of commands ("draw this rectangle, make a circle here, now move this block from here to there..."), process them in a batch (internally reordering them for optimal throughput), and letting the calling process know that it's finished.

I know everyone hates Motif (myself included), but try running one over a remote X session sometime. You'd be amazed how fast a widget set designed to run well on X can actually be. On the other hand, I can watch KDE apps draw individual pixels over a slow link.

I'm not entirely sure I'd blame Gnome or KDE, even though the poor performance is definitely their responsibility. They were designed more for local desktop use, and maybe it was much easier to Get It Right by doing things the way they chose. That doesn't mean that X is inherently slow, though, just because those toolkits don't take full advantage of it.

--
Dewey, what part of this looks like authorities should be involved?

Re:Cut-and-replace takes longer in X than Windows by Wesley+Felter · 2004-01-23 07:12 · Score: 2, Informative

I would prefer the X developers to just implement the Windows method, instead of requiring users who migrate to learn a new method.

Ctrl-C and Ctrl-V work fine in all the modern (i.e. GNOME) apps I've tried.

In a related vein, does anyone know how to disable the regular CTRL-C in a KDE terminal window, perhaps by making it into a menu item instead? Then I could finally use CTRL-C in the terminal.

Of course, the correct solution is to have a separate Command key, and use Command-XCV for cut, copy, and paste. This works great on the Mac. :-)

93 of 597 comments (clear)