Slashdot Mirror


Is KDE 4.0 the Holy Grail of Desktops?

An anonymous reader writes "With KDE 4.0 being expected some time this year, expectation runs high in the linux/unix users camp and the media read a lot between the lines of what the KDE developers say and do. In some ways KDE will provide a standard as to how a desktop should look and behave. This interesting article wonders whether KDE 4.0 will become the complete desktop which will meet the needs of a wide cross section of computer users. One of the common complaints that some Linux users have over KDE is that it is too cluttered. And by addressing this need without putting off the power users, the KDE developers could make it an all in one Desktop. Keep in mind that KDE 4.0 is based on Qt 4.0 and so can be easily ported to Windows and other OSes too which makes this thought doubly relevant."

1 of 511 comments (clear)

  1. Re:Let's Get Serios by Aaron+Isotton · · Score: 0, Redundant

    As current Linux user that mixes everyday Gnome, KDE, and desktop-agnostic apps at home and work, I can assure you the "clipboard hell" issue has not been fixed at all. And I'm not anti-Linux trolling, I'm a Debian fan and used to be a package maintainer there. But you should be able to admit where Linux is just weaker than Windows or OS X. Here's an extract of the various "clipboards" or "yank buffers" or whatever they're called I deal with on a daily basis: - The venerable X11 buffer - select and middle click. This works great BUT if you happen to select something by mistake whatever you had in the clipboard before has gone. This is especially annoying if you select a link from somewhere and want to *replace* the URL in the address bar of Firefox. What you intuitevely do is the following: 1. Select the link in some program 2. Alt-Tab to Firefox 3. Select the link currently in the location bar (in order to replace it) 4. You just lost because the second selection replaced the first. - Then there is the Gnome Clipboard (I believe that's what it is called). This is the Control-C, Control-V clipboard which works like in Windows - with one subtle difference. If you close the program you have cut/copied from, the content of the clipboard is *gone*. 1. Select and copy some text in some program 2. Close the program 3. You just lost - Then there is the vim yank buffer. Yes, you can have multiple yank buffers and probably program them and whatever. But it is totally separate from the other clipboards. Vim even stores it when you close and restart vim. Thus you can: 1. Open vim, yank some text (that's "copy" for non-vimmers) 2. Reboot your machine 3. Log in from another machine with ssh 4. Paste it back. You win! BUT of course it doesn't work across multiple concurrently running instances of vim. Don't tell me that I should use only one vim for multiple files and splits and all that crap. I want to be able to yank and paste across vims. Which you can't. And if you use gvim (the vim with gui) then pasting from the Gnome clipboard is as easy as...pressing (no joke) ESC : " g P They must be out of their mind. - And then there's the Emacs buffers (I believe it's called the "buffer ring" or something like that) which are again similar to the ones in vim. I hope I don't offend any emacs users here since I'm not that familiar with it, but I know that they are again incompatible with everything else. What Linux needs is ONE universal clipboard. Just ONE. It shouldn't be part of Gnome, KDE, Xfce or even X11. It should be a system service. So you can copy and paste LIKE A SANE PERSON in ALL PROGRAMS. Just like on Windows. Or a Mac. You could throw in persistence across reboots. And maybe across different sessions (say, local X11 and remote SSH). Then it would even be better than everything else. I'm actually thinking of implementing something like that - maybe even with X11 and Gnome clipboard bindings to "unify" them finally. There should *definitely not* be multiple buffers, rings and crap like that. 99% of the time they are just confusing. If a program *really* needs multiple buffers - and most do not - they could still implement that ON TOP of the universal clipboard. It's ok if *that* is not compatible across programs. Greetings from one who loves, and loves to works with Linux but just *HATES* its clipboard functionality.