JUN
14
2003

KDE-CVS-Digest for June 13, 2003

In the latest issue of KDE-CVS-Digest, read about new Kontact plugins for summary, notes and the newsticker,
KOffice gains improved import and export filters plus template loading from the command line, we also see an improvement in speed for Konqueror file and image viewing, and Dr Konqi gets hooked into KDevelop for debugging. Also, improvements to KDE Print,
KGhostview, user interface cleanups, and numerous bug fixes.

Comments

Derek, thank you very much for doing all the hard work every week and giving us this wonderful KDE-CVS Diggest. I love to read it!


By Michael Thaler at Fri, 2003/06/13 - 5:00am

Jeeez! These "Thanks Derek" posts are getting old.


By Jörgen S at Sat, 2003/06/14 - 5:00am

Why? The KDE-CVS-Digests are very much appreciated. Why don't *you* stop being so negative? *That* is getting old.

So, yes, back to the topic: Thanks for providing up to date news regularly every week. I don't think a *single* week has been missed since the launch of KDE-CVS-Digest. That is quite something.


By ac at Sat, 2003/06/14 - 5:00am

To put a little perspective on things...

I spend about 3 hours to generate the digest.

Most commits to cvs probably take a couple of hours to find problem, fix, compile and test, maybe check with other developers, etc. Most don't get a mention in the digest. For example, Dirk and coolo regularly go through everything to make sure it compiles. Quite a few of the larger ones probably represent days of work.

The whole thing could (and did) work well without me. But without the developers, we wouldn't have anything to talk about.

The thanks are noted and appreciated. But please make sure you thank the ones doing the work.

Derek


By Derek Kite at Sat, 2003/06/14 - 5:00am

Thank you very much!
Thank you very much for doing all the hard work every week and giving us this wonderful KDE-CVS Diggest. I love to read it! its not a good way to say crazy so it means that you have not been underestood me yet then it's not my fualt


By Sohrab Navaee-Ardeh at Tue, 2006/03/14 - 6:00am

In 2003 my venture to seek higher education abroad brought me to the Kingdom of Thailand and ultimately to Shinawatra University. I received a full scholarship at Shinawatra International University for doing Bachelor of Communication Systems and Network Managements in Computer Science in 2004, such a scholarship which is rarely given to foreign students who are excellent to study in abroad.
My keen interest to seek for international learning experiences and broaden my knowledge has always persuaded me to constantly look for opportunities. This is the primary reason why I have put this opportunity to do my internship in your company as one of my top priorities. This shows my strong commitment and eagerness to join this program. I strongly, believe that in a world that is constantly moving towards globalization, knowledge and experiences gained from certain one country is not sufficient. Not only International learning experiences helps me widen my academic knowledge, but it also strengthen me other aspects of societal knowledge which is equally important to qualify for a competent graduation.
Sohrab Navaee-Ardeh
Canadian arranger assistant,
Vancouver,
Canada.


By Sohrab Navaee-Ardeh at Thu, 2007/03/08 - 6:00am

I am Sohrab Navaee-Ardeh a Sohrab Navaee-Ardeh, Canadian arranger assistant,Communication Systems and Network Managements.
I am eager to exchange cultural activities as I enjoy learning new things from different cultures and social settings. Other than English, I am also proficient in several Asian and Middle East languages including Persian/Farsi, Thai, Arabic, Ordo.
Before studying at Canadian Uuniversities, I studied my both Pre-University and Diploma in the filed of Mathematics and Physics in Rezvanshahr, Iran. I received an award of third rank among all Diploma Mathematics-Physics Students at Englab Eslami high school in 2000, and a second rank among all Pre-University Students at Pre-University Center, Gillan, Iran in 2000.

Sohrab Navaee-Ardeh,
Canadian arranger assistant,
Vancouver,
Canada


By Sohrab Navaee-Ardeh at Thu, 2007/03/08 - 6:00am

is anybody else have this bug with cvs .
cant umount cdrom device after viewing in konqueror.
http://bugs.kde.org/show_bug.cgi?id=58504    


By maor at Sat, 2003/06/14 - 5:00am

Is this a dupe of 37780? I still have this problem with 3.1.2, and it's been around since before 3.0 was released.


By Blue at Sat, 2003/06/14 - 5:00am

look like it's a dup of 58504  bug so i added my comment there.


By maor at Sun, 2003/06/15 - 5:00am

For some reason I can't unmount cdrom while using icons. I can do it from the command line. Any suggetions? Thanks.

chris


By Christopher Moniak at Fri, 2005/03/18 - 6:00am

I'm very happy that KDE has decided to focus more on usability and general polish more now. This is one of the areas it lacks most at.

Against XD2 using the latest stable GNOME no current KDE distribution can hold its own to it overall. XD2 looks amazing, the entire desktop is integrated and overall pretty polished. It's biggest drawback is proabbly that it doesen't give enough power to the user, for example I can not edit the menu easily, however KDE gives an excess of options, what needs to happen is a balance

I really hope KDE developers all download XD 2 and try to implement what they like this desktop is far more inutiitive and a little faster than 3.1. it is also far better looking.

For some screenshots and feature highlights check this out: http://ximian.com/products/desktop/features.html

I have to say that I am very very pleased with XD2, it is the most usable and attractive desktop. This sums up most things I don't like about Konqueror in terms of apperance: http://kde-look.org/content/show.php?content=3910

ANYWAY, PLEASE CHECK IT OUT! KDE DEVELOPERS NEED TO SEE THIS, THERE ARE SO MANY THINGS WE COULD USE IN KDE FROM THIS DESKTOP!


By Alex at Sat, 2003/06/14 - 5:00am

bug report for look and feel: http://bugs.kde.org/show_bug.cgi?id=58944


By Alex at Sat, 2003/06/14 - 5:00am

every time there have to be one talking about gnome this gnome that
u like gnome use it if i would like to use desktop that look like xd2 i'll use xd2 but it's ugly usabillty is sucks and that's all.
so stop be annoying u want xd2 use xd2.
if u want to say somthing usefull say it don't talk about xd2 this xd2 that just say what u think.


By enough at Sat, 2003/06/14 - 5:00am

I'm not posting here just to say "EVERYTHING IS PERFECT IN KDE EVERY OTHER DE IS INFERIOR GO KDE AND THANKS!" like many people here , I actually want to post a realistic opinion on how things ar elooking on the other side and what I think needs to be improved. It is no help to post encouraging statements without any crititicism to the KDE developers, what is not working is a lot more important for them to know than what is working great.

I think KDE in general is a better desktop for more advanced users, but XD2 is far more intuitive, like the way filters are added for their find tool or the way when one of the column headers in the list view is clicked that row is slightly darker to show which column was selected and many other things. KDE I believe also has a better base to work from, and better toolkit. It also includes many more feautres, though many times hard to use or just plain needless. It is the opposite for GNOME, sometimes there are not enough features.

