X.org and XFree86 Reform 597
albepetr writes "NewsForge is reporting about a press conference held today at LinuxWorld 2004 in New York, where some members of the X Consortium, XFree86, and freedesktop.org announced that X.org and XFree86 have merged. They claim that the reformed group will be working together to bring "not just more eye candy but new functionality" to the X Window Manager for Linux and Unix." Newsforge and Slashdot are both part of OSDN. Update: 01/23 18:06 GMT by M : XFree86.org denies the story. I think a more accurate description of the event might be something like, "XFree86 core developers leave XFree86, join X.org, remaining people of XFree86 are peeved".
Good for everybody (Score:4, Interesting)
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 (Score:2, Interesting)
Like the ability to reconfigure X on the fly. Right-click on desktop -> properties -> change desktop resolution. Why can't it be that simple? Well, a prerequisite to making it that simple is for X to be reconfigurable on the fly without having to quit out of X, run some "configurator" program, and then restart X and hope it works. If the hooks in X to dynam
Re:Good for everybody (Score:4, Informative)
-Erwos
And in KDE (Score:3, Informative)
KControl -> Desktop -> Size & Orientation
For added convience check the box there that adds a system tray applet.
Re:Good for everybody (Score:2, Informative)
KDE supports this (this is only possible because the underlying xfree 4.3 supports it offcourse).
See this dot.kde.org [kde.org] post about it.
Re:Good for everybody (Score:2)
HAHAHAHAHA
BWAHAHAHA
Re:Good for everybody (Score:3, 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 (Score:4, Insightful)
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
Except that those two tasks perform different things.
Jason.
Re:Good for everybody (Score:5, Informative)
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).
Hopefully... (Score:3, Interesting)
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.
Re:Hopefully... (Score:4, Insightful)
This is the one case where I say I like the Windows way better then the Unix way.
Unix Philosophy (Score:3, Interesting)
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,
Re:Unix Philosophy (Score:2, Interesting)
Re:Hopefully... (Score:5, Insightful)
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.
Re:Hopefully... (Score:4, Insightful)
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, ...
Re:Hopefully... (Score:4, Interesting)
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.
Re:Hopefully... (Score:3, Interesting)
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 compu
Clippy the deamon (Score:5, Interesting)
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.
Re:Clippy the deamon (Score:5, Informative)
The link I found in a post below is here [jwz.org]
Oh, no, not again (Score:4, Interesting)
Cut'n'paste works on X's level.
The problem is (or probably: was) not with X, but with Gnome and/or KDE.
Cut-and-Paste in X beats the competition... (Score:4, Interesting)
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.
Re:Cut-and-Paste in X beats the competition... (Score:3, Insightful)
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).
Re:Cut-and-Paste in X beats the competition... (Score:2)
Tsk. X has more than one buffer. The one you're used to on Mac's and Windows' is CLIPBOARD (IIRC) and the one he refers to (copy on select, paste with a click) is the PRIMARY buffer.
One of the things I hate the most on Windows UI
Re:Cut-and-Paste in X beats the competition... (Score:2)
Re:Cut-and-Paste in X beats the competition... (Score:3, Insightful)
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
Re:Cut-and-Paste in X beats the competition... (Score:3, Interesting)
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
Re:Cut-and-Paste in X beats the competition... (Score:3, Insightful)
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 a
You are factually wrong (Score:3, Informative)
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
Re:You are factually wrong (Score:5, Interesting)
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
I like it (Score:3, Interesting)
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 litt
Re:You are factually wrong (Score:3, Insightful)
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
Re:Cut-and-replace takes longer in X than Windows (Score:3, Informative)
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 pas
you whatchamacallit (Score:5, Informative)
"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. [jwz.org]
Not really.
Re:Cut-and-Paste in X beats the competition... (Score:2)
Re:Cut-and-Paste in X beats the competition... (Score:3, Informative)
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 re
There are two clipboards. (Score:2)
Once you understand the difference between the clipboard and plain text DnD, you'll see why both are important. Espe
Re:Cut-and-Paste in X beats the competition... (Score:2)
As for 'click to focus', that's highly subjective. I personally like it very much, I can't stand the focus-follows-mouse concept. It hurts my eyes, especially after long hours in front of the monitor.
Re:Cut-and-Paste in X beats the competition... (Score:3, Informative)
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 pe
Re:Hopefully... (Score:5, Informative)
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 (IDEA!) (Score:4, Funny)
Dammit! Why can't the browser just be integrated into the OS?
*ducks*
Re:Hopefully... (Score:3, Funny)
But I'm using Mozilla on X, you insensitive clod!
Re:Hopefully... (Score:5, Interesting)
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.
Garbage Collection (Score:3, Interesting)
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.
Re:Hopefully... (Score:2, Insightful)
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-an
Re:Hopefully... (Score:3, Insightful)
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
Not quite right (Score:2)
Down at the Xlib level it doesn't even do that. The client side code (usually in a widget library) has to check which text has been selected
where when the mouse was pressed and moving (or whatever the policy is) and keep it in a buffer. All the X server itself does is provide selection request and selection notify events
which do nothing more than allow clients to grab chunks of data from each other via the server. They could be used for anything really, not just cut-n-p
Re:Hopefully... (Score:3, Interesting)
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... (Score:4, Informative)
> 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?
I have a feeling... (Score:3, Interesting)
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.
Re:Hopefully... (Score:4, Informative)
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.
Eric RayRNond strikes again! (Score:2)
People, try to read the contents of the post before you moderate. Just because you don't understand it, doesn't mean it's insightful -- it just means you don't understand it. Maybe because it's info, or maybe because it's random garbage like this parent post.
That's nice, more of that (Score:5, Insightful)
Great for *nix (Score:2, Insightful)
Window Manager?? (Score:3, Troll)
I'm seriously confused now.
Re:Window Manager?? (Score:5, Informative)
The window-managers are apps running on the X-server.
Although. I cannot read anybodys minds =)
UnitedX (Score:5, Insightful)
I still believe the Right Thing is to have an efficient system for local display, and a widget-based protocol (a la PicoGUI [picogui.org]) for remote display, though.
Re:UnitedX (Score:2)
Widget based ineffecient. (Score:3, Interesting)
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.
I am with you on the unified server front, but (Score:3, Informative)
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,
Re:UnitedX (Score:2, Interesting)
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 bette
Re:UnitedX (Score:3, Informative)
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 "e
Re:UnitedX (Score:3, Interesting)
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 sluggishne
Get the name right! (Score:5, Informative)
It is so mostly because it is not a window manager.
X again (Score:5, Insightful)
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.
Re:X again (Score:3, Interesting)
If you really would have taken the time to read the previous X stories on
Re:X again (Score:3, Insightful)
I call bullshit (Score:5, Insightful)
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...
Re:X again (Score:5, Informative)
This tiny version of X is called "KDrive" and it ships with XFree86. Read more about it here [linuxdevices.com] and here [jussieu.fr].
And stop talking about "choice" when you don't even know what choices X offers.
Re:X again (Score:2)
But devices that ``memory- & CPU-limited'' can even run Windows. Sorry, but they are not limited in any way. If you had said: X runs acceptably on a 486/33 with 4 MB core, that would have been something. And let me tell you: it does (at least Xfree86 3.3.6 did). But then, there are other systems that work a lot better on it.
Re:X again (Score:5, Insightful)
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 (Score:3, Informative)
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 usin
Re:X again (Score:5, Insightful)
Yes. For instance, when giving presentations, it is not always possible to try out the projector ahead of time.
Re:X again (Score:2)
Perhaps you have really odd hardware, but since RedHat 7.x, these issues simply haven't existed on any hardware I've installed it on.
Re:X again (Score:2)
I upgrade to the latest xfree/gnome just now and realized that, yes, they have fixed this problem. gracias.
Re:X again (Score:2)
"the X Window Manager for Linux and Unix" (Score:5, Informative)
"...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.
Where's Keith? (Score:4, 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.
Re:Where's Keith? (Score:2)
Re:Where's Keith? (Score:5, Informative)
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.
Re:Where's Keith? (Score:3, Insightful)
Anyway the current development will probably diminish the importance of having something like xouvert.
Quick name change (Score:5, Funny)
this should help programming a lot (Score:4, Insightful)
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.
Article about it on CNN! (Score:3, Interesting)
About time they do this!! (Score:2, Interesting)
Okkkay... (Score:5, Interesting)
Name issues (Score:5, Insightful)
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'.
Re:Name issues (Score:2)
Thank god (Score:2, Interesting)
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... (Score:4, Insightful)
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 (Score:3, Interesting)
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 (Score:3, Interesting)
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 P
I already saw this coming (Score:5, Funny)
They wanted this cool x.org mail-adress
Article seems confused (Score:5, Insightful)
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.
Of course not... (Score:2, Insightful)
Nothing. (Score:4, Insightful)
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.
Re:Nothing. (Score:3, Informative)
Xouvert (Score:2)
Not Slow (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.
Re:Heretical thoughts (Score:5, Informative)
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. :-)
Re:Then answer it once and for all (Score:3, Informative)
I know