KDE Developers don't test their own programs...

Nathan Toone nathan at toonetown.com
Wed Mar 17 15:30:18 GMT 2004

Hash: SHA1

Here are my opinions - they probably differ from yours, but that doesn't 
invalidate your opinion.  (I like to play the devil's advocate).  However, I 
agree with you on one point - KDE is far from finished.  But I think that 
most people would agree on that point.  If you stand still, you may as well 
be going backwards - especially WRT computers and technology.

> I.e. KDE Addressbook. Don't even think of trying to use the csv
> importer. its totally useless to me because I cannot import my adresses.

Haven't tried it - so I can't comment.  It may be that your csv file is not 
100% conforming to specification though.  I don't discount the possibility of 
bugs, but I do know that for the most part KDE applications try to adhere to 
previously defined standards (and in my experience, they have done a good job 
of that - where KDE messes up is when you try to do something with a 
"nonstandard" file.)

> mime type detection might work for 95% of stupid newbies that never
> change anything. I tried to add .sid Tunes and Gameboy roms. But its not
> possible because both of them are recognized as octet-streams... That
> might be true but they still have different file endings.. well but
> konqi doesnt care.. hit is hit :-)

One thing to remember.  The extension of a file name is NOT THE SAME AS A MIME 
TYPE.  Mime type is something completely different.  This is one thing where 
advanced windows users really get messed up (it took me a while to figure it 
out too).  Mac users apparantly don't have this problem as much.  But whether 
a file is called "Myfile.ksp", "Myfile.doc", "Myfile.avi", or "Myfile.mp3", 
if it was created with kspread and has a mimetype of application/x-kspread, 
it will open with kspread.  KDE will *ALSO* recognize file patterns, but in 
the event that there is not a mimetype saved in the file itself.  (At least, 
that's my understanding, is that right?)  Again - this is an issue of doing 
things in a "nonstandard" way - mimetypes should be declared within the file 
- - not by file extension.  Extensions are WAY too easy to change.

> Viewing pdfs is still a pain because the tools render slow and always
> only the current page. After switching the page you still have to wait 5
> secs. Searching is a pain that way.. not to speak of the missing search
> function or the ability to select text (yes I know its ghostscripts
> fault but that still doesnt make it better). And before I forget, don't
> try to view landscape pdfs....

There are a lot of options for displaying PDFs.  KPDF (which I've found to be 
pretty quick, but sometimes renders blocky), KGhostview (which is pretty 
slow, I'll admit), XPDF (which isn't a KDE application, but it *IS* pretty 
slow - but renders well), and Adobe's own Acrobat viewer.  I think that 
Adobe's product should be a LOT better than it is - it lacks a lot of the 
functionality of the windows version...so let's start bothering Adobe and 
encourage them to support Linux better. 

> The reason why I dont file bug reports is because I just don't have the
> time to surf the homepages and check if my bug isn't already filed etc.

This is really a minimal amount of time - if you follow the KDE bug wizard, it 
does it for you.

> I already file reports for openoffice, evolution and sometimes debian
> packages. No matter what program it is for, it normally takes 10-15
> minutes. Way too much for just a simple bug. 

It's a small price to pay for a free operating system and desktop environment.  
Besides, if you don't log the bugs, you dont' have a right to complain about 
them.  It's kind of like voting - if you didn't vote, you don't have a right 
to complain about the current administration, because you didn't *DO* 
anything about it.  (Now if you voted for someone else, you have all the 
right in the world to complain about it.)  If you want to lend credibility to 
your complaints, you have to do everything you can do as well.

> I vote for an easy Tool 
> with a bug search function and a simple form to fill out all the needed
> information. Gnome developers have tried this but they forgot the search
> function. Without this I can't save time because searching for an
> already existing bug takes most of the time (besides waiting for slow
> php scripted webpages to appear :-( )

The bug submission pages at http://bugs.kde.org/wizard.cgi are among the best 
that I have ever found - they are quick, they do the searching for you, and 
if you don't like it, you can even file a bug on it - and they will get it 

> I am convinced that there are lots of people out there finding bugs but
> none of them files them because its still too difficult. The same with
> localization.

And if you file a duplicate bug - NO BIG DEAL!  This is to minimize work for 
the developers, but they know their bugs - and it doesn't take them that long 
to mark a bug as a duplicate.  You should do what you can - but I don't think 
you need to spend 15 minutes looking for duplicate bugs when you aren't 
familiar with all the bugs in the system.

> Enough rant.

No problem - I love to have discussions like this - and it's points like yours 
that show where applications like KDE can get better.

> I'd like to see what others are thinking.

That's what I'm thinking.  :)

- -Nathan
Version: GnuPG v1.2.4 (GNU/Linux)

This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

More information about the kde mailing list