For example, I switched my mom to XD2 and SuSE 8.2, because she loved the way it looked and felt. I had thousands of e-mails, documents, pictures etc. all copied to her home directory. Unfortunately because Windows runs as root everything was read only for her (indicated by a nice emblem for the files, gotta love thsoe emblems http://bugs.kde.org/show_bug.cgi?id=37300 ;)) and when i change dthe permission of the backup folder the files inside it still remained with the same permissions. I almost ran her as root by default before I decided to try Konqueror to see waht it will do. Thankfully Konqueror did not omitt this essential feature and after I changed the permission fo the folder and cecke da box saying something like change permissions of all files and folders inside too everything was great =)

You see, I like KDE a lot, and I want it to succeed mor ethan any other DE, because KDE developers seem to care about the architecture and not just features, this is exactly why I have submitted over a dozen bug reports and none for GNOME. I use KDE, but I am an experienced user, someone like my mom likes GNOME more than KDE because it is more inutuitive and this is what needs to be improved. I do not want KDE developer to strip the desktop bare, just improve its current features and their usability. For example the background program displaying a website for the background in KDE is totally unpolished and is very poor. Its gui is bad, and all it does is take a screenshot of the website rendered in konqueror, it does not even bother to remove the scrollbars which can not be used. This level of quality should not be in KDE.

I hope you understand.


By Alex at Sat, 2003/06/14 - 5:00am

Hi,

few people care about Gnome here. Why should they at all? Obviously Gnome developers don't share KDE goals, otherwise they would develop KDE probably. The same holds true otherwise.

The goal of KDE is to empower the user. The goal of Gnome is probably to make money of your mom, force everybody to do it the same way, or whatever. Just look at the button order. OK/Cancle vs Cancle/Ok. Sure the HIG is a nice thing, but I personally prefer configurable code that allows my HIG to appy.

I am personally very happy that everything in KDE is improving all the time. Gnome was close to dying around Gnome2.0, is it better now anyway, is it actively developed outside secrecy maintaining Ximian?

Little to no impact on improving KDE can come from Gnome as Gnome is not or not openly developed as KDE.

Yours,
Kay

PS: And has to be mentioned, the usage of CAPS is not appreciated either and never has been the indication of person capable or willing to help.


By Debian User at Sat, 2003/06/14 - 5:00am

Flaming GNOME does not make it any less good than it is.

HIG is meant to be followed by everyone, including developers who may think otherwise. The GNOME HIG was developed in consultation with their developers, and because so many are actually using it, GNOME apps actually look very consistent. Consistency is IMO most desirable. Once people get used to OK/Cancel, as long as all apps they use do that, they will not use it. GNOME also makes good use of color in the dialogs, which helps users correctly identify the choices being offered. GNOME does not force anyone to use their button order. If you do not follow the HIG, then your app is not included in the base GNOME. Thats all. The fact that so many not even targetting inclusion in GNOME actually do use the HIG speaks volumes about how good the HIG must be though. KDE needs something like that.

GNOME is openly developed, only that companies contribute a lot. They also spend money on it for user testing. Three companies, Redhat, Sun, and Ximian contributed to the making of that HIG. KDE needs more of that. It is easier for volunteers to code than it is for them to do thorough user testing or even give some of their money which is where companies come in because they do have a financial interest in keeping the project going.

And you are wrong that nothing from GNOME can improve KDE and vice versa. Only last week, Nat Friedman said something about the clock configuration dialog, and it was promptly fixed because it was really bad. That was an idea from a GNOME person, albeit read from an interview. Plus with Freedesktop.org, both sides need to agree on ways of sharing information between them.

You must get it out of your head that having companies come and give direction to the project is tantamount to taking it away. They cannot take it away. KDE will stagnate if it does not get its share of that money being used to develop opensource products.


By Maynard at Sat, 2003/06/14 - 5:00am

while i agree with some of the things you've said, i'd like to nip in the bud two new fallicies that are starting to emerge as KDE urban legends.

first, the idea that Nat Friedman's comment caused the clock config to be rewritten is bogus. i had started on this weeks ago and had been puttering away on it here and there with no real "Must be done in the next 2 hours" urgency because 3.2 is a long ways off and i'm working on quite a few different things for 3.2 (as are many KDE developers). had Nat not said a thing, that dialog still would've been rewritten in 3.2. in fact, because he said something and a few people jumped on it immediately it caused duplication of effort. yes, outside critique and viewpoint is good, but in this case it made no real difference for 3.2. i wish people would stop purporting that it did.

second, the idea that without mo' money KDE will stagnate is bogus as well. there are so many things wrong with this one i don't know where to begin. first off, there are KDE developers who are payed to work on KDE. more people are finding ways to support themselves doing KDE work, and this trend is only increasing. second, KDE got to where it is today without all those "oh so necessary dollars". and i hope you'll agree with me that where KDE is today isn't so bad, and that it isn't stagnating. third, the first time i heard this argument it came from no other than Miguel De Icaza himself. as you know he's rather pro-GNOME, and GNOME's biggest accomplishment to date is that they have managed to get lots of dollars in the door for development. i applaud them for that. but one may notice that whenever Miguel perceives GNOME as having done something good, he tends to turn around and say that KDE is doing that same thing poorly and that's why it will fail and die. whatever. next week he'll discover 7-11 "nachos" and decide GNOME will succeed because it's processed-cheese friendly while KDE seems to prefer real cheese and will therefore cease to exist in the near future.

and just to make myself clear: i agree that more corporate involvement (and more volunteer involvement too!) can benefit KDE and all of it's users greatly... KDE is quite corporation friendly as has been seen in the efforts of Mandrake, SuSe, Trolltech, KDAB and others. there is a foundation set for those who would like to support KDE with effort and funding, and this will only strengthen in the weeks and months to come.


By Aaron J. Seigo at Sat, 2003/06/14 - 5:00am

Yes, GNOME has gotten a lot more corporate attention than KDE from a lot of companies and it has seen a great increase in quality and especially acessibility and usability.

KDE on the other side has had little corporate support from big companies like SUN and it does not enjoy being shipped as the default DE in the biggest linux distro in the world with over half of the entire linux installed base.

However, even with all that money thrown at GNOME, it is still questionable if they are truly ahead overall.

What has made them so much more commercially adopted is probably that their license is LGPL and that companies don't need to pay anyone if they want to make a commercial product using say GTK. Therefore, at least the initial costs are FAR FAR lower and this gives GNOME an enormous advantage to the corporate, especially in times when money is tight.

KDE, can not compete with GNOME on the initial cost, but we can compete in making the total cost lower for KDE by having a much better architecture, toolkit, DOCUMENTATION (really needs work) and support from the community.

Ther also need to maybe be some benefits for companies suporting KDE, like a prority support list or something?!


By Alex at Sat, 2003/06/14 - 5:00am

How comes you think that Gnome is "much more commercially adopted"? I only see Red Hat using Gnome as (heavily tweaked) default, all other commercial distributions use KDE as default. And I see more commercial programs making use of QT than of GTK. And why does it matter for you what companies have to pay?

Companies supporting KDE benefit from a free well thought out and well working technical backend with a very flexible frontend (eg. Kiosk mode). Improvements are easy to include on a system level and will benefit all programs due to the existing strict code sharing infrastructure within KDE.


By Datschge at Sat, 2003/06/14 - 5:00am

Lets see. The big distros are Redhat and SuSe right now. Then there is Lindows, Lycoris, Mandrake and Xandros. I put Mandrake together with tose because I see no way for it to go but down right now.

Suse is big in Germany and Europe. Redhat is the Linux company with the largest market cap, and the largest share in th corporate world by far. Even compared with Suse. If anyone is making an app to run on Linux, if they provide rpms, then they provide Redhat ones. Then in some cases they provide with Suse and Mandrake ones. Then yu have SUN, Ximian and Redhat basically sponsoring the writing of the HIG. Sun ships Solaris with GNOME. Making a few tools in KDE does not count as major support IMHO. If you look at true contributions, GNOME has way better contribution than KDE. (Home)Desktop is not the most viable market right now. Enterprise desktop maybe, and guess who dominates there. Look at Ximian. They will only provide packages for Redhat 7.3, 8.0 and 9 vs only SuSE 8.2 and none for anyone else. Should give you very good leads as to who is major in the market right, at least of those Ximian is targetting.

Maybe let me give you a short list of Major contributions to GNOME

1. The HIG - Sun, Redhat and Ximian
2. Evolution and Red-carpet - Ximian
3. Bitstream Vera- The now default font set in GNOME - Bitstream (Yes KDE can use them)
4. Nautilus - I know Eazel went out of business
5. GNOME Setup Tools - formerly Ximian Setup Tools
6. Eclipse - Well not really, but there is a very mature port to GTK - IBM
7. HP was also going GNOME, but they have backtracked for now.

Just know that Distributions do not really count unless they are as big as Redhat. The rest pretty much deal with very small niches and are going nowhere certain right now.


By Maynard at Sun, 2003/06/15 - 5:00am

I really don't see what you want to say or achieve.

I don't and KDE as a project shouldn't care whether Red Hat hast the "largest share in the corporate world" (in the US?). I also don't care whether Red Hat forces others to provide RPMs while SuSE often gladly offers them themselves if there's demand. I don't care if any company contributed a HIG to Gnome, it was Gnome lacking one while KDE already has it [1] for years. Also I don't understand your definition of "true contribution", I just hope you don't consider your post as one. ;) As for enterprise desktops, Microsoft dominates by far there, Ximian struggles for some time to open the market for alternatives, Xandros offered a more complete solution for former Windows users for some time already and SuSE just extended its offerings with a new "linux desktop for enterprise" member due to "huge demand". Again nothing which should bother KDE as a community.

1. See http://developer.kde.org/documentation/standards/kde/style/basics/ and http://developer.kde.org/documentation/design/ui/
2a. See Kroupware/Kolab/Kontact project which can replace whole Exchange/Outlook networks.
2b. Offering an updating system for a system is a job which should be done by distributions. Red Carpet regularily breaks stuff unless used solely which makes it basically an own distribution with all its pros and cons. Nothing KDE should offer imo (besides the already existing KPackage).
3. Bitstream Vera is pretty much useless as of now since it lacks many unicode ranges.
4. Konqueror versus Nautilus, which cost more money, which has more features, which looks better, which is faster? I'd honestly pay more for Konqueror and hope someone adds the few eye candy Nautilus offers later on instead taking Nautilus and hoping for missing features to be added. But I digress, KDE as a project should never take part in silly battles like this.
5. GST formerly XST is basing on a flexible Perl backend for changing system values, there are already several people planning to create a KDE frontend (currently dubbed kggst, kde gui for gnome setup tools) for it in Nove Hrady.
6. There's KDevelop and even Kylix if you count QT.


By Datschge at Sun, 2003/06/15 - 5:00am

I think you miss the point of my post. I was not trying to say that these are better than KDE alternatives at all. Just to say that there is more corporate involvement in GNOME than KDE. The only on your list that is corporate is the Kroupware/Kolab/Kontact project. And IMO ; -

1. That style basics does not qualify as an HIG. Read GNOME's and Apple's to get the gist of what I am talking about. An HIG is needed.

2. Broken dependencies with red-carpet are not the result of red-carpet, but rather the packages in the channel. The problem is with Linux packaging more than it is about red-carpet.

3. Bitstream Vera is useful if you do not have to deal with the missing Unicode ranges. It is made to look good on the desktop. Most people use it with no problems. It was never said to be complete.

4. Yes Konqueror has more features than Nautilus, and it is a matter of opinion about the looks. I think Nautilus looks very good, better than Konqi. But to each his own. The point is that it was donated by a company to GNOME.

5. The point again is this was donated to GNOME by a company. That KDE wants to make a front end for it is not the issue.

6. Yes there is Kdevelop, but you are still missing the point.


By Maynard at Sun, 2003/06/15 - 5:00am

> 1. That style basics does not qualify as an HIG. Read GNOME's and Apple's to get the gist of what I am talking about. An HIG is needed.

Sure, go make one for us :) *grin*

