KDE & Gnome Usability Engineers Interviewed 382
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."
Sigh.. (Score:5, Insightful)
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.
Re:Sigh.. (Score:3, Informative)
The article does not even suggest a flamewar - quite the opposite really.
Re:Sigh.. (Score:2)
Re:Sigh.. (Score:5, Informative)
Re:Sigh.. (Score:5, Funny)
Re:Sigh.. (Score:3, Funny)
but users get very angry in the same way we have perl/python/ruby wars, emacs/vi, debian/redhat/suse/mandrake/slackware/whatever wars....
The article said something about Havoc frome RedHat. Now if RedHat would stop spreading Havoc, maybe we would be better off
Re:Sigh.. (Score:3, Interesting)
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.
As long as the result isn't Knome... (Score:4, Funny)
Kjella
Re:As long as the result isn't Knome... (Score:5, Insightful)
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.
Re:As long as the result isn't Knome... (Score:2)
Re:As long as the result isn't Knome... (Score:2)
But that's just him. It's the tie he wears I guess.
I like app names that actually have to do something with their function, i.e. Rosetta instead of KBabel, or Meccano (you know, the construction kits made from metal strips, screws, gears and bolts you could construct stuff like cranes with etc) instead of boring Kdevelop. You catch my drift.
Simply a sed -e s/c/k/ on a name does not a good appname make. *sigh*
Re:As long as the result isn't Knome... (Score:2)
Rosetta plays on the rosetta stone while KBabel plays on the babelfish from H2G2
Can't see how oe is better than the other ?
Re:As long as the result isn't Knome... (Score:2)
Re:As long as the result isn't Knome... (Score:2)
Meccano doesn't make me think of a compiler. It makes me think of construction sets, but the only construction set I remember from my youth is the Erector Set, the American equivalent which Meccano now owns (the web is wonderful for looking this stuff up). So Meccano is only instantly recognizable if you grew up in Europe or Canada. Even then, I expect something called Meccano or Erector Set to have something to do with creating engines or building something, not creating computer software.
I'd suggest something like "KDE C++" to show it is a c++ development platform. Or maybe "KDE Developer" or Koder if you want to get cutsey again, or just KDE Coder.
Rosetta involves an awful lot of knowledge on the average end user. Most people don't know what the Rosetta Stone was or why it was so important. And even if they do, they may not make the leap that something called Rosetta will translate documents for them.
KBabel isn't any better. KBabel involves the user know either a)the babelfish website, b)the babelfish in Hitchikers, or c)the Biblical Babel that was the source for the other two. For the average computer user, not average slashdot reader note, a and b are out the window. And c may have entirely the wrong connotation: run this program and you'll never be able to understand what the computer says. Your manager is right; a good name would be something like "KDE Translator". Because the average person knows what a translator is.
Re:As long as the result isn't Knome... (Score:3, Funny)
You know, I've spoken to people who think it iWorks.
Re:As long as the result isn't Knome... (Score:2)
I hope KDE drops that whole K-naming gimmick. Although I love KDE, and I use it every day, it's the one thing that I find downright irritating.
You mean kirritating , of course. :)
Re:As long as the result isn't Knome... (Score:2)
Surely you mean Kirritating right? :o)
Re:As long as the result isn't Knome... (Score:5, Funny)
Disclaimer: it's still beta and very buggy, but in case of necessity
ill -9 kremoveinitial
should solve any problem
Re:As long as the result isn't Knome... (Score:2)
Aaargh! Damn you, making me laugh out loud while I furtively try to read slashdot in the office!
Mods: +5 KFunny.
Re:As long as the result isn't Knome... (Score:3, Funny)
So, I plea to everyone that develops new GNU apps, _DON'T_ use that silly G-ism shtick. It was fun the first two versions. It's getting old. Be original for a change, okay? Thanks.
gcc, gdb, gimp, glibc, gnats, gnome, gnotepad, grub, gnumeric, gnupg, gnustep, gphoto, grep, groff, gtk, guile, gzip, getc, getc, getc.
Re:As long as the result isn't Knome... (Score:2)
Marketing shmarketing. Yes, you have a point that KDE "friendly names" are probably the only thing a user sees, but THEY follow that silly K-naming abhorration too! Aargh!
In short, the K naming scheme must die. Maybe the KDE project needs something like RFC 2100 [faqs.org] but then regarding application names.
Re:As long as the result isn't Knome... (Score:3, Insightful)
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.
Good news! (Score:5, Insightful)
Re:Good news! (Score:2)
Interoperability is king (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:5, Informative)
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:and: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 (Score:3, Interesting)
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.
Re:Interoperability is king (Score:3, Informative)
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:Interoperability is king (Score:4, Interesting)
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.
Re:Interoperability is king (Score:3, Interesting)
"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
Re:Interoperability is king (Score:3)
The main issue isn't what's best to develop in, it's how hard it is to share code. If I write an object using GObject, it's fairly trivial to use it from C or C++ (or many other languages). Now, you can bind C++ to C as well, but it's not as easy, nowhere near. The need to manually bind objects is just a total pain in the ass, and something Windows slapped down with COM years ago. CORBA could have been it, but has a bad rap for various reasons.
So the real question now is not, what is it better to develop apps in, but, how can I share my code with everyone, while using my preferred programming paradigm.
glib is a lovely library (Score:3, Insightful)
Re:glib is a lovely library (Score:3, Interesting)
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.
Re:glib is a lovely library (Score:2)
I know (manyoso seems to also be confused here), but if it's external, then it's more widely available if I want to use an app that uses it. glib feels kind of like "stuff that should have been in the standard library but shouldn't", and tends to help programmers avoid stupid string mistakes. I really like having it available (I've used it on plenty of non-gtk stuff).
Re:glib is a lovely library (Score:2)
This is different from another proposal being floated by Havoc and a few others where GNOME and KDE would share much more tech. Again, no problem, but to me the exclusion of Qt/C++ from this shared tech is a non starter.
Re:Interoperability is king (Score:2, Interesting)
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.
Usability and Fonts (Score:5, Insightful)
Re:Usability and Fonts (Score:3, Informative)
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:Usability and Fonts (Score:2)
http://www.kde-look.org/
Ooo look at all the ugly desktops.
Unification can only help (Score:2, Interesting)
Re:Unification can only help (Score:2)
Re:Unification can only help (Score:2)
For apps, well, you can run gnome programs in KDE and viceversa, but a bit more of interoperability will help to have all more integrated (like common clipboard and things like that)
Re:Unification can only help (Score:3, Informative)
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:Unification can only help (Score:2)
I'd like to see a convergence where you have 'Linux Desktop' and you have a nice little area where you can pick the menu-style, window-style, theme-style, widget-style. Maybe in the background it runs KDE or Gnome, whatever, I want my choices I just want them seemlessly integrated into an overall system. And I want to stop having 3 different looks and feels to my apps.
Unnecessary (Score:5, Insightful)
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?
Integration across the desktop (Score:5, Interesting)
'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.
Re:Integration across the desktop (Score:3, Flamebait)
The real problem that needs to be addressed in earnest is the idea that C++ and KDE are fundamentall superior to GObject C/GNOME. While certain KDE developers persist in having a "KDE is perfect, GNOME is teh suck" attitude, the biggest barrier to integration is attitude, not technology.
Re:Integration across the desktop (Score:4, Interesting)
BTW, I don't take the 'KDE is perfect, GNOME sucks' attitude. I prefer KDE, but this choice does not in and of itself disparage GNOME. Plenty of opportunities for improvement on both sides.
Yeah? And? (Score:2)
Using it wouldn't cause Qt to be "replaced" in any way. It just helps Qt programmers whenever they're using something (SDL, OSS, the Unix system calls) that uses C strings. Glib is really nice -- stuff that (IMHO) probably should have been part of the standard library.
Re:Yeah? And? (Score:2)
Rich.
Re:Yeah? And? (Score:3, Insightful)
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.
Re:Integration across the desktop (Score:2)
I'd note that while KDE may be more integrated, your average KDE desktop is not, as I'd guess most desktop users use apps like OpenOffice, XMMS, Mozilla, Wine and so on, none of which are part of KDE nor GNOME.
I think that's a pretty fundamental thing. The idea that everything will be alright if there are enough KDE apps, if nobody uses C anymore, is just flawed. On Windows you have COM, and that means apps can be written in the right language for the job - Delphi for databases and generic desktop apps, VB for prototypes, JavaScript on IE for web apps, Visual C++ for, well, other stuff :)
Linux has no equivalent to COM. Until it does, arguments about whether C++ is better than C is sort of pointless, I'd rather use Object Pascal to write my APIs in, but that's not an option today :(
The reasons GNOME uses C are well documented, and it's not because it's easier to do objects in C.
Re:Integration across the desktop (Score:2)
I don't know on any 'average KDE desktop'. The only thing I know is that my KDE desktop is very integrated. The apps that we have now will only improve and I currently do not lack for any feature. BTW, you can use different languages to develop KDE applications right now. We support Perl, Python, Java and C# and others so this is not really a useful argument. Besides, the difficulty of writing all this shared infrastructure and rearchitect KDE is enormous compared with the difficulty of binding the current architecture to other languages. It is not really that much more difficult than binding to C.
Re:Integration across the desktop (Score:4, Insightful)
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.
Re:Integration across the desktop (Score:3, Interesting)
The idea behind .NET is similar - code sharing between languages. The lack of pretty much any automatic-binding (like corba or com) object model at all, means GObject is the best we've got.
So, if people prefer Qt/C++ then that's cool, GObject lets you use that. I don't know C++, and I don't want to learn it unless I have to, so I can use C, or Python, or Perl, or C# etc etc
Re:Integration across the desktop (Score:2)
Re:Integration across the desktop (Score:2)
IIRC, it was officially over and done with when Qt went GPL, but it may have even happened when they adopted the QPL - my memory of the licensing issue is fuzzy, since it's never really mattered too much to me.
Harmony is dead (Score:2)
Re:Integration across the desktop (Score:2)
Recently, we've been discussing the incorporation of Glib into KDE on the core development list.
Have you used glib? It's a really, really good library, but it's also very lightweight. It's a tremendously useful utility library. It would add very little by way of dependencies to either project -- it's nothing like requiring libgdk or libgtk or any of the gnome libraries. Using Qt or C++ in GNOME would significantly increase gnome's requirements.
But please, let's not rearchitect KDE and strip it of Qt.
Actually, I'd really like to see that.
Re:Integration across the desktop (Score:2)
Yah, I have no real problem with glib. But, I do object to using a bunch of shared technologies between GNOME and KDE when all the shared technologies are devoid of Qt/C++. It is just to radical to say that KDE should now start over and start using all C based infrastructure just so that KDE and GNOME can share stuff. KDE is already mature and has a good strategy. No compelling reason exists to remove Qt from KDE. Just the thought of it makes me shudder.
Re:Integration across the desktop (Score:2)
I fail to see the irony. Open source software licenses are designed to achieve specific goals, and it seems like the Gnome/Gtk+ license is achieving its goal.
KDE is built from the ground up upon Qt/C++ and this is one of the major reasons for it's considerable success.
IBM, Microsoft, Apple, and Sun all are moving away from C/C++ for their GUI efforts. What is KDE's response going to be? Claiming that everybody else is wrong?
Re:Integration across the desktop (Score:2, Troll)
GNOME was started because Qt was not free. Now, Qt is free, but GNOME developers are concerned for the proprietary developors who might wish to create third party apps.
The irony presented in all it's glory:
"For example, they may appeal to the ego, promising "more users for this library" if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all."
(http://www.fsf.org/licenses/why-not-lgpl.html)
Re:Integration across the desktop (Score:2, Insightful)
"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.
Useability Engineer? (Score:5, Funny)
Is this type of deal limited only to the Tech Sector, or is everybody throwing about hyphens and "Engineer" to make people sound more important?
Other good tack-on words I can think of would be associate (no, that's not the Fry Cook, that's our Comestibles Associate), analyst (hey, I'm not a waitress, I'm an Order Analyst), and vice president (no, I'm not the bus boy, I'm the VP of Table Maintenence).
-theGreater Cynic.
Re:Useability Engineer? (Score:2, Informative)
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? (Score:2, Informative)
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?
one API. one look. (Score:5, Interesting)
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...
Re:one API. one look. (Score:2, Interesting)
The rub was that everything was Free except Motif, which was commercial, and threw a wrench in the whole "standard" Unix desktop. I guess it was pretty much the superior piece of kit at the time.
The desktop projects need to work together towards the same goal if a Free desktop is to go anywhere. The code, the API, all the behind the scenes stuff needs to work in a common way. There needs to be a common clipboard and a standard for the way a window works.
There's then still a ton of room for 'tweaking'. Most people's 'tweaking' consists of changing some event sounds and putting on a wacky fractal wallpaper anyways.
Re:one API. one look. (Score:3, Insightful)
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.
Unify ? Who wants that ? (Score:2, Insightful)
I think that K and G do things their own way, but when G and K do the same thing (eg icons, desktop files,
Keep Dangerous options away, please! (Score:5, Insightful)
Re:Keep Dangerous options away, please! (Score:4, Insightful)
If that's the case, I think we should take KDE's Control Center, name it to Control Panel, move it under Applications->Accessories->System Functions. The in the next minor release, let's move it under Applications->System->Options and call it System Control. Then in the next minor release, we need to call it "KDE System Control" and move it to Applications->Utilities->System->Options.
The point is, taking a lesson from Network Neighborhood, moving things from one place to another is a PITA. That's one of the good things about KDE & Gnome. When they change something that big it's not hard to find it, the name rarely changes. So yes, MS should take a lesson from us.
Options like the one you mentioned are there for those who prefer it, but need to be well hidden under an "Advanced Dialog". Why? Because there are people who expect things to work in certain ways that we consider "stupid" or "difficult" or "dangerous" when in fact it is quite the opposite for that person. Yes, I prefer more and more configuration options, and yes, I believe they need to be well, well, well hidden. Perhaps an overall option in the control center where you can set configurability from "Basic", "Advanced", "Expert", "Don't Blame Us"
Just my 2c
I am sick of this... (Score:2, Flamebait)
Instead of getting usability "experts" together to moderate a supposed flamewar and make KDE and GNOME clones of each other and ultimately every other OS in existence, why don't they get these so called experts to suggest how these interfaces can be enhanced, in their own way, and *gasp* even contribute a few patches to the cause. Yeah, OSS has some pretty wretched interfaces but there is a great deal of innovation occuring as well and if someone with true experience in the realm of GUIs could harness and direct some of this innovation some amazing things could probably occur. The Mickeysoft way of doing things is not working for anyone over a 65 IQ and Apple is to artsy for many folks so there is a clear market to serve hear. I can even imagine many would think that KDE and GNOME *are* serving that market and with a little more time may really have some polished interfaces. Things *have* gotten better and they will continue to as time moves on. Development is an iterative process.
</rant>
Finally at long last..... (Score:5, Interesting)
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.
Re:Finally at long last..... (Score:3, Insightful)
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.
Common object model (Score:4, Insightful)
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".
Re:Common object model (Score:3, Insightful)
Let me tell you what. Maybe it's not endemic of every CORBA implementation (hell, maybe even ORBit is unaffected by this) but MICO in particular is slow. When I say SLOW, I mean:
Before the actual KDE 2 release, before DCOP and KParts were ever invented, KDE used to use MICO for its CORBA implementation. We had cool technology called KOM/OpenParts, which was completely 100% based on CORBA. And it was slower than hell.
It took hours to compile KDE from CVS back then - kdelibs + kdebase was a 6-hour job on a top-of-the-line machine. It took minutes for Konqueror to start, and it was buggy as all hell, even after six months of bugfixing (including, iirc, a few patches being sent to the MICO guys to fix bugs in MICO as well).
Finally, after all of the problems with MICO had been enumerated, a couple of our developers claimed that they could come up with something better in a weekend. Were they being arrogant? Sure. Were they cocky? Absolutely. But were they right? Surprisingly, yes. (Actually, I seem to remember the initial DCOP implementation taking 4 days, but that's really just a long weekend.
As soon as DCOP and KParts were released, development on the 2.0 branch ramped up exponentially. We released 2.0 within months, as opposed to still being years away due to the incredible slowness and bugginess and complexity inherent in using CORBA for desktop communcation.
And the technology introduced back then is still going strong today. KDE 3.1 still has the same DCOP command-line tool, the DCOP API is still the same, and almost all of the programs' DCOP interfaces haven't changed. I doubt that any single one of these would be true had we stayed with CORBA.
(Sorry for the rant, but you have NO IDEA how much CORBA sucked for us, and I am 100% sure that it would suck equally as much, if not incredibly more, today.)
Re:Common object model (Score:3, Insightful)
Well, ORBit is something like 2-3x faster than DCOP iirc. ORBit still has painful C apis, but that's just a property of OOP in C I think, CORBA in for instance Python or some similarly high level dynamic language is pretty painless.
Before the actual KDE 2 release, before DCOP and KParts were ever invented, KDE used to use MICO for its CORBA implementation. We had cool technology called KOM/OpenParts, which was completely 100% based on CORBA. And it was slower than hell.
Yes, I know. Unfortunately, the KDE guys wrote off CORBA completely, rather than writing off the implementation (mico) as being unsuitable for desktop usage. It's like people with X. "Oh no, it's hard to get anti-aliased fonts in X!!" or whatever, when what they really mean is "I don't like XFree the implementation". And so today we have ORBit, which is pretty light and fast. Is it perfect? Nooooo, no way. CORBA is still complicated. But with that complexity comes features - like the ability to write an object in one language/environment, and use it in others, both inproc and outproc.
I think we're confusing two things. You can use CORBA for DCOP style "poke me" IPC, but something like DCOP/DBUS seems to be better. You can also use it for distributed objects, something that KDE has nothing for. KParts is tied to Qt/KDE/C++/inproc only. DCOP is not suitable for distributed objects.
I'm talking mostly about distributed objects. They interest me. DCOP style scripting is cool too.
(Sorry for the rant, but you have NO IDEA how much CORBA sucked for us, and I am 100% sure that it would suck equally as much, if not incredibly more, today.)
Except it doesn't. Sure Bonobo has issues, but then it's more ambitious. See how useful COM/ActiveX is on Windows? That could have been CORBA on Linux. Now - now we have nothing, and are reduced to bickering about whether objects in C are good or bad :( [sigh]
Re:Common object model (Score:5, Insightful)
I can tell my media player (Kiwi) to go to the next song with this command from a script, or the command line, or from another app:Talking with a few GNOME developers, it seems that something this simple, this useful, is still not possible in GNOME (Please, correct me if it is! I hate being misinformed).
As far as the 'distributed' nature of CORBA: Can you show me how to take advantage of this? I can't find any documentation on the Net about it, and the APIs in CORBA are hopelessly complicated (even for me to understand, and I'm a developer...). If my Gnumeric object is on another machine, how will Evolution embed that Gnumeric object locally to show a spreadsheet? Is that even possible? IIUC, it's supposed to be, but I've yet to see it done.
The language-neutrality I'll give you, but in response to that: How many useful Bonobo parts are being implemented in Python? How about ruby? Or Perl? Or maybe Smalltalk, or Java? No? Why are they all in C, if the language doesn't matter? (Again, correct me if I'm wrong - but I've yet to see a Bonobo part implemented in C++, let alone any scripting language.)
In short, I find that the KDE technology gives us flexibility that we don't see in GNOME, and it works plenty fast enough for our uses, while also being easily accessible to new developers.
When I was adding new DCOP functions to Kiwi (having never used DCOP before) it took me all of twenty minutes to figure it out; once I had figured it out, adding the second DCOP function took five minutes. How long do you suppose it takes a new GNOME developer to get up-to-speed on using ORBit?
Re:Common object model (Score:3, Insightful)
Maybe another Linus Torvalds is hacking it out as we speak.
Re:Common object model (Score:2)
LOFL - Laugh Out Freakin Loud.
Even if you were a KDE developer I would find such a statement extremely silly. I mean you are a GNOME developer and now you are worrying because KDE doesn't want to use GObject? Come on! How about you go and ask the gnome development list to use QObject and then report back how irritated you are with the small but vocal minority that might disagree. Truly one of the most amusing comments I've seen Mike
Re:Common object model (Score:2)
I am not a GNOME developer, merely an interested observer.
Come on! How about you go and ask the gnome development list to use QObject and then report back how irritated you are with the small but vocal minority that might disagree.
Except they'd have good points, like harder to make language bindings and licensing. And for what it's worth, GNOME already has a C++ dependancy in the form of FAM, and if Ephy gets into the core (which the gnome project seems to be keen on), that'd be a core app written in C++. So, really, you can't draw comparisons here.
Re:Common object model (Score:2)
Fight it out (Score:2, Funny)
the fundamentals are key (Score:3, Interesting)
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.
Re:the fundamentals are key (Score:2)
but then again *I* don't use KDE
Funny excerpt... (Score:2, Interesting)
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.
Re:Funny excerpt... (Score:3, Interesting)
And how exactly do you take 8 different programs to do the same thing and find the one that's best for you? The advantage of Debian for me is that I do it all the time, and it doesn't hose my system (which I understand most Linux and BSD distributions have also got down pat.)
Joe-sixpack windows (and mac) users are very prone to the shareware syndrome, _because_ it's do frigging easy to install random software.
Again, that's not a bad thing. When I hear jokes about "I'm going to make Windows stable by reinstalling Windows and only installing a few programs." and the other character stares while he installs ICQ, Winamp and a couple dozen other programs, it makes me shake my head. I can install all the programs I like in Linux without worrying about stability.
I noticed that they even didn't touch WinXP (Score:2, Interesting)
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.
detail not opinion (Score:4, Insightful)
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?
isn't this what ms got into trouble for? (Score:2)
A desktop is useless unless it enables you to get your work done, therefore it should be our aim to provide people with as complete a solution set as defined by the general needs of the userbase (as oppose to, say, our personal opinion).
and don't say that his next sentence regarding people being REQUIRED to install it - as people could quite easily install Netscape on top of Windows...
Know thy enemy/ Too much is simply too much (Score:5, Insightful)
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.
Reinventing the wheel (Score:4, Insightful)
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...)
menus and apps (Score:3, Interesting)
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?"
sigh (Score:3, Interesting)
Aaron J. Seigo
Re:Commercial alternatives (Score:2)
Re:moron compatibility for gui lamos (Score:2)
Re:KDE, Gnome , just dull Windows clones. (Score:2)
Throw a business person or newbie in front of Enlightenment (which is cool lookin') and they'll freak.
Re:KDE, Gnome , just dull Windows clones. (Score:2)
Do you have any ideas? Is there a forum in which this kind of idea is discussed? I would like to see the UI totally abstracted away from the program, so that a program simply exports functionality, and the OS draws widgets in keeping with the platform's look and feel.