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."

Comments

Re:Sigh..

[myLobster]

The article does not even suggest a flamewar - quite the opposite really.

Interoperability is king

[nitehorse]

There's a relatively large thread going on in the kde-core-devel mailinglist about such interoperability efforts that you guys might be interested in, too... check out this thread for the whole story.

The short version is - arts, the KDE sound daemon, uses glib code internally, but the maintainer wanted to move the glib code to rely on an externally-installed glib (instead of maintaining a copy of glib in the arts distribution). Lots of developer confusion over this has ensued, but a lot of interesting discussion has also resulted. Check it out.

Re:Interoperability is king

[IamTheRealMike]

There's a similar thread on the GNOME desktop-devel-list, basically a debate about DBUS vs CORBA turned into some KDE users (developers? maybe) having a go at GObject yet again.

The main sticking point seems to be GObject, but I've yet to find a KDEer elucidate what is so bad about it, especially considering it was designed with language bindings in mind.

Re:Interoperability is king

[nitehorse]

I think that a lot of the problem with GObject is (in most KDE developers' minds) is that we feel it's a hack for C to help make OO programming available, where OO is much more readily available in other languages.

The OO paradigm wasn't around when C was designed, and C certainly is an awkward language to use OO in.

It's the difference between saying:

QPushButton *button = new QPushButton("Hello, world!");

and:

GtkButton *button = gtk_button_new_with_label("Hello, World!");

In one case, you have clearly defined language-level constructs and rules about what happens when you use said constructs; using the 'new' keyword on any object means that the language will automatically call the constructor for the object in question.

So instead of having to write a x_button_new_with_specific_property function, you define a class with the properties, and the proper constructors (because C++ has rules about how constructors get called, instead of forcing the programmer to remember a name mapping for every _new function with every possible permutation of the _with_property names at the end).

I support GObject personally insofar as it is used for the language bindings, because programming GTK in ruby or python should be easy and fun and take full advantage of the OO properties of those languages; but for use in C? Thanks, but no thanks.

Re:Interoperability is king

[Sam Gibson]

Actually Small Talk was around before C and it's based on the OO paradigm.

Re:Interoperability is king

[nitehorse]

Ah, but having documentation for the APIs makes all the difference.

Self-documenting function names might be neat, but that's a nasty kludge for not having a well-designed API, IMHO. The Qt API docs are the best I've ever seen from ANY project, bar none. So you know exactly which constructors exist for QPushButton, what types they take, etc - there's no question about it, and you don't have to do any weird casting in order to get it to work right (which is necessary in C a lot of the time).

I've never used Eiffel, so I won't comment on that, but I really like the way that C++ constructors work; in any case, I agree that it's mostly a matter of syntax and semantics, but I think that the C++ way of doing it (having a 'new' keyword, class constructors, etc) is better and cleaner. Again, this is all very subjective, so you're free to disagree, but for new programmers... well, it depends on what language they learn first. :)

Keep in mind that KDE also has bindings for Python, Ruby, Java, Perl, and (Qt so far) even C#. We're not exactly lagging behind in the bindings race. Unless you consider Scheme and OCaml bindings to be important, of course... but then, I've heard that GNOME's bindings for these languages have lagged behind and not been updated as consistently as their more popular ones. YMMV.

Re:Sigh..

[larien]

I think the point is that it's a "user" flamewar rather than a "developer" flamewar. You're right in that Gnome/KDE get on fairly well (well, they do now; I think there was some antagonism early on), but users get very angry in the same way we have perl/python/ruby wars, emacs/vi, debian/redhat/suse/mandrake/slackware/whatever wars....

Re:Usability and Fonts

[samhalliday]

what are you talking about flame-bait?

nobody thinks Xfree86 (its not just gnu/linux you know!) is archane becuase it uses anti-aliased fonts... if anything, people would think it arcane if it did NOT support anti-aliasing.

granted this support has come a lot after windows has supported it, and some GUI libraries still need to catch up (nto an issue for gtk+2 or qt3) but for older machines, bitmapped fonts look much prettier than rendered ttf's.

just what is your point?

the main reason people walk by gnu/linux is that they dont know what it is, or if they do, they have so many windows apps they would rather not lose them ... or they see it as a geek's OS requiring geeks command line skills (true geeks use FreeBSD by the way). I have never in my life heard of anyone walk by a Linux system and immediately think it's arcane becuase it uses anti-aliased fonts.

Re:Unification can only help

[gilesjuk]

I don't think you can standardise on any desktop, that would be unfair for those people developing other systems.

Yes it would be nice to ditch the KDE/Gnome names and just call the desktop simply "Linux Desktop", but Linux isn't the desktop, it's the kernel.

KDE and Gnome are available for other systems, Sun recently changed their default desktop for Solaris to Gnome 2. Sometimes you have to remind yourself sometimes that their is life outside of Linux :)

Re:Useability Engineer?

[JimDabell]

What's your problem with usability engineers? Usability is a big deal, and it involves a lot of work that differs from normal development quite a bit. Usability enhancements can increase sales and employee efficiency by a hell of a lot.

How about learning a little about the field before dismissing it as a silly title for a developer?

Re:Useability Engineer?

[bigfleet]

Usability Engineer is actually quite an interesting position, IMHO. It focuses not so much on the raw, technical nuts-and-bolts, but on how people work with machines. You'll often find jobs (in the real world, I suppose) like this going to people who've graduated in Human Computer Interaction at places like CMU or Stanford.

My own opinion is that it's a very important field. I think everyone knows we're not going to win Grandma back from Microsoft with the current state of Linux on the Desktop, even if it is getting better. Apple isn't going to win, because it's-- what, 3x as expensive? Even if I love them!

So it's up to the Open Source movement to generate something that doesn't provide what coders THINK the users would like to work with, but something that they can demonstrably interact with well, and understand enough to use.

A further opinion is that all we need is a little more handholding... It's not a bad thing! Don't you want Microsoft to start losing?

the fundamentals are key-"pinhole" logic.

[Anonymous Coward]

"Whether we like it or not, the Microsoft Windows 2k & XP interface is the gold standard for how applications are integrated into the desktop."

Apple would disagree with you, but then everyone sees the solution they know as the correct one.

Re:Common object model

[damiam]

I've yet to see a Bonobo part implemented in C++, let alone any scripting language

Gecko and AbiWord are both written in C++, and both are available as Bonobo components.