Anyway, GNOME needed a HIG more than KDE back with GNOME 1.4. It still needs a HIG more than KDE needs one. By using classes that found in kdelibs, KDE application developers can assure (1) that they follow good HIG standards that more than ~70% of the GNOME HIG talks about. This is the nice architectural nature of KDE. Note that some classes needs to follow good HIG standards in the first place. If we wanted to switch to no lines in Group Boxes, like GNOME for example, we could always create a KGroupBox class which calls setLineWidth(0) in it's ctor, and globally s/QGroupBox/KGroupBox through kde.

What KDE really needs isn't a massive application-writing HIG like GNOME. It needs a hig for kdelibs itself, and a small section for general application writing.

1) -- Using classes and services like KDialogBase, KStdAction, KKeyChooser, KNotify, KIntSpinBox, etc..


By lit at Sun, 2003/06/15 - 5:00am

Hi,

Which was exactly my point. And with KDE the HIG in code can be modified through personal configuration.

Not to say that HIG in code saves code duplication, allows higher flexibility should changes be needed and still allows people to cut down. Seen KDE Kiosk operation.

Yours, Kay


By Debian User at Mon, 2003/06/16 - 5:00am

Ok, so your only point is that you want stuff to be contributed by a company?


By Datschge at Sun, 2003/06/15 - 5:00am

I've had a lot of talks with SuSE guys in the last time and they've stated that SuSE sees KDE as the the superior desktop. And SuSE does a lot for the KDE (see their homepage).


By Ruediger Knoerig at Sun, 2003/06/15 - 5:00am

How is GNOME that much more commercially supported than KDE? I don't exactly see a huge amount of companies developing for GNOME compared to KDE. The only two large(r) companies that I can think of that have greatly supported GNOME development are Sun, RedHat, Ximian, and Eazel. On the other hand, SuSE, Mandrake, and Corel have greatly helped KDE development over the years. KDE has also enjoyed being shipped as the default desktop environment in almost all commercially available distros, except for Redhat. This has cancelled out the RedHat+default GNOME factor. Like it or not, RedHat will continue to dislike KDE-- they have been 1997 :)

> DOCUMENTATION (really needs work) and support from the community.

Yes, I do think documentation needs work. However, it's not so great in GNOME either, especially developer's documentation.

> Therefore, at least the initial costs are FAR FAR lower and this gives GNOME an enormous advantage to the corporate, especially in times when money is tight.

Sure, but I haven't exactly seen a large corporate rush to GNOME (or KDE)...

You might find this shocking, but KDE and GNOME only have to be marginally better in terms of usability in the future to be adopted widely. The major problem thus far for mass deployement of KDE and GNOME isn't the desktops themselves, but the supported software and base operating system it runs on (like Linux..)

When there is an easy way to configure the system (yes, system, not desktop), not mess with config files, install hardware instantly, migrate from Windows quickly, etc.., you'll see more migration to Linux/(KDE or GNOME) from Windows. Many of these things fall outside of the realm of a desktop in the X11 (that is, KDE or GNOME) sense. And many of these things are already being worked by distro makers.


By fault at Sat, 2003/06/14 - 5:00am

Redhat is perhaps the only major distro using GNOME as the default, but their market share is larger than all of the KDE distributions put together!

In addition, msot companies that decided to develop for Linux have used GNOME/GTK and not KDE/Qt, for example Lost Marble's excellent animation program, Loki's tools, Ximian's programs, I'm not sure but I think WineX too, and Mozilla's only got a GTK frontend that is actually maintained, Eclipse only has a GTK front end, even Mandrake uses GTK to develop their tools and so on.. all these companies mad ethis decision only because it was cheaper to use GNOME/GTK and so we need to show them it is not if you consider the total cost for lets say 5 years, or anyway the architecture needs to be vastly superior.

It IMo is better if KDE gets a company than if GNOME get sone to develop using their tools because the comapny has to pay trolltech a fee if developing clsoed source and so trolltech will thrive as KDE gains more momentum and KDE will get a better and ebtter architecture and support from trolltech and Qt will also improve faster IMo.

Anyway, the license sounds fair, if you want to make a profit and you close the source you pay, if you don't want to make a profit or you GPL the program you don't pay trolltech.


By Alex at Sat, 2003/06/14 - 5:00am

You are living in the US, don't you? SuSE is the largest distribution in Germany, I'm pretty sure Conectiva is the biggest in Brazil, TurboLinux in Japan, Red Flag in China etc. Just because Red Hat seems to be the only local distribution you can buy at your place (after Caldera went to hell with SCO) you don't need to conclude it rules the world.

That being said I think the discussion is pretty much useless. If someone starts a business he does so because he has a business idea, something the market asks for and he can earn money with. Many companies already do earn money with FOSS and use a desktop, if necessary, mostly based on KDE. Gnome never had such a broad widespread audience but always has been limited to few companies like Red Hat, Eazel, Ximian, Sun and HP (all US companies) which basically took over the project controlwise. With KDE way more companies are already directly and indirectly involved so I doubt a KDE counterpart to Ximian is actually that feasible businesswise. But that's up to the market's demand, not up to us as community imo.


By Datschge at Sun, 2003/06/15 - 5:00am

>Redhat is perhaps the only major distro using GNOME as the default, but their market share is larger than all of the KDE distributions put together.

