Slashdot Mirror
KDE & Gnome Usability Engineers Interviewed
Gentu writes "After the recent flamewar between the KDE and Gnome user camps, OSNews brings together the most influencial KDE and Gnome usability engineers to talk about how they will be able to overcome a number of obstacles in order to 'unify' KDE and Gnome in ways that could bring to the Unix desktop an easy to use, integrated and fully interoperated DE to better compete with the commercial alternatives. Waldo from SuSE and Havoc from Red Hat are taking part to the interview, and also Aaron, the head of KDE's usability."
There is no flamewar. There is no "war".
Users can use whatever they want, the two proejcts get along better than most to be honest.
THis whole fued thing has been overhyped by "news" sites since gnome was created and it's quite silly.
it's just a simple choice of DE, nothing more.
Oh now Linux developers are actually trying to make a unified GUI standard? Its sure nice to see everyone moving to the right idea here, but I am sure people will still complain because it is all about 'choice'...
The one reason that people walk by a Linux system and immediately think it's arcane is typically the use of anti-aliased fonts. People feel much more comfortable learning systems that look pretty. After all, people never bought Windows because it was stable (not that I'm saying this is the only reason or anything, but it certainly helps ...).
In the long run, we're all dead.
So, I plea to everyone that develops new KDE apps, _DON'T_ use that silly K-ism shtick. It was fun the first two versions. It's getting old. Be original for a change, okay? Thanks.
What I would like to see is not another technical feat, but an effort to bring the Linux desk top closer to the a-technical masses.
I've recently had the "pleasure" of reinstalling Red Hat Linux and neither Gnome nor KDE are user-friendly at all. Yes, they do copy the Windows 95 desk top, but no, that's not going to help my father. And don't even start about the built-in file/web/help/and-what-not browsers.
With all this high configurability that's available in both windowing systems, couldn't a group of more human-interface oriented people build a layman interface on top of either Gnome or KDE?
Th reunification, from a user POV, should maybe not be the goal of G/K. Why ? Why have exactly the same features ? With the same political decisions ?
...) they agree on a same format, same interfaces, which is imho very very important.
I think that K and G do things their own way, but when G and K do the same thing (eg icons, desktop files,
I just installed Gentoo, to try out kde 3.1. Well, it is just great. The one problem was this. The FIRST option in Konqueror setting menu is Show Menubar. Click on it by accident (which is easy since it is the first option), and you are in lost world. It was ok for me, since I know how to tinker and find out that control+M turns tyhe menu back (still it was difficult), imagine the newbie hitting this setting. WTF..
Most KDE developers have chosen KDE because they think it is superior. Otherwise they would have chosen Gnome. For example, I worked on Gnome stuff for a while but it was almost unusable for me. Then I decided to give KDE a try and never went back.
So today the fundamental rift is that KDE developers think that C++/Qt is the most productive environment. Using GLib is just no fun, it is painful compared to C++/Qt, Java, C#, basically every modern programmign environment. And I also think that it is not possible to compete with MacOS X and Windows using C/Glib technology. They are already years ahead, and trying to catch up using a more primitive programming environment is crazy. I could understand to go 100% Mono, but C/glib?
I would rather stop developing on GUI software and/or buy a Mac than write GUI apps using glib.
glib is great -- I'd love to see it universally available. If both KDE and GNOME used it as a standard base library...
May we never see th
Unfortunately, getting such a thing into KDE looks set to be next to impossible. A small but vocal minority appear to be dead-set against using even GObject, which only tackles a small subset of the problem of code sharing - the idea of using GObject seems to scare them witless.
I wouldn't normally name names, but it's starting to get very irritating. Neil Stevens and Zack Rusin in particular, (there are others) consistantly object whenver the possibility of using something based on GObject (even when wrapped in the KDE style) is brought up. I've yet to see them state what is wrong with GObject, beyond "it's not appropriate" or "KDE developers should only have to use Qt C++".
To be honest, this isn't the first time I wish KDE had gone with CORBA. Unfortunately, by dropping it before it matured, they blew a hole in the consistancy of the Linux desktop a mile wide, leaving their answer to "how do we get consistancy" to be "only use KDE apps".
"The new start menu is also an abomination. In fact, those two days with Windows XP reminded me why most people hate computers. I'd hate them too if that was all that was out there."
as a linux/freebsd user you would think i wouldn't, but i actually quite like the new start menu. i really like the fact that it adds shortcuts on the fly to your most recently used programs. i think it looks very elegant and it also simplifies a lot of tasks for people such as my mother (the usual metaphor!) in terms of its "My Recent Documents", "Connect To" etc...
my problem here with these guys statements is that they all, and in particular Aaron just makes these swooping opinionated statements without any meat to back them up.
i was also concerned that none of them have much experience with Windows XP. i would assume that apple looks at it all the time to not only imitate things it has done well, but to avoid things it does badly. surely these guys should be analysing osx and XP and doing the same thing?
Ugh. How many times do we need to see this?
"To make commercial apps w/ Qt, you have to pay a liscence for the QPL version since GPL doesn't allow commercial use."
The GPL has absolutely no problem with commercial use. It is really disheartening to see this. I guess MS's FUD had more of an affect than we thought.
I find it highly disturbing that they don't use Windows every so often. I mean, come on, Microsoft spends TONS of cash on usability studies and 99% of the world knows Windows.
I don't want an XP clone (although the thought is not that bad) but if you are creating a new UI, XP should be required study. Both for it's good AND bad points.
They should also use OSX, MacOS9, Be, and any other OS worth mentioning on a regular basis. XP is not the be-all-end-all.
Unix is the ONLY OS without a standard GUI.
IMHO, the KDE vs. GNOME battle hurts Linux on the desktop more than it helps. Great, we have choices. But really, if there was a LINUX GUI, not two half-assed UI's, we could be much further along on our way to a really good UI. Red Hat 8.0 is the only distro to "get" this and they were crucified for trying it.
1. The best code from each would have been used and the worst would have been dropped.
2. There would be twice as many developers.
3. Users would not have to choose their problems.
4. Tech support would be possible.
5. Graphical tools could be made for system configuration and packaging if they did not have to support a multitude of OS's.
Too many options is good for a technical individual, too many options is NOT a good thing for a group. If they can't get together, I hope they both fail or lose mindshare. The Linux community would be better off with it's own standard GUI.
It's not the packaging, the number of distro's or X Windows holding Linux back as I hear so often. It's the desktop. The other problems can be solved with a standard GUI.
If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy. - James Madison
MS did a lot of work on this. Maybe a lot of the results are distasteful - but that doesn't mean one should hide one's head in the sand. There may be some good things and some bad things, but choices can be made more intelligently when there is a broad base of knowledge to draw upon.
(Same comments for Mac UI of course...)
You are obviously just making things up. I think you will find that the vast majority of programs accepts ALL THREE of these.
If you really knew anything you would know that the "inconsistent" program is Emacs, which takes Ctrl+Y to paste. There are also very old programs that have no idea about pasting at all, but I'm sure you can find some Windows programs like DOS ports that don't pay attention to pasting either.
And having debian prefixing kde- or kde_ to the start of the package name is beyond reason?
Now that I think about it, that is silly, and so is your comment. If you are worring that it is a KDE package, you are obviously not task driven, but environment driven which doesn't make much sense IMHO.
This is of course different when we talk about configuring the environment, but every application under the sun doesn't need to have k or g prefixed to it. All it does is give the impression that the program is more important because of its environment and not its function.
Bye!
A small but vocal minority appear to be dead-set against using even GObject, which only tackles a small subset of the problem of code sharing - the idea of using GObject seems to scare them witless. I wouldn't normally name names, but it's starting to get very irritating. Neil Stevens and Zack Rusin in particular, (there are others) consistantly object whenver the possibility of using something based on GObject (even when wrapped in the KDE style) is brought up.
Can you give a link to this discussion? I've searched the mail archives at lists.kde.org but I can't find any mails from Zach Rusin discussing the GObject issue.
Also, it doesn't seem fair to bitch in Slashdot about people because they don't support the path you would like for KDE. If you have technical arguments for your position, present them in the appropriate mailing list. If you don't, name-calling is not the solution.
In other messages you've admitted you don't even know C++, so your experience in KDE development must be inevitably small. These people probably know quite a lot more than you about KDE's internal workings, so why not show a little respect for their position.
-- Repeat with me: "There is no right to profits".
You make some good points.
However, you must avoid making the assumption that anyone who wants "choice" wants it simply for the sake of choice.
Some of us have been using Un*x-like operating systems for many years. We have built entire computing lives out of shell scripts--ways to manage our budgets, ways to manage our contacts... and we have also spent a great deal of time tweaking desktop configurations (which have traditionally been very flexible in open-source GUIs) with focus behaviors and window behaviors that make our computer work more efficient.
It may seem only like a small option here or there is removed when GUIs are "simplified" but if that was the option that *you* depended on, and if removing it makes your computing 50% *less* productive on average, you're going to be upset about it.
I get tired of people assuming that I use feature 'X' in Linux just because I want to be different. The reason feature 'X' exists in the first place is because somebody thought it was needed. When you remove that feature once again, that person has lost a feature in Linux that he or she *needs*. This is not likely to make him or her happy.
I can understand the thought that to lose that one user in order to gain another ten is a good tradeoff in terms of Linux market share, but you certainly can't expect that particular person to be happy that the latest version of his or her favorite operating system has basically left him or her out in the cold.
STOP . AMERICA . NOW
However, almost 95% of what Glib does is already handled by Qt (and in some places, in a more natural manner, such as QObject vs. GObject)
Huh. I haven't even seen GObject -- I've only used glib 1, not glib 2. I guess I should see what's up. Some of the things are the same. I'm pretty sure that both have some sort of API for creating timers, for example.
Qt provides the same easy ways to use C strings as glib does.
No, I don't think it's quite as nice -- if you'll take a look at some of my other posts in this thread, you'll see me talkign about them.
GNOME would probably never want to depend on Qt (it's GPL'd, not LGPL'd)
I always wondered about that. How do the KDE and TrollTech people get along when it comes to licenses? kdelibs is LGPL and is definitely dynamically linked to qt, which is GPL.
depending qt on gnome would do the same thing.
I think that would be worse. Glib is a very small, basic set of utility code that gdk/gtk use. You'd have to combine all three of them to have something equivalent to Qt, so GNOME depending on Qt would be a much larger set of dependencies. KDE can comfortably use lots of glib code without having to adopt a new object model, but GNOME doing the same with Qt would not hold true. Plus you'd be introducing a C++ requirement into GNOME, plus there's the license issue, yadda, yadda, yadda.
May we never see th