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."
If both parties can indeed merge to form a unified desktop environment, this could have a HUGE impact in the acceptance of Linux on the desktop. My biggest prob with Linux is trying to decide which GUI to standardize on. I feel a slight tremor in Seattle.
In general I found myself agreeing with Aaron
's comments more than the others. The main problem I see with Havoc and Waldo and all the others pushing for more shared technologies across the desktop is the implementation technology. KDE is built from the ground up upon Qt/C++ and this is one of the major reasons for it's considerable success. I see no reason to change this winning strategy.
Recently, we've been discussing the incorporation of Glib into KDE on the core development list. While I am not against this per se, I wonder whether the GNOME developers will ever allow the use of Qt/C++ in any shared technology. It seems to this day that Qt licensing is still a problem for GNOME. One of the greatest ironies in all of Free Software, IMHO.
If Havoc and Waldo are serious about integration then this problem will have to be addressed in earnest. I do not want to see KDE come down a level in technology just so that GNOME apps can integrate into KDE. Better to improve the great applications we currently have in KDE then waste so much time focusing on some elusive merging of these two.
Besides, choice is good and GNOME with KDE offer this. Where we can agree upon specs and closing superficial differences we should and that will help those who choose to use GNOME apps in KDE and vice versa. But please, let's not rearchitect KDE and strip it of Qt.
a unified look and feel to both Gnome and KDE will be great. I would even go further to suggest that someone should write a book in the lines of the M$ book of standards (its a book full of "thats how a window should look like" and "thats how a button should look like" etc.) for the linux environment.
I know this is sort of a blasphemy, after all - linux is about tweaking, but nevertheless its quite irritating to use middle mouse to paste in one program, ctrl-v in the other and shift-insert in the third , without any way of deciding or even a way to know in advance.
just my 2 cents...
Heh. This is one of the more amusing criticisms of KDE to me. The name of the app is just marketing man. It can be changed by distros or hidden in the menus or whatever. While the K* naming scheme might not be so pretty it helps to show which apps are integrated into KDE.
...REASON joins the open source movement!!!
Choice is good, when limited. When allowed to run free, its actually a prison unto itself.
Too many GUI's, desktop environments, xfree86 shells, WHATEVER you wanna call them (see there's even too much choice on naming the damn things) and userbases get splintered along with their apps making Linux HARDER not EASIER to use.
A united GUI is the best chance Linux has for a respectable marketshare on the desktop.
And for all you "But you will RUIN my LEENUCKS if you make it easy to use, I like being counter-culture and unique!!!!!" and "Dammit. Choice is sacrosanct! I don't care if NO ONE can figure out how to use Linux, if it doesn't have 500,000 different ways of doing the same thing then it isn't worth installing! Can't you see? Linux is ALL about WASTEFUL and POINTLESS duplication of effort! Why go foward when you can spend eternity going nowhere!!?!?!" people relax. I am sure someone will create a new Linux distro, the "Ub3r L33t Linux Extra-Special Hard To Use" distro with a built in AI that will monitor your usage over time and re-arrainge various commands randomly to keep you on your toes and make sure Linux never becomes "too easy" for you. Legions of filthy unwashed nerds and geeks, dissilusioned by the increasingly easier to use mainstream distros will flock to this new permanently hard to use distro. They will form communities to provide each other with moral support. Real Estate firms will notice a skyrocketing in their sales and rentals of basement unit apartments/condos as the geeks settle in for a lifelong pursuit of sunlight shunning and the disdainment of anything easy or social. Although these geeks and nerds will think their intelligence is par none, they will miss all other technological advances and fall further and further behind the rest of society. When their savings finally runs out and they apply for computer jobs interviewers will be amazed that you've all spent the past 5 years using what will appear to the rest of the world as "DOS Linux". Laughed out of the interview the poor geeks will have to settle for flipping burgers at the local fast food restaurant for a short time until they are replaced by burger flipping robots. Finally realizing their worthlessness to society in general they will join an EverQuest cult where they will all live in massive communes cut off from the rest of the world and live peacefully until someone forgets to pay the EverQuest bill and they all jump off a bridge from mass depression.
Mac OS X and Windows XP working side by side to fight back the night.
Well, this isn't about moving everything to use glib instead of the Qt-based equivalent data types at all (which is what several of the developers on kde-core-devel seemed to think) but simply about moving the copy of glib out of arts and into kdesupport. This way, we only have to keep kdesupport in sync with the latest glib stuff, and arts itself doesn't require updates when glib bugfixes are implemented.
This is just my take on it, though - I may be misinformed or just plain wrong, but that's how I understand it. As I said, this has nothing to do with porting KDE to glib or anything like that, merely making the dependency tree slightly more sane and cleaning up arts a bit.
When I look at areas where both Gnome and KDE can both improve, I see the basics. Things like printing. Things like sound setup. CDRW... DVD... improved .jpg and .tiff and other image management & manipulation.
I know the immediate, knee-jerk response is going to be that there are great programs out there which handle all of the things I listed above. The problem is they aren't as integrated into either Gnome or KDE as they SHOULD be. Whether we like it or not, the Microsoft Windows 2k & XP interface is the gold standard for how applications are integrated into the desktop.
What we should be thinking of is how we simplify the integration of applications into both KDE and Gnome desktops.
The surest sign of intelligent life in the universe is that none of it has tried to contact us. -- Calvin & Hobbes
9. Despite the advancements of RPM handling, apt-get from Debian and Gentoo's Portage, users are still not comfortable downloading applications and easily installing them. Either dependancy hell (RPM) when downloading apps from the web, bad interfaces for apt-get (Synaptic is not what I would call "niiice") while Gentoo itself is a nightmare to install for new users, makes the installation of... random Linux applications pretty impossible for new users.
And how is that a bad thing? No more shareware syndrome. Panic installing of random software is a sure fire way to hose your system. Experts know this, lusers don't.
Joe-sixpack windows (and mac) users are very prone to the shareware syndrome, _because_ it's do frigging easy to install random software. Although the uninstallation step on the newest Mac OS is a breeze (drag app into the garbage), under windows, the uninstallation can leave a lot of cruft behind.
Oh well, I'm just ranting. It's just something that caught my eye and couldn't help noticing.
Believe it or not, these three "experts" have never seriously touched XP.
As a UI designer, you should learn from all good/bad aspects of other UIs. Simply rejecting idea from Microsoft is never the wisest approach.
I don't mean Microsoft is any better, but it is foolish to act blind.
I dont want to troll or take the GNOME side, but I think here is a general problem of KDE:
All it's libraries are very tightly integrated, this leads to something like a monolithic block.
Just think of a console program using container classes from qt - it has to be linked to the libqt, containing all the qt stuff (GUI etc.). Because the ld.so doesn't load the whole stuff, this doesn't mean that this is harmless. C++ container classes just don't have anything to do with GUI classes.
In other areas, this scheme is true as well. I think GNOME could learn much from KDE about a unified interface but KDE could learn the "build it from small, *independent* components" from GNOME.
There are many interesting libraries originally developed for the GNOME project but usable in other contexts, but I can't think of any library in KDE that makes sense alone.
Well, in fact you can query them, but in general if you're poking objects from the command line this is more a case of scripting IPC than objects.
If the media player exposed a CORBA/Bonobo object (i believe rhythmbox does), and if there was a bash "poke me" CORBA client (i don't think there is), then there'd be nothing really stopping you. But CORBA isn't so hot for DCOP style simple scripting - the recent threads on desktop-devel-list contain more about that.
By distributed, I don't necessarily mean distributed between different physical computers. If you look at DCOM on Windows, it's most often used to marshal calls between different processes or threading contexts. It's rarely, if ever, used for network transparency. But as the technologies are practically identical.....
Most stuff in GNOME is C, because C is easy and that's what the developers know and like (just like, why is the media play in KDE in c++, when really that kind of thing is better off in python imo).
There aren't any Bonobo objects defined in Python (although there are some used) as far as I'm aware, simply because the GNOME CORBA efforts are seriously starved of manpower. It's a technology with much potential, after all, look at DCOM/ActiveX on Windows, which is very similar in ideas, but little usage. Partly that's due to it being complex, and due to lack of good working documentation. I only "got" CORBA after reading an (old) Bonobo/Python tutorial. I realised how easy it was to load and use objects, without having to care what they were written in. It was COM, but for Linux, and better! Unfortunately, the hill it has to climb for general acceptance is too steep. Eventually I'll let go, and realise that politically we probably have to start again with a neutral solution. We'd end up reimplementing CORBA under a different name, and it wouldn't be standards-based, but maybe it'd be better as well.
I'd note that a bigger problem is lack of good dependancy management. I'm firmly of the opinion that most desktop apps should be written in Python/Ruby/C# - not C++ nor C. The main problem is that for instance, Straw, an RSS reader using the GNOME/GTK python bindings, has a list of dependancies that is positively scary. The GNOME parts aren't so bad, but it needs bindings for all kinds of wierd database libraries and so on that have to be built separately. So, many people don't use it, cos they can't install it. That's one thing I'm trying to work on. Objects would have the same problem.
Partly that's because KDE is C++ only. I think these C vs C++ arguments are pretty silly, neither of them are all that great for desktop apps, even games! Try frozen-bubble. It's written in Perl/SDL. Easy peasy.
Much longer, but it's apples and oranges. You can use CORBA to do DCOP style scripting, and also distributed (ie process/network-transparent) objects. You can't really use DCOP for such objects, not without huge, enormous pain. The whole DBUS vs CORBA thread in gnome is about that distinction.
1. Gnome should never have started because it took developers away from KDE.
2. Competition from Gnome has pushed KDE to strive for better
Which is true? *shrug* just playing Devil's advocate, again.
Each has a clear design quality that the other could use.
- KDE: Elegant API
- GNOME: Good component model
Each has a design flaw that still needs to be overcome.So, when it comes to flamewars, why is it always the KDE guys who do most of the bitching? Why are there so many articles about why GNOME sucks? Why do KDE guys tend to shout? ;-) Why do the KDE guys seem like Bolsheviks, and the GNOME guys seem like Mensheviks?
My poor theory, which is almost certainly off the mark, is that since GNOME has garnered some corporate attention, there is no longer a single face (besides Miguel de Icaza) on the project; it has become very much an amorphous enterprise. The KDE project, having been spared this attention, still has an individual character, and still takes things very personally.
--I only got one serious beef with the various distros I've tried. I want ALL the apps installed on the machine to show up in the GUI menu system. I don't care if it's a little dragon or a little fat guys foot, when I click on that thing down in the corner I want the menu to be complete. I got stuff on here I don't even know what I got. No idea where it even is. That was my first impression of Linux, I KNEW I had a lot more apps then what showed up.
The only other useability beef is dialout, I had dismal luck at first getting a normal over the old fashioned telephone wires internet connection, MAN that was annoying. I have yet to get kppp on mandrake to work,but I did get redhats dialer and front end to work in the 7 series, and not even gonna attempt to do it with "tweaking files" ever, ME tweaking files is an invitation to mass FUBAR, this is just *so true* it ain't funny. I love that that option is there, sometimes I fool with it, but NOT with my inet connection, that's the primary reason I own a computer.
Besides that, it's a pretty nifty system, if the developers can integrate, more power to them! I'd love to see it. The concepts for GUI are fairly easy, you have to be able to look at what's there, and it should make sense and do what it's told. If it can't, then it won't get used or people will get frustrated. GUI it appears can be made more complex, but then you have to ask "why do that?"
The language doesn't specify what kind of memory it is. It might be allocated directly in a file using mmap, it might be doing fancy stuff with memory maps to do all kinds of weird and wonderful things whenever you write to it (or not allow you to write to it at all), or a zillion other things only limited by the fantasies of some of the most imaginative people around :) Remember, you can provide your own new handler.
As for the state of the object, you have no idea without knowing what the QPushButton() constructor does. It could be left completely uninitialized because initialization is costly and it's left to the user to call an init() method, the user may be expected to set various properties, or everything might just have been zero'ed out.
In other words: You are relying on convention to say what operator new does, and on your assumptions about what a class with the name QPushButton() should do, or specific knowledge about this particular class to tell you what you expect the constructor to do.
Which is, suprise, surprise, the exact same starting point you have with a function called gtk_button_new_with_label(), except that in my opinion the latter name give you a better clue to what the argument is. In the first case it is not clear without going to documentation whether the argument to the constructor is the text on the button, keyboard accelerators, and internal id used in callbacks (why am I supposed to assume that QPushButton has a text label?), or something else entirely.
And your comment about having to write a x_button_new_with_specific_property function is also more about syntax than semantics - a constructor is a function too, the only difference between the two is that in the first case you have explicit control over how memory is allocated, whereas in the latter to you take what's coming. The first case allows a lot of flexibility to the class implementor that isn't available when using the operator new syntax in C++, hence patterns related to object construction often require the user to use a different syntax even when the user has no need to know.
As for the number of _new functions with permutations of _with_, you have the exact same problem with C++ constructors: You need to remember the syntax (the order and type of the arguments) of the constructors. With GTK's naming scheme on the other hand, you're a hell of a lot less likely to call the wrong constructor because you remember wrong, pushing more errors from runtime to compile time, which in my book is good.
If you need more than 2-3 constructors tops, you should be looking at way to more clearly syntactically differentiate them even if you use C++. Eiffel for instance allow differently named constructors for the same class, and that might have been useful for C++ too. Another alternative is of course to use static class member functions, but then we're back to the different syntax for object construction issue that I mentioned above.
I like C++, and personally don't do much GTK programming, but from your message it is not at all clear to me that you've demonstrated any superiority in C++ object oriented programming with your message (I'm not saying there aren't any, just that you'll have to try harder :-) except for "it looks prettier" and that you think C++ guarantee you more than it does.
I think the problem with the RedHat 8.0 implementation of KDE is that it actually breaks KDE and makes it incompatible with standard KDE.
I remember reading an interview with the guy who runs The Kompany and he basically said that with RedHat 8 you are effectively supporting a thrid platform (KDE, GNOME and then RedHat 8). I believe it's something along the lines of RedHat had to make significant changes to some key KDE stuff to get not just the look of the apps to be the same, but to get them to behave as if they were written under the same toolkit.
Which is probably (amongst other reasons) why you can't download RedHat RPMS from www.kde.org.
The Romans didn't find algebra very challenging, because X was always 10
If that's true, then PLEASE, point me to a single Bonobo object implemented in Python.
:)
Or Ruby.
Or Java.
Or SmallTalk. Or OCaml, LISP, Scheme, or Perl. Any one of them.
Where are they? Where is the "Implementing a Bonobo object in Python" tutorial? Where's the documentation? Where are the examples, the real-life apps using them?
That's my point. They don't exist, so pointing at KDE/KParts and saying "You have to use C++ for KParts!" is silly, because you have to use C for Bonobo (to implement, anyway. Unless I'm wrong - which, if I am, please do tell me.
Bzzzzt.
5 /smalltalk1.html
"The very first Smalltalk system was a thousand lines Basic program, which successfully computed 3+4 in October 1972."
From http://www.cosc.canterbury.ac.nz/~wolfgang/cosc20
'jfb
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.