I've seen reports that this is true, and I've seen reports that Mandrake has more users than RH. I have no idea who to beleive, personally.

Anyway, in almost every report that I've seen, KDE usage has ALWAYS been higher than GNOME's, usually by a considerable number. I think this is mostly because of stagnation in gnome developmeent from 2000 to early 2002. Very little happened then.

> In addition, msot companies that decided to develop for Linux have used GNOME/GTK and not KDE/Qt

Many of those instances are because the usage of GTK guarenteed smaller statically-made apps. Trust me, I worked for Loki in early 2001 :-)

We actually did have several copies of the commercial version of Qt, and I suppose we could have used it. But we wanted to keep our installer ultra-small. I didn't have access to the copy of commercial Qt while I was there though :(

Anyway, I'm pretty sure the decision by other companies, like Mandrake, is similiar. I wouldn't doubt that Mandrake already had enough copies of the commercial Qt to make what they needed. I beleive Mandrake open-sourced their tools anyways so they could have used GPL-Qt.

There are plenty of commercial vendors using Qt in making apps for Linux too. Good examples of this are Borland and Opera Software.

There have been plenty of people who wanted to port Eclipse to Qt, but at that time, there were some licensing problems with kdejava/qtjava, and the creator of it had at that time disappeared (Richard Dale)


By lit at Sun, 2003/06/15 - 5:00am

> Mozilla's only got a GTK frontend that is actually maintained, Eclipse only has a GTK front end, even Mandrake uses GTK to develop their tools and so on... all these companies made this decision only because it was cheaper to use GNOME/GTK

All these are under GPL afaik so the commercial Qt cost argument didn't exist for these! In Mandrake's case it may have been chosen because of the original author's preference/experience. In the other cases becauses there was a need to make a GTK frontend (or in case of OpenOffice.org a GTK-look-alike version) because no mature native Gnome/GTK version for these program type existed for Gnome.


By Anonymous at Sun, 2003/06/15 - 5:00am

Hello,

isn't Redhat using Bluecurve to migrate away from Gnome to KDE?

doesn't that coincide with Redhat on the Desktop?

wasn't KDE the sole reason of existance for Mandrake (a fork of the Redhat that didn't include the then legally unclear KDE) ?

and governments here in Europe change the desktop, which desktop is the only one mentioned ever? Yes, KDE. Because it can come closer to Windows HIG while still appealing those that like other HIGs.

Yours, Kay


By Debian User at Mon, 2003/06/16 - 5:00am

> as the default DE in the biggest linux distro in the world with over half of the entire linux installed base.

RedHat? Tell me the source for those figures. Debian, Mandrake and SuSE are far more popular than you perhaps believe.

> What has made them so much more commercially adopted is probably that their license is LGPL and that companies don't need to pay anyone if they want to make a commercial product using say GTK.

Tell me commercial/closed products which have chosen LGPGL because of this. Why do RealPlayer and Acrobat Reader Linux versions still look ugly and are not ported to GTK if this is such a natural thing? Why did Adobe even chose and pay for Qt for the Windows version of Photoshop Album?


By Anonymous at Sun, 2003/06/15 - 5:00am

Debian is mostly e geek distro. No major deployments there. Mandrake is mostly a user distro. Redhat is not too far behind Mandrake on the enthusiast desktop. In fact, the Redhat crowd seems to be growing of late. Suse is not even as popular as Redhat on the desktop. Redhat leaves them for the dust in the enterprise. Its trusted and already has one of the more recognized qualifications(certifications) in the industry. Internet polls are very skewed when it comes to comparing the popularity of these distros which is where a lot of people get their stats from.


By Maynard at Sun, 2003/06/15 - 5:00am

> Debian is mostly e geek distro. No major deployments there.

Eh? Debian is for sure the second most used distro for servers.

> Mandrake is mostly a user distro.

Users don't count to use the over-all Linux installation statistic?

> Suse is not even as popular as Redhat on the desktop.

Source? RedHat afaik doesn't even have desktop targetted products yet.

> Internet polls are very skewed when it comes to comparing the popularity of these distros which is where a lot of people get their stats from.

So where do you get the figures from for your opinion?


By Anonymous at Sun, 2003/06/15 - 5:00am

I was stating my opinions and I do not believe I am wrong. OK, maybe stagnate is a wrong word, but once KDE becomes very large, it could need a better organisational structure which is more corporation friendly. Right now users rule what goes on there, but once interest goes past enthusiasts, then there will need to be greater representation for the non enthusiast users, which is most likely to be companies serving their clients. Right now, I believe signals in the open source world are terribly misleading. Many popular open source projects are popular because of their enthusiast bias. This is why you go to many mailing lists and you hear people extolling the virtues of Windowmake, Fluxbox, Enlightenment over even KDE and GNOME. You and I know they are both wrong, and there is no way they can be better than a proper full fledged desktop. The software needs to move past the enthusiast stage to a stage where actual users for whom software would be grudge purchase in a way demand certain features. These people are not on mailing lists and do not frequent the dot. Neither do they know or care to know what KDE is.

The community does not have the best access to these groups, but companies do, since they sell products to them and their involvement probably will shift the aims of the project to incorporate them more. This is partly what happened to the GNOME project. This is where the community wil probably feel they are losing control of the project and start complaining. And many may leave like many quit GNOME.

Many people do not enjoy computing like I imagine everyone who comes to the dot does and therefore their preferences are very different to our preferences. You just have to look at the BSDs to see how far the community takes you and in which direction. The BSDs are technically 'better' than Linux, especially with regards security, but miss a lot of features which we now take for granted in Linux. So while development would not 'stagnate' as such, just try to think for example, where the Linux kernel would be without the the involvement of companies like Transmeta, Redhat, IBM and so on. Not as far as it is now certainly.

So no, where KDE is is not bad at all. On the contrary, it is impressive. But it needs the steadiness a few more paid maintainers and programmers can give to it the future.

And I do remember Miguel admitting that GNOME had fallen behind on some aspects. The point is don't listen to Miguel, he is selling GNOME, so expect what ever he says to be a bit of a sales pitch. Listen instead to nuetral analysts.

My point with the whole Nat thing was that he noticed something was wrong with something in KDE, and he pointed it out. That it was being fixed was not what I was important there. The point is some people actually reacted to what he said (A good thing) and is part of how the two projects can help each other. It did create as you said, duplication of effort, but the fact is some people reacted to it.


By Maynard at Sat, 2003/06/14 - 5:00am

KDE is already very large: The amount of official KDE source code is nearly equal that of the Linux kernel.

KDE is very corporation friendly: Companies can easily contribute improvements to KDE, as long as they actually improve instead break stuff they are very much welcomed from everyone. And all KDE users as well as all companies using KDE benefit of that. Only if a company doesn't want to give back its products basing on QT to the community which gave it the environment they'll have to pay Trolltech for being able to keep the source closed.

KDE doesn't need companies working on KDE to survive: KDE has a large community contributing to KDE. Due to the technical quality of KDE more and more long time KDE developers who know what they are doing are paid by companies to work full time on KDE. Moreover the basic framework is undisputed and allows any kind of contributors with or without commercial interests to extend KDE. A good example for a specific commercial interest leading to valuable contributions is the Kroupware/Kolab/Kontact project which can replace whole Exchange/Outlook networks and will be included in KDE 3.2.

KDE is easy to support as soon as you know how to: KDE offers many different ways how one can make valuable contributions. Discussions about generic issues are usually a waste of time for anyone involved since KDE as a large project archieved a level of flexibility where noone is still willing to restrict it again anymore. Nobody denies however that there are many small pieces in KDE which are in need of improvements, and those are only improved when one actually picks them up and improves them. Please pick yours at http://datschge.gmxhome.de/support.html


By Datschge at Sat, 2003/06/14 - 5:00am

Nearly equal? Last count gave 2.6 million lines of code for KDE and 3.1 million lines of code for Linux 2.5.29.


By Anonymous at Sun, 2003/06/15 - 5:00am

How would you define nearly equal if it wouldn't fit for 2.6 and 3.1.
Both are around 3 Mio lines of code, so how would you call it?

