Slashdot Mirror
X.org and XFree86 Reform
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".
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.
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.
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 =)
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."
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.
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....
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.
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.
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
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.
With a proper XF86-config file (all resolutions specified) you can do that on the fly anywhere.
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....
Not Buzzword 2.0 compliant. Please speak english.
> 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.
Correct on both accounts. You haven't read the article and X is separate from the window manager. So what's the point of your comment?
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
So does KDE 3.2
KControl -> Desktop -> Size & Orientation
For added convience check the box there that adds a system tray applet.
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
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).
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
Stop complaining :) You get a long way with knowledge....
Holy Shit. The irony of this statement is maddening.
What's it like to be a fucking idiot?
As others have pointed out, this does two different things.
Anyway, it's two steps easier than you make it out to be in Windows: Right click desktop, properties, click the settings tab, change resolution, click ok.
I like X, I know X, but to say it's as intuitive and simple to use as the integrated display infrastructure Windows has is nothing short of a public display of stupidity.
"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.
Not really.
Yes, and GTK relies on the GDK, which has also been ported to Win32, MacOSX, Cairo and DirectFB.
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?
SCM = Service Control Manager
You can restart a service on failure, run a command or etc etc...
> 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?
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.
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...
from xfree86.org
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.
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?
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.
And you're pressing C-v with your nose?
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.
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.