Philipp


By Philipp at Sun, 2003/06/15 - 5:00am

500000 lines are no gap for you? That's nothing to catch up in a month or so.


By Anonymous at Sun, 2003/06/15 - 5:00am

I was curious about some exact numbers, so I ran cxxmetric plus some bash and python scripting automagic to scan the source files.. Here's what I got:

Linux 2.4.20
1,995,143

Linux 2.5.68-mm1
3,329,570

kdecvs (arts+kdebase+kdelibs+koffice+kdevelop+kdeaddons+kdegames+kdenetwork+kdeartwork+kdepim+quanta)
76075+579346+504765+663920+43862+196307+93308+101963+32109+205122+87717

= 2496777 (yes, I'm missing a few like kdeutils, kdeadmin, kdeedu, kdegraphics, kdemultimedia, kdeaccessibility, kdesdk.. I would expect around ~600,000 more LOC from those combined)

kdenonbeta
649,458

Mozilla 1.3:
2,406,372

Xfree86 4.3.0:
2,129,444

Wine 4/11/03
701,312

gcc 3.2.2
1,026,056

qt 3.2b
694,368

gtk 1.2.10+glib 1.2.10
137,145+1,8546=155,691

gtk 2.2.1+glib 2.2.1+pango 1.2.1

31,5406+81,000+43,247=439,653


By jeb at Sun, 2003/06/15 - 5:00am

It may be that there is a different way of doing things. The corporate top down development model is familiar, but isn't the only way. In fact, corporate involvement in the FOSS movement, linux, gnome, apache, etc. came because a strong base of enthusiasts built a system that was better, more flexible, cheaper, freer, more stable than the alternatives. So now we stop doing what brought us this far? The desktop is getting very close to where it needs to be. It is progressing amazingly fast. This without huge 'corporate' support and involvement.

I would hate to see any reorganisation that would alienate the enthusiasts. For the simple reason that the enthusiasts are the ones who are doing all the work. They own the project. They are the programmers, translators, testers, etc.

Derek


By Derek Kite at Sun, 2003/06/15 - 5:00am

> I was stating my opinions and I do not believe I am wrong. OK, maybe stagnate is a wrong word, but once KDE becomes very large, it could need a better organisational structure which is more corporation friendly.

I'm sorry. You're just plain wrong here. It is a fallacy that I have to guess is based on the fact that you are making this observation from the outside. Here's some free advice. Don't buy the popcorn. KDE is the best example of bazzaar prgramming I know of and it works. Not only that but I will take our program, Quanta, and issue this challenge. Show me any web development tool that a developer has used seriously where that developer has also used Quanta seriously. Now, if they had issues with both ask them where they had better service. We are extremely friendly to compaines. If anything they have yet to warm up to us and "get it", that they can get the software for less on a community development model. There's nothing wrong with this because it's a new paradigm that will take time.

Here's a thought for you... Just because people do not yet fully understand a better, more productive and less costly paradigm does not mean that we need to rush our and adopt one that is gradually eroding to the up and coming paradigm we have. That's just wrong!

> Right now users rule what goes on there, but once interest goes past enthusiasts, then there will need to be greater representation for the non enthusiast users, which is most likely to be companies serving their clients.

Please don't be offended... but this simply illustrates you are pretty much unaware of how things work. I don't know if an in depth explanation is appropriate in a talkback. Again, I'm not trying to offend you but... Users don't choose! Maintainers, developers and release coordinators choose. It's done based on open discussion, with common sense, and with regard for users as much as possible. Because KDE developers are sincerely concerned about all users the reference to enthusiasts is only relevent in as much as they are also supported instead of a seemingly single focus on newbies. As far as corporate users go there is only one thing that needs to be said... Kiosk! KDE can be reshaped, thinned down, locked down and completely controlled. If you look into kiosk mode you will understand there is absolutely nothing that compares to KDE for corporate support!

> Right now, I believe signals in the open source world are terribly misleading. Many popular open source projects are popular because of their enthusiast bias.

Whatever merit this statement has must be contextural. I'll take Quanta for instance. Our mailing list doesn't go a lot into extolling the virtues of our program. It is open discussion and help. But Quanta's strength is in enthusiasts. They are enthusiastic because they like how it works, saves them time and gets the job done. Any given piece of software is going to draw a large portion of it's support, especially vocal support, from enthusiasts. I can't see that changing. If you can't get enthusiastic about new software you will probably stay with the old software. Right?

> The community does not have the best access to these groups, but companies do, since they sell products to them and their involvement probably will shift the aims of the project to incorporate them more.

There you go... several classic fallacies which indicate to me you probably dion't run a business or manage an OSS project. From the OSS perspective developers have direct access to users without filtering by corporate offices, shaping by marketing and constraints by accounting. Companies regularly promote useless fluff, vapor and half baked code for internal reasons and because the believe they can promote it. From a marketing psrspective companies try to know their customers... but you and I know our friends better. This is why 1 in 4 people in the US was in an MLM in the early 90s and it was doing billions of dollars in business. That's why the internet has done so well. Companies can be less faceless and more personal. Knowing the customer is not actually something companies do well without spending millions of dollars to find out what you and I talk about on a mailing list or over a beer. More over it's the selling of products that becomes the issue. I personally love to sell, but I sell a product I have absolute control over the quality of. The fact is once companies get involved they have to think about deadlines and bottom lines. This translates into software hacks, bugs and botched feature sets. Believe me when I tell you that outside of open source, unless you're an IBM fellow with free reign, it's not easy to do it right. KDE is good because it's done right.

> So no, where KDE is is not bad at all. On the contrary, it is impressive. But it needs the steadiness a few more paid maintainers and programmers can give to it the future.

I sort of agree with you here, but I wouldn't say "needs". I would say they would greatly benefit from this, but as you pointed out, not with a massive corporate oversight. For my part I'm actually looking to involve more users contributing so that I can increase the number of developers I sponsor. I have one so far and hope to add a part time developer next month.

The difficult thing is to remember what my dad always told me thought did... nothing... that is, nothing without action. Years from now the talk won't mean anything but the actions that were taken could well end up in the history books. ;-)


By Eric Laffoon at Sun, 2003/06/15 - 5:00am

Developers like me are spending their time and money both on KDE. KDE is self sustaining.


By Nadeem Hasan at Wed, 2003/06/18 - 5:00am

> GNOME actually do use the HIG speaks volumes about how good the HIG must be though. KDE needs something like that.

Much of KDE already complies with a lot of the GNOME hig.

Some differences between KDE-cvs and the GNOME-HIG are listed below (widely known things like ok/cancel button order and quit vs. exit are not listed).. this might look like a big list, but considering the size of the GNOME-hig, it really is not. KDE is already more compatable with the GNOME-hig than GNOME 1.4 ever was.

1. GNOME hig recommends using tooltips in menus, especially things like the footmenu. The k-menu does not have menu tooltips, and I don't think any apps do.

2. The GNOME HIG recommends most configuration dialogs to be "instant apply". I'm not sure why the HIG decided to do this however. I didn't state any usability reasons why this is superior to KDE/Windows "explicit apply" behavior. In fact, I think it would be confusing to end users as some dialog, and even some dialog options would have to be inherently explicit apply (the HIG tells what options should be explicit apply)

3. The GNOME HIG says that alerts must usually have primary and secondary text. KDE alerts don't do this. I like how the GNOME hig recommends doing Quit/Save Confirm alerts. A typical HIG-ified dialog would say "Save changes to document 'foo' before closing?" and then "If you close without saving, changes from the past FOO minutes will be discarded." KDE Save/Confirm dialogs, on the other hand, say "The Document 'foo has been changed'", and then "Do you want to save it?". KDE's is similiar to Windows behavior.

4. the GNOME hig says that authentication dialogs should "will present a button labelled with a verb or verb phrase describing the action authenticated, or OK if such a phrase would be longer than three words. Place this button in the bottom right corner of the alert."... For example, "Check Mail" if logging into a mail server. KDE authentication dialogs don't do this.

5. All window captions in KDE have the app name in them, like "Document - AppName". GNOME hig recommends that appnames don't appear in the window caption. It does say that if you really want to have it in the caption, it should be after the document name. KDE has followed that for years.

6. GNOME hig generally recommends that dialog box captions have full text of action performed. For example, Print "kde.dot.news". In KDE, it would be "Print - Konqueror"

7. The GNOME HIG says to put initial keyboard focus to the component that user is expected to operate first. KDE apps "generally" follow this. But I think an audit of all KDE apps would be nice for anyone looking for something to do in usability. I think nearly all of them are fine though.

8. The GNOME HIG recommends that wizards/assistants don't have help button but rather inline help. It also says that the introductory page shouldn't have a back button and only should have "big picture text". kpersonalizer doesn't follow this.

9. The GNOME HIG recommends that ALL menu items have accel keys. Most of them do in KDE apps, but not all. Note that this is offset somewhat in KDE, because KDE supports searching in menus by typing in letters.

10. The GNOME HIG recommends avoiding more than one level of submenus. This is generally followed by apps in KDE, but not the kmenu.

11. The GNOME HIG recommends that in western locales, buttons acting on contents of whole window should be at bottom. Most KDE apps follow this- some don't (thinking about things like kfloppy and kfind)

12. The GNOME HIG recommends putting a menubar in each primary application window. Again, most KDE apps do this. Some smaller apps like kfloppy, kfind, etc.. don't.

13. The GNOME HIG recommends not putting mechanism for hiding the menubar, as this may be activated accidentally, resulting in the application being "broken" for some users. But if it's absolutely needed, put some other way that it can be accessed again, like in toolbar. Konsole/Konq do provide another way-- through a context menu. However, the HIG says "Be aware that popup menus are used primarily by intermediate and advanced users. Even some users who have used graphical desktops for many years do not know about popup menus until somebody shows them." Perhaps another method of showing the menubar would be good.

14. The GNOME HIG says to limit top-level menus to a maximum of about 15 items. Most KDE apps do this. Some koffice apps don't.

15. The GNOME HIG says to provide an access key for each item in an popupmenu. However, to enhance their spatial efficency and readability, it says not to show keyboard shortcuts in popup menus. All KDE apps show keyboard shortcuts in popupmenus. I agree with the The GNOME HIG here.

16. The GNOME HIG orders popup menus as default action for object, other commands and settings in expected frequency-of-use order, then transfer commands such as copy, paste, etc, and finally input methods. KDE apps don't follow this. In konqueror-cvs, it goes, default action for , transfer commands, then command and settings, and doesn't show input methods in text edits at all.

17. The GNOME HIG says not to place more than about ten items on a popup menu, and not to use submenus. Some kde apps like Konqueror don't follow this. I disagree with the submenus though. Sometimes it helps organization. There are still extraneous things in Konq-cvs's popup menu like "undo". The GNOME HIG says that popup menus should act on the selected object, so thus, undo should only appear when clicked on content area, not on icons.

18. The GNOME HIG says that the best size for a group of menu items seperated by a seperator is around 2-5 items. It says also that single-item groups are best placed at the top or bottom of a menu. Some KDE apps don't follow this very well. For example, kwrite's tools menu or konq-cvs's edit and help menus.

19. The GNOME HIG says to label the menu item with a trailing ellipsis ("...") only if the command requires further input from the user before it can be performed. Do not add an ellipsis to items that only present a confirmation dialog (such as Delete), or that do not require further input (such as Properties, Preferences or About). KDE apps don't follow this.

20. The GNOME HIG recommends to use the "File" menu name with all apps that operate on documents. It's debatable wether KDE apps follow this like Konqueror :) Also, it recommends sorting this menu by locality. For example, items to save or load from file, followed by printing, followed by sending to a remote user/host. Some KDE apps such as Konq don't follow this order. Also, KDE apps tend to put things like "Properties" in the View menu instead of the File menu, as is recommended by the The GNOME HIG.

21. In the edit menu, the GNOME HIG recommends putting "Undo" and "Redo" even if app only supports one level of Undo. Also, HIG says to put "Preferences" here. KDE apps typically have another menu to do this. I agree with the HIG here.

22. The GNOME HIG recommends that by default, have toolbars appear directly below the main menu bar. Konsole doesn't follow this.

23. The GNOME HIG says to provide an option to return all toolbars in your application to the default. The KDE dialog for this doesn't. This is important because in apps like Konq, you can remove things like and not have a way of getting it back-- or mess up the toolbar somehow (I've done it in Konq)

24. The GNOME HIG says to not use vertical toolbars by default. Some koffice apps like kword do. According to the HIG, a better solution is to display less default toolbars, perferably 3 or less rows.

25. The GNOME HIG says that if toolbar is configured to show labels beside button icons rather than below them, only show text for most used ones or it'll get too wide in a hurry. Evolution, for example, shows check mail, etc.. KDE apps show text for all icons.

26. The GNOME HIG says that toolbar icon tooltips should be more descriptive than the corresponding menu item. For example, "Create New Document" instead of "New". KDE apps don't follow this, but rather give a tooltip of the menu item itself.

27. The GNOME HIG says that if the user types three invalid characters in a row in an entry field that accepts only keystrokes valid in the task context, such as digits, display an alert that explains the valid inputs for that textfield. If less than 3, beep. KDE apps follows the latter, but not the former.

28. The GNOME HIG says that pressing Ctrl-Tab in a multi-line entry field should move focus to the next control. KDE uses this to flip desktops.

29. The GNOME HIG says that sliders should be used the value relative to its current value is more important than choosing an absolute value. Some places in kcontrol don't follow this, especially things like timeouts. Appearance->Launch Feedback in cvs, for example. Also, the GNOME HIG says that linked spinboxes and sliders should have sliders first and spinboxes second (depending on the locale)--- as the slider will more often be used. This is reversed in KDE in some places (like Launch Feedback), and is not reversed in others (KPanel options)

30. The GNOME HIG says that checkboxes should clearly show effects of both their checked and unchecked states. If it doesn't, a radio button or combobox is better. This is broken in some places in KDE. For example, kcontrol->KDE Components->File Manager->Display file sizes in bytes. It's not clear what the effect of the unchecked state is. Also, checkboxes/radio buttons should enable/disable valid options/controls depending on their state. This is usually followed in KDE apps, but sometimes isn't (like kcontrol->Panels->menus->QuickBrowser Menus-> Show Hidden files should disable/enabled number of entries)

31. The GNOME HIG says not to use comboboxes/option-type menus in situations where there is more than 10 menu items, especially in preferences/configration dialogs. A better solution is lists or a seperate dialog. This isn't followed in some places in KDE, for example, Konqueror options->Web Browser->Fonts.

32. The GNOME HIG says to always label listboxes/views in some fashion. It isn't in some places in KDE. For example, kcontrol->appearance->Theme Manager or Splash Screen themes.

33. The GNOME HIG says to use Tree controls with a lot of care, because they are very complex, even for intermediate users. KDE doesn't follow this at all. Kcontrol itself is a giant tree control. It also says to label all tree controls. This isn't followed in kcontrol.

34. The GNOME HIG says to label tabs in header capitalization (like "Hi There"). 99% of all KDE apps do this, but there are a few that don't. For example, kcontrol->Local Network Browsing->lan:/ and rlan:/ tab (this needs to be reworded, anyway)

35. The GNOME HIG says to not assign accel keys to any tab labels-- they can't be used within tabs then. KDE apps don't do this.

36. The GNOME HIG says to use a list control instead of tabs when there is expected to be too many tabs to display in a screen. This might actually be good in things like a web browser.

37. The GNOME HIG says that taskbars should display information about the task the user is currently performing or when over a menu or toolbar. Some KDE apps follow this at least partially (Konqueror...), others don't (kwrite)

38. When there is no interesting status to report, the The GNOME HIG says to leave a status bar panel blank rather than displaying something uninformative like "Ready". This way, when something interesting does appear in the status bar, the user is more likely to notice it. Many KDE apps display "Ready." I strongly agree with the HIG here.

39. In statusbars, the GNOME HIG says to use a inlaid appearance for areas that respond to a double click and flat appearance for areas that are not interactive. Apps like kwrite don't follow this.

40. The GNOME HIG says that rather than using bordered frames, to use frames without borders, bold labels, and indented contents. It says that bordered frames add visual noise that can both make a window appear more complex than it really is, and reduce the ability to quickly scan window elements. Bordered frames are used quite heavily within KDE.

41. The GNOME HIG says to discard unnecessary operations. For example, to move back several pages in a web browser, a user might click the browser's Back button several times in rapid succession. To display the final requested page more quickly, the browser might not display the pages visited between the current page and that final page. This doesn't happen in Konqueror.

42. The GNOME HIG says that not when using configurable colors, to use colors the basic 32-color pallete vaiable from http://www.ximian.com/images/art-devel/ximian-palette for default colors. KDE instead uses the Qt-16 color pallete in some places, like kate. The GNOME pallete has been optimized for people with deuteranopia, and tritanopia, two kinds of color-blindness that effect 11% of all users in the world. The The GNOME HIG recommends using these and lighter and darker shades of these for default colors. They would be useful in places liks syntax highlighting in kate.

43. The GNOME HIG says to use a 12 pixel padding between window and controls, and 6 pixels between controls (and 12 pixels between labels and controls). KDE's default is something like 4 and 3 pixels, I beleive. Also, it says to align objects vertically when possible. Indenting is recommended at 12 pixels.

44. The GNOME HIG says not to avoid vague text in icons. For example, the ksirc icon is vague. The kmail icon is fine.


By lit at Sun, 2003/06/15 - 5:00am

Wow, that's a fantastic analysis! This deserves to be put somewhere in the Usability website...a good examination of the differences of KDE & GNOME's UI standards.

Thanks!


By Eron Lloyd at Sun, 2003/06/15 - 5:00am

1. this is only useful if the tooltips differ significantly from the menu items. this would obviously take quite a bit of work. it also isn't very easy to do with the majority of your menu entries are provided by libraries and not hand coded.

2. mixing instant apply and explicity apply is a recipe for insanity. not all things lend themselves to instant apply as the changes may be invasive, security related or take quite some time to take affect (>3 seconds). erring on the side of caution and consistency says "explicit apply".

3. this is a good idea and something that has been discussed. it's a lot of work however as it will require grepping the source for every instance of KMessageBox and fixing it. it should also result in a new set of static KMessageBox methods to accomodate this in a standard method. know anyone who wants somewhere to spend a few hundred hours on it?

4. this is not often a problem, but sometimes it can indeed be confusing. part of the challenge is that apps don't usually handle the authentication themselves, but the base libraries do. to know what was being authenticated and why would require some introspection from the library to the application.

5. *shrug*

6. good idea, and the support is already there (KPrintDialog::printerDialog takes a caption argument, and KPrinter::setup which is how this is usually called does this as well). just takes someone grepping the code.

7. so why did you mention this again?

8. agreed...

9. given the limited number of characters in most languages and the fact that many applications automerge the UIs of several different apps without knowing beforehand which ones or what their UI actually is this is far fetched as a 100% achievable goal. sometimes the GNOME HIG seems to assume a simple, static interface. such utopian states is not always what reality is made of.

10. the kmenu is an odd thing: it's a faithful user-configurable representation of the application .desktop files. the problem isn't that the KMenu has multiple levels and is therefore broken, but that different menu paradigms are probably useful for most.

11. many kde utils don't put their buttons at the bottom of the window. sometimes it's aesthetics, sometimes ergonomics. in the case of kfind, it mimics other KDE find dialogs and is embedable as a part in other apps (making bottom-buttons not a great option). these are the exceptions, and usually with good reasons for them. standard KDE dialogs ALL have the buttons at the bottom. so i don't agree with your point here.

12. why put menu bars in applications that have at most 2 or 3 items to put in them? do users get confused when they don't see a menu bar? or is a menu bar in those cases just more complexity and interface noise? the 'G' in HIG is for "guideline" not "rule". common sense must be applied as well, right?

13. agreed... this is a tough one, though, as the toolbar many be present either. ;-)

14. some KDE apps need menu reorg and rethought, yes.

15. and how will the user learn the key combination if it is so effectively hidden?

16. sort of like 14.

17. sort of like 16. ;-) that said, not having sub menus is sometimes a stupid idea, especially when you have dynamic sections (such as servicemenus) in an already large menu. BeOS had an Actions submenu, too. btw, they're usually referred to as "context menus", not "popup menus".

18. another "some menus need reorg'ing" thing. you could've wrapped up the last several items into one point, me thinks.

19. What you talkin' 'bout Willis? the KDE UIG state: "Notice that every item in a menu that first opens a dialog requiring additional information must be labelled with a trailing ellipsis". Preferneces, er, Configure does require further input, so does get an ellipses. Delete, About, etc don't. there are people that watch this in KDE CVS, and infractions are quickly fixed. i don't know what you're going on about with this point.

20. i wonder if users think in terms of locality. and who's to say that printing is more local than sending to a remote system? the printer might be down the hall, the remote system might be in the same room.

21. i don't think KDE handles Undo/Redo differently. and the Edit menu is NOT where preferences belong. KDE UIG says: " All actions available in the Edit menu manipulate elements of the content area (nothing else!)." that makes lots of sense. and when you see how many items are in a Settings menu it makes even more sense. a menu called Settings is about as clear as it gets, and keeps the Edit menu clear and small.

22. there is a good reason Konsole doesn't follow this. and if you think about it for a few moments, you'll probably figure it out! try this: open a konsole and start using it. after a few commands, where is your locus of attention? why, at the bottom of the screen. if the session switcher bar is at the top, you have to keep moving your eyes and attention between the top and the bottom of the window. not very ergonomic. downright stupid, actually. no, the switcher belongs at the bottom where your locus of attention will be 99% of the time. in KDE 3.2 the toolbar will likely be replaced with a tab bar anyways. and it will be by default at the bottom. again, common sense.

23. agreed. i've put this on my TODO, and it shouldn't be very hard to do such that all KDE apps that support toolbar config will get it automatically.

24. *shrug*

25. a nicety, i suppose. assumes the programmer knows what is commonly used, or difficult to understand, but that should usually be manageable to figure out. in any case, like #4 this requires deeper introspection by the libraries into applications and their state than is currently possible. many, and often most, menu/toolbar entries in a KDE app are provided by KDE libraries themselves.

26. the tooltip helps cement the relationship between the toolbar item and the menu entry. WhatsThis help is another matter altogether, and should be more verbose and helpful. in KDE menu entries and toolbar entries are usually one and the same thing within the program, btw.

27. very good concept. also on my TODO.

28. agreed. this is bad for accessability.

29. i agree with the GNOME HIG here. i'll probably post a patch for switching the order of the widgets shortly.

30. i agree with the clarity part, but the part about enabling/disabling dependant widgets really annoyed me. what you found in the panel config dialog was a bug, not a HIG problem. a bug. like any other. you have the where-with-all to find it, notice it and write about it in a lengthy 40+ point posting, but you can't go to bugs.kde.org and file the problem? anyways, it's fixed now. i wonder how many other similar microbugs people such as yourself are quietly sitting on?

31. in the dialog you mention there are too many font settings to give each a list. and giving a dialog just for the list is silly; a general purpose font dialog won't do since the user can only define the font, not the size, weight or style. i think you're misapplying the GNOME HIG.

32. where list headers are prudent, they should be there. but they aren't always prudent.

33. agreed. KControl is set to get some luvin' and usage of trees is diminishing.

34. the reason why KDE is so consistent here is because of a few very dedicated, wonderful people who proof read all those things. there's even a KDE widget style that autohighlights these sorts of errors. neat huh? as for the lan and rlan tab heading, that's because they are the PROPER NAMES of the items in question. it isn't Lan and Rlan, it's lan:/ and rlan:/. they are protocols. i agree a better name could likely be found, but if that is the name then the capitalization is right. 34 is a non-point.

35. talk about stating the obvious. so if there are accels available that aren't used in the tabs, then they shouldn't be put to work to make switching tabs easier? what kind of stupidity is that? *shakes head*

36. a list control or else rethinking the dialog. and one or the other is what usually happens, btw.

37. yes, more humdrum work to do that 99% of users will never notice. it should be done, of course, but the people who will appreciate it the most are reviewers, critics and people like yourself. great way to spend time.

38. agreed. you should compile a list of apps that do this. then create patches. it would be trivial.

39. difference in style. so what?

40. i disagree with both stands. i often find non-bordered windows with many options more difficult to use as there isn't a visual compartmentalization. i don't agree with having heavy borders, since those are distracting. something that suggests a tasteful, subtle hint would do well. we had a patch that got rid of all groupbox borders and i used it for nearly a month. boy were things less clear; perhaps with a complete rewrite of every dialog we could approach something decent, but that's a lot of work when probably all that's needed is a nicely done frame that isn't so visually obtrusive.

41. agreed.

42. 11% of people have a hard time seeing the syntax highlighting in kate?

43. KDE's defaults are 12 and 6 as well. and vertical placement is generally preferred. what's your point again?

44. yes, some icons could be improved.

your 44 point list is much longer than it really ought to be.


By Aaron J. Seigo at Sun, 2003/06/15 - 5:00am

> your 44 point list is much longer than it really ought to be.

I was just trying to highlight ways in which KDE and the GNOME HIG differ in terms of usability. I wasn't really trying to say which side I thought was better or what not-- except whcn I said so. Keep in mind that a list of similarities between the two would have been MUCH MUCH larger. The numbers are arbitary- perhaps I shouldn't have numbered.

> 2. mixing instant apply and explicity apply is a recipe for insanity.

Fully agreed.

> 7. so why did you mention this again?

Hmm, I don't think I did :)

> 9. given the limited number of characters in most languages

I don't think this is as much of a problem as...

> 9. (continued...) the fact that many applications automerge the UIs of several different apps without knowing beforehand which ones or what their UI actually is this is far fetched as a 100% achievable goal.

Yes, this is a problem unfortuantly. GNOME tends to use less components in terms of things like dialog boxes and configure dialogs than KDE does, and especially doesn't try embed to dialogs within larger dialogs as widgets, as KDE does with things like kcontrol, kspell configs within koffice, and many other places. This part of the GNOME hug is unrealistic for KDE.

> 10. the kmenu is an odd thing: it's a faithful user-configurable representation of the application .desktop files. the problem isn't that the KMenu has multiple levels and is therefore broken, but that different menu paradigms are probably useful for most.

Agreed-- the kmenu is fine. In fact, the foot menu in GNOME even has a additional layer of submenus than the kmenu does. This is why it was largely depreceated in favor of the "Applications" menu, which has a simliar layer of submenus as the kmenu does, except for "More Programs", etc... I don't think this is much of a problem though. The kmenu is essentially a system menu, and thus might be more complicated than other menus. However, users tend to use system menus so much that they can typically memorize and effectively scan through large parts of it.

This is similiar to what is said in Apple's pre-Aqua HIG. Apple chose not to add heirarchial menus to the MacOS apple menu for a long time. However, they did further usability tests and found that heirarchial menus (and in some cases, doubly heirarchial menus) within special menus like this were perfectly fine.

> 11. so i don't agree with your point here.

Again, not my point, was just contrasting differencies.

> 12. why put menu bars in applications that have at most 2 or 3 items to put in them?

I think you'll find that users will get confused if there is no menubar. The way to fix this problem is to treat kfind/kfloppy-type apps as dialogs (when not embedded..)

That way, users won't look for a menubar.

> 15. and how will the user learn the key combination if it is so effectively hidden?

Through regular toplevel (non popup) menus. Popup menus, according to the HIG, are meant to be efficient and quick for intermediate and advanced users- who will likely know the combos from regular menus anyways. Remember that popup menus are essentially shortcut menus-- not places to learn key combos. I still agree with the HIG here.

> 16. sort of like 14.

Sufficiently different from 14 :).. the problem is that in some parts, KDE lacks consistancy here. For example, when I right click on the trash in cvs, I get the default option, "Open". When I click on a directory in konqueror, I get "Create New Directory" (which needs be removed, by the way)...

> 17. sort of like 16. ;-) that said, not having sub menus is sometimes a stupid idea, especially when you have dynamic sections (such as servicemenus) in an already large menu. BeOS had an Actions submenu, too. btw, they're usually referred to as "context menus", not "popup menus".

Agreed that not having sometimes not having submenus is a stupid idea. As per terminology, I was simply using the GNOME HIG's one.

> 18 .... you could've wrapped up the last several items into one point, me thinks.

Probably, but I was doing individual subtopic by subtopic, instead of broad topic-- so I could elabortate more.

> 19 ... there are people that watch this in KDE CVS, and infractions are quickly fixed

Good point. I probably should have said that configure and preferences dialogs don't get ellipses under the GNOME hig, but do under KDE. I'm not sure which method is "right" here-- as configure dialogs often do require input, but not often specific input. Some config dialogs, like kkeychooser, don't require input as defined by the GNOME hig at all.

> 20. ... i wonder if users think in terms of locality.. the printer might be down the hall, the remote system might be in the same room.

Apparently people do think in terms of locality when it comes to file-type menus. You have a good point with remote printers.

> 22. there is a good reason Konsole doesn't follow this. and if you think about it for a few moments, you'll probably figure it out!

Yes, I know why Konsole has it's toolbar at the bottom by default :)

However, according to the HIG, most new users won't think to look for a toolbar at the bottom. It's good that it's being replaced by tabs in 3.2. I personally think it's fine to leave it at the bottom.. it's essentially a taskbar type of thing.

> 24. The GNOME HIG says to not use vertical toolbars by default.

It says this because "The eye does not scan vertically as well as it does horizontally, groups of mutually exclusive buttons are less obvious when arranged vertically, and showing button labels is more awkard and less space-efficient. Also, some toolbar controls just cannot be used vertically, such as dropdown lists."

> 30. it's fixed now. i wonder how many other similar microbugs people such as yourself are quietly sitting on?

I only noticed it after reading the HIG. Perhaps some novice user would be confused by it, though. Anyway, the goal of my post was to show differences between current KDE and the GNOME HIG, and similiarities as well; not to show bugs.

> 31. in the dialog you mention there are too many font settings to give each a list. and giving a dialog just for the list is silly; a general purpose font dialog won't do since the user can only define the font, not the size, weight or style. i think you're misapplying the GNOME HIG.

Agreed. Perhaps not a good example.

> 34. is a non-point.

agreed. was being too nit-picky here.

> 37. it the most are reviewers, critics and people like yourself

I don't personally care _that_ much about usability, actually. I'm not a critic of KDE either, I love it. I think perhaps a little consistancy is in order, though.

> 38. agreed. you should compile a list of apps that do this. then create patches. it would be trivial.

Sorry.. I wrote this thinking it was an accepted thing in the KDE UIG. It isn't.

> 39. difference in style. so what?

I think the idea is that inlaid areas look somewhat like a button to users.

> 42. 11% of people have a hard time seeing the syntax highlighting in kate?

Yeah-- based on default colors in kate. KDE could use some accessible color schemes-- anyway, this is

> your 44 point list is much longer than it really ought to be.

or longer, or shorter. It's just how I wrote it. Perhaps I shouldn't have numbered at all.


By lit at Sun, 2003/06/15 - 5:00am

i realize you were just highlighting differences... i wanted to give some light as to perhaps why some of those differences existed: sometimes it's a bug, sometimes KDE has pooched the dog, sometimes it's just a difference in style/attitude, sometimes the GNOEM HIG pooched the dog. =)

btw, you say you're not "that" interested in usability, but you obviously have an eye for details and a good deal of patience and follow up, judging from your posts to this article. ;-) it would be GREAT if you could post bug reports for the things you notice (or even create patches; you seem to be a developer yourself?). KDE, and therefore Free Software in general, would benefit from this.

my TODO now has a few more items on it thanks to your list.


By Aaron J. Seigo at Sun, 2003/06/15 - 5:00am

Pages