Announcing KDE 3.2 Beta 1 "Rudi"

With the new year fast approaching, beta testing of the upcoming KDE 3.2 release has begun. The KDE Project is excited to announce the immediate availability of "Rudi", the first beta version of KDE 3.2. Sharing its name with the Kastle conference's host coordinator, Rudi represents the culmination of the KDE Project's efforts to date.

As no further features will be added between the release of Rudi and KDE 3.2, this is an excellent opportunity to preview the most advanced and powerful KDE yet. Packages may be downloaded from download.kde.org. As of this writing there are sources and binaries for SuSE and Conectiva, but other distributions will follow. The Konstruct build toolkit was updated.

With its 25 page feature plan, nearly 10,000 bugs closed and over 2,000 user wishes processed a complete report on what one can expect from Rudi would be so long that by the time you finished reading it, there would probably be a more current KDE release to try out. The only way to truly appreciate this release is to experience it first hand, but here are a few of the highlights anyways...

Read on in the full announcement.

Dot Categories: 

Comments

by luimarma (not verified)

OK SuSe users,

First install desktop-data-SuSE-8.2.99-61.noarch.rpm at the noarch directory.
Second execute following commands as root:

#cd /etc/xdg/menus/
#cp default_kde-information.menu information.menu
#cp default_kde-information.menu information.menu.kde
#cp default_kde-screensavers.menu screensavers.menu
#cp default_kde-screensavers.menu screensavers.menu.kde
#cp default_kde-settings.menu settings.menu
#cp default_kde-settings.menu settings.menu.kde

That works for me like charm.

Luis

by Ed Moyse (not verified)

I've not been able to use konstruct for months now ... I've tried several times, and I always get errors with the mirror download.kde.org assigns to me. Does anyone know who I should write to about this? It's extremely frustrating!

Connecting to download.kde.org[131.246.103.200]:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: ftp://ftp.lip6.fr/pub/X11/kde/unstable/3.1.93/src/kdebase-3.1.93.tar.bz2 [following]
--19:24:21-- ftp://ftp.lip6.fr/pub/X11/kde/unstable/3.1.93/src/kdebase-3.1.93.tar.bz2
=> `download/kdebase-3.1.93.tar.bz2'
Resolving ftp.lip6.fr... done.
Connecting to ftp.lip6.fr[195.83.118.1]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/X11/kde/unstable/3.1.93/src ...
No such directory `pub/X11/kde/unstable/3.1.93/src'.

by binner (not verified)

I have uploaded a new version of Konstruct which reduces the number of files you have to change to enforce the download from a specific mirror to one file (kde.conf.mk). Those mirrors omitting unstable/ should probably be excluded from download.kde.org rotation.

by Jayenell (not verified)

I have the same problem with the new konstruct. There's the eunet server from NL, that not have the unstable version yet. I think it should be easy for the konstruct-constructors, to make sure of a alt-server or maybe event two alt-servers. That must be a easy change.

Cheers,

J

by Stefan Heimers (not verified)

When I tryed it, konstruct had the same problem. It sometimes tries different mirrors if you restart it, but it is boring to keep restarting it.

How about having it retry different mirrors automatically in the case of a failure?

by binner (not verified)

Just add more mirrors (or duplicate the download.kde.org entry) in kde.conf.mk.

by TomL (not verified)

I just run it this way

for i in $(range 1 1000)
do
make install
done

range is a bash function I have.

by Bertie (not verified)

> range is a bash function I have

which presumably does the same thing as `seq 1 1000`, a unix command everyone (?) has....

by TomL (not verified)

I guess I've had it for so long.

by theorz (not verified)

Wow!
10,000 bugs closed
2,000 user wishes processed
30 new applications

This release is shaping up to be amazing.

by John Allsup (not verified)

I'm not knocking the KDE people in any way, but...

1) 10,000 bugs closed means that there were at least 10,000 bugs to begin with.
One should wonder about the methodologies at work in the software production: the thinking, the planning, the workflow, etc. You should ask if the process behind the software can be improved so that, without too much loss in development time, these bugs can be prevented _before_ they happen, not fixed after they happen. Software development is one area where prevention certainly is better than cure. (But cure is better than nothing at all, and nothing at all is better than M$...)

2) 2,000 user wishes processed doesn't indicate how well the needs of the user were thought about to begin with. You could increase this figure in the short term by brainstorming for user wishes in advance, plus a little asking around, and then not implementing the wishes until they land in the 'user wish' inbox, at which point you wheel the feature out and count it as another 'user wish' processed.

3) 30 new applications. What is/isn't an application? What do they do?
Surely better KOffice (exceeding OOo everywhere), with a complete GIMP+Cinepaint equivalent (using the new KDE interface stuff... only 1 new application so far) and deeper framework inprovements would be better than the 'new application' count?

Whether the release is shaping up to be amazing has nothing much to do with the numbers, rather it has everything to do with what those numbers are referring to. Numbers can, and routinely are massaged, fiddled, adjusted, corrected, and forced to lie under various forms of torturous duress. Don't listen to numbers alone.

That, ladies and gentlement, concludes today's lecture.

by Hydralisk (not verified)

A "bug" in Bugzilla is not the same as a bug anywhere else. Conservatively, more than half of those bugs were enhancements, feature requests, TODOS, or duplicates.

by Mojo_risin (not verified)

"nearly 10,000 bugs closed"

I think the intention is good but gives the impression of too many bugs...
Like John said, is good to correct them but is better that they don't exist at all.

Moura

by George Staikos (not verified)

10000 bugs is only one bug for every ~400 lines of code. That's incredible in comparison to industry standards.

by katakombi (not verified)

once, i used to write so many lines of comments as well!

*looool*
katakombi >8^)

by Datschge (not verified)

It's actually even less per line of code since usually people compare all collected bugy reports to the current amount of lines, while they ignore the fact that a lot of rewrites/additions/removals predate the current number of lines. According to http://libresoft.dat.escet.urjc.es/cvsanal/kde-cvs/ the current amount of about 4 million lines has be reached through about 60 million lines (excluding websites and qt-copy) of added and rewritten code in the last 6 1/2 years.

by Chefren (not verified)

It was 1 bug per 400 lines *fixed* bugs, not total bugs. Who knows how many bugs are still lurking in all those lines of code. For a mature project like KDE which does not have to worry about strict deadlines, I'd say it's just about normal.

by Tom (not verified)

I think those numbers are simply interesting, in a strange sort of way. It just sounds impressive that 10,000 bugs have been processed; it gives an idea of the scale of the project. The announcement lists plenty of specific improvements and additions, and doubtless when 3.2 final comes out we will see several documents explaining it all in depth.

by a.c. (not verified)

John, I am guessing that you are a PM? Yes?

by John Allsup (not verified)

PM=?

Prime minister? Nope.... that'd be a B*****d control freak called Tony.

Pure Mathematician? Yes. (See e.g. my profile on slashdot.)
I tend to share my pedantry with the mathematical logicians, which is
understandable given my research area. (specifically, I'm a postgraduate student working in models of Peano Arithmetic.)

Other PM? please advise. (I've given up guessing.)

But yes: pure mathematics does tend to make you think about what numbers are, what they mean, and what they can also mean, given someone's intended meaning.
(Undergraduate statistics books quite often have explanations of various scams
that work effectively on the unwary...)

John.

by Ingo Klöcker (not verified)

I'm a pure mathematician, too. Furthermore I'm a KDE developer (KMail, to be precise), so I know exactly what those numbers mean with regard to KMail. We have loads of bug reports which are:
- duplicates of already reported bugs (cf. http://bugs.kde.org/duplicates.cgi)
- invalid, i.e. distribution specific bugs, user error, bugs in the libraries we use, etc.
- not reproducible (so it's not clear whether there's really a bug)
- missing features which are reported as bugs

Some numbers (bug counts for kmail since 2003-01-28, the day KDE 3.1 was released):
- total number of new bug reports (excluding wishes): 855
- total number of closed bug reports: 684
- closed as FIXED: 213
- closed as DUPLICATE: 170
- closed as WORKSFORME: 163
- closed as INVALID: 115
- closed as WONTFIX: 20
- closed as LATER: 3
- still open: 171

Some more numbers (bug counts for all of KDE since 2003-01-28):
- total number of new bug reports (excluding wishes): 9788
- total number of closed bug reports: 6866
- closed as FIXED: 3052
- closed as DUPLICATE: 1267
- closed as WORKSFORME: 1304
- closed as INVALID: 984
- closed as WONTFIX: 218
- closed as other: 41
- still open: 2922

by Aaron J. Seigo (not verified)

great numbers... maybe we should enlist you to write the pure math version of the release announcements ;-)

by Derek Kite (not verified)

The methodology goes as follows:

Developer works on feature, fix, cleanup, whatever.

Developer commits changes for review.

Other developers or users test changes, either email bugs or submit bug report.

Developer responds, fixes bugs.

rinse... repeat.

Sounds pretty good to me.

Derek

by John Allsup (not verified)

That's a very simplistic view.

Where is the deep, large-scale thinking as to how everything goes together?

Where is the end-user-pov thinking, looking not at particular features or whatever but on how they are going to use the UI as a whole to get done whatever they want to get done?

Before you even get to the point of working on features, the large scale thinking lets you prioritise things so that the important features are well planned (rather than hacked up out of comparatively spur of the moment interest)
and have far fewer bugs than average. Also, thinking about the workflow of the people doing the programming (this is a huge thing to think over in its entirety, and many books have been written on the various aspects of it,)
what procedures allow the amount of debugging/correction to be reduced?

Part of the problem of development is that, when it actually comes round to writing things, you have to do so a feature at a time (well, pretty much anyhow.) But thinking and planning things according to the features doesn't tend to produce the best results.

Consider building a car, starting with the best tyres you can afford, and that really cool supercharger your mate has in his hot-hatch. If you go along that road, you'll be lucky to end up with something that even works.

What you describe as the methodology is only really appropriate if you're working on an already planned out project, following the guide to what features are/aren't needed, where they go and what they do.

It is only recently IMO (i.e. post GNOME 2 and KDE 3) that the two main competing OSS desktops (GNOME and KDE) have really started to come around to this kind of thinking and planning.

John.

by Derek Kite (not verified)

Interesting perspective. I think you underestimate the work involved in the few lines that I used to describe the process.

There are two ways of going about this. One is to try to figure out the requirements, come up with an infrastructure design, hash out the implementation details for a few years, then start writing code from a spec. For a project like KDE, this is an impossibility. For one thing, how do you attract other developers except with working or almost working code?

The second way it to write it. Find what doesn't work, throw it out, rewrite it. Repeat. 7 years later you have a mature and stable desktop, with few bugs. Actually, you have about 3 versions of a stable workable desktop. There are a few core developers that are still around, but many have come, contributed, then moved on. User interface stuff is details, getting basic functionality is the bulk of the work. A few months ago there was a lengthy discussion here about configuration, how complicated etc. it is. Someone banged out a 4 or 5 liner that produced a simple narrowly focussed configuration dialog, that worked. Literally. To say there isn't a good solidly designed infrastructure behind that is plain ignorance. That is one example. Khtml was written, the rewritten. Features, as in capabilities to view web pages built with unusual technology, are added to the basic engine. There is a design, a good design according to the apple people, that is extensible. Another example is the intercommunication mechanism. At one time KDE used CORBA, but it was found to be too slow and heavy for the purpose. So based on what they learned, they designed a new one, and wrote it in rather short order.

I would say the second way comes up with better real world design. I work in a construction related industry, and know the value of design and specifications. But it is a very different industry dealing with very different constraints. First, you can't build, throw out and rebuild. Actually you can, but progress takes generations. Second, very seldom does anything new come along, I mean really new and unprecedented. Most technologies I deal with have been around since the 16th and 17th century, at least in someone's mind. The new stuff is new / faster / cheaper ways of doing the same thing. With software, this is not at all the case. Some of what the KDE folks have done is different than anything anybody else has done. It is truly new ground. How does one formally design that, other than writing it and seeing how it works? And throwing it away if it doesn't? Or letting someone else look at it to improve or trash it?

Derek

by Datschge (not verified)

Dear John,
before you continue rambling about how software development should work in your opinion I'd like to make you aware that in the last 7 years KDE's development model transparently grew without any big break, without any kind of top down rules/rulers. Of course there *is* a development model as well as a grown community culture. For an introduction to those I suggest you to read http://www.kde.org/whatiskde/devmodel.php as well as the other related pages in that section. If after reading those you think we are doing it totally wrongly anyway I suggest you to look for other projects which fit better to you and may listen to your suggestions.

Thank you.
Respectfully, Datschge

by Aaron J. Seigo (not verified)

well put Datschge! if something works really well and is a huge success, you shouldn't come along and say it doesn't work; if its churning out good product, efforts are better put to enhancing the mechanism rather than trying to turn the boat around for no reason at all.

by Tim Gollnik (not verified)

So, you shouldn't work. Nature proves best that this IS a possible way. Sometimes it's better if someone comes along with a vision or so, i agree. But there ARE contributors with such visions. See how Bernd Gehrmann started with a new kdevelop (gideon), and now it's the one kdevelop none of us can wait for..

So where is the problem?

Best wishes

Tim

by James Richard Tyrer (not verified)

I don't think that it works that way.

AND, that is why it isn't working.

But, perhaps I should see if my latest bug report *actually* is fixed in 3.2 before I go into this in detail.

--
JRT

by Aaron J. Seigo (not verified)

first off, that isn't 10,000 unique bugs but 10,000 bug reports. some of those were undoubtedly duplicates, some of those were against development versions that were never in production releases. however, many were against older versions. seeing as there's nearly 4 million LOC and people like to report every fiddly little bug they come across, i think that's not too bad at all. perhaps you like to show us your million+ LOC complex multi-program GUI project that's been over with a fine tooth comb by thousands as a comparison?

with regard to user wishes, you are exactly right in that it doesn't say anything about the final outcome of those wishes. some were duplicates, some were denied. still, many were implemented. how many? i don't know for sure since i haven't counted them (anyone know how to get bugzilla to spit out such a report?). at the same time, it's almost irrelevant. what IS relevant is that these reports from users get read, considered and dealth with. that means there is a real user->developer communication going on.

as for your "sand-bagging the user wishes" conspiracy theory, believe me when i say that those in the KDE project have better things to do with our time. honestly. most of us get our enjoyment from writing code, not dicking with statistics.

you asked what is and isn't an application. here's a short list of new apps and components in 3.2: juk, devices applet (kicker), universal sidebar (kicker extension), khotkeys2, kdialog, ksplash(ml), kwallet, kmag, kmousetool, mouth, Konqi Mozila-like web sidebar, vimpart, plastik, Kig, KBruch, KGoldrunner, kopete, kontact, kcachegrind, umbrello, kgpg, kdelirc, kpdf, quanta's kommander, Kicker menubar applet, fsview, kcmrandr + systemtray tool, kcmuserinfo, kcmgamma, konq-plugins/auto-refresh, konq-plugins/crash, kuiviewer/ui thumbnails, kwifimanager, ksvg, a couple of new trivial ioslaves, libkcddb .... i'll bet i've even missed one or two in that list still.

but remember, this is a beta announcement. wait for the final release announcement for more detailed coverage of the whole thing.

and btw, KOffice has gotten better (though it isn't counted in the KDE Desktop release) and in some places does exceed OOo. look up the word "maturing".

as for the GIMP+Cinepaint equiv you mention, hey, great, you've found a place KDE doesn't have a better app. to which i'd say where's Scribus, the K3B, KStars, or the KSVG? and just wait as apps like Kexi get into shape. i could go on, but i think you get the point, which is that both sides have holes in their application coverage. and without taking anything away from the great efforts made by the Gtk+/GNOME folks, i can confidently and honestly say that KDE is filling its application gaps at a terrific pace.

you are also right that the KDE 3.2 release has everything to do with what the numbers are refering to rather than the numbers themselves. you seemed to question whether the numbers actually referred to anything, however; let me assure you they do.

but most people don't have great attention spans, and most people don't like to read. knowing that, one of the things to remember when writing announcments and other such PR bits is that while one wants to offer substance, you can only offer so much before it becomes wasted, and even retrograde, effort. ergo the shorthand and trotting out, hopefully impressive, summary concepts and numbers.

of course, if you show me factual errors in the piece, i'll be happy to correct them. as it is, i stand by everything in that article.

by Aaron J. Seigo (not verified)

gah.. i really ought to Preview rather than just add ;-)

when i said "to which i'd say where's Scribus, the K3B, KStars, or the KSVG?" i of course meant "to which i'd say where's the Scribus, K3B, KStars, or KSVG apps for Gtk+/GNOME?"

by Eric Laffoon (not verified)

> as for the GIMP+Cinepaint equiv you mention, hey, great, you've found a place KDE doesn't have a better app.

However it does appear that there is once again work on paint apps as well as Krita so these holes could become more a matter of choice of apps. Not having the Gimp's hideous UI for editing several files is such a big plus for me I'd live with less features. I mean when your picklist display is limited by your screen resolution and you can't find anything without the taskbar you're talking UI from hell.

> i'll bet i've even missed one or two in that list still

Yes, in the Quanta module there are kxsldbg and KFileReplace. KFileReplace is just included as a kpart plugin at this time but it shows up on konqueror toolbars and is the coolest multi file find and replace ever.

by Josep (not verified)

> Yes, in the Quanta module there are kxsldbg and KFileReplace. KFileReplace is just included as a kpart plugin at this time but it shows up on konqueror toolbars and is the coolest multi file find and replace ever.

Are there any way to remove the kfilereplace icon on the Konqueror toolbar, without removing the other two listview icons?
Don't get me wrong I like it on Quanta.

by Andras Mantia (not verified)

I don't know how can you do this. It seems that Konqueror puts every KPArt that handled inode/directory on the toolbar. Cervisia is also there if you have kdesdk installed. Ask it on kde-devel or some other mailing list and if nobody know you should fill a wish item for kdelibs or Konqueror. I'm not sure which one is the best.

Andras

by Eric Laffoon (not verified)

Yeah I was actually a little surprised to see this myself when I opened konqueror after installing it. Then again I'm not sure how I feel about Cervisia being there as I usually use the application or as a plugin in Quanta. My personal preference would be to complete the upgrades to the stand alone app for KFileReplace, but for now we will see what the options for the toolbar are at this time.

by Melchior FRANZ (not verified)

> i'll bet i've even missed one or two in that list still

Yes. I'm quite upset that you didn't mention kclock.kss!

m. ;-)

by Aaron J. Seigo (not verified)

/me quickly adds that to the list

no. seriously. and the binary clock, speaking of clocks.

by anonon (not verified)

> I'm quite upset that you didn't mention kclock.kss!

Yes! It immediately became my default screensaver! :)

I might have missed KDevelop3 in that list, which is the first official release of an app that has been in the making for years.

by Datschge (not verified)

with regard to user wishes, you are exactly right in that it doesn't say anything about the final outcome of those wishes. some were duplicates, some were denied. still, many were implemented. how many? i don't know for sure since i haven't counted them (anyone know how to get bugzilla to spit out such a report?).

----

*cough* Coolo asked me to add statistic scripts like this in vein of like the existing "weekly summary" and "old bug" reports. I'm kinda late, but promise that I'll work on it.

by John Allsup (not verified)

I'll give a long answer to this. It will probably produce more questions+retorts than
answers, but here goes.

I stated quite clearly at the start of my previous comment.
I AM NOT KNOCKING KDE IN ANY WAY. I am not. (Not much anyway.)
(You seem to be reacting as if I were.)

The original point was intended to stress that the numbers (namely the 10000, 2000 and 30) aren't that important, and those that are impressed by the numbers should try not to be. Instinctively, when faced with things like '90% fat free' and 'and amazing 1000 combinations', one should ask what these numbers are talking about. Don't listen to the numbers all that hard.

In the particular case of the numbers in the comment I replied to, it is certainly not the case that more=better. Neither is it the case that less=better. All that can be judged from the numbers is a rough amount of effort, and even then you need to be familiar with what the terms 'bug', 'user wish' and 'application' mean here.

My response to the parent comment was mainly aimed at the 'Wow! look at the big numbers' aspect, it was certainly NOT aimed at the actual article. I read the article, was impressed by what KDE had achieved with the current pre-release, but saw someone spouting numbers and thought 'here we go again... I'll just throw something back at the statistics this time.' Maybe I was falling for a troll, but I don't think the original comment was one.

> as for your "sand-bagging the user wishes" conspiracy theory, believe me
> when i say that those in the KDE project have better things to do with our
> time. honestly. most of us get our enjoyment from writing code, not dicking
> with statistics.
Did I suggest such a conspiracy theory? I apologise for doing so if I did: that was not the intention. (It was a knee-jerk reaction to yet more empty statistics.) The point about an artificial way of increasing the 'use wishes' count was intended as a reasonably direct counterpoint to the 'more the merrier' attitude to the numbers. Again, the numbers themselves don't say that much.

Personally, I think it's better to say 'this, that, the other, and approx. x many other user wishes accounted for' rather than 'x user wishes accounted for.' This is more informative and places less emphasis on the numbers.

As to the what is/isn't an application:
The easy way to answer this question is: 'One pile of code with a name=one application.' I'll offer an alternative view, taking the list in your comment.

In short, applications are things like Photoshop, GIMP, OpenOffice Writer, etc.
Kicker, Konqueror, etc. are features of the environment (i.e. what you have before you run any applications.) A possibly controversial view, but I do not consider Konqueror to be an application, but an integral part of the underlying environment.

Applets are applets: they are generally little gizmos that get something done, but are auxiliary to the main purpose at hand (whatever it is you are doing at your desktop.) Personally, I consider things like WinAmp and friends to be applets: you have them lying around making life a little easier, but you don't _work_ in them. You do work inside something like Quanta or KSpread.
(If you are wondering where I'm coming from, this point of view starts from the dumb-user end of things, looks at what they are trying to accomplish, and thinks things from there.)

Note that when I say 'framework', this is to be thought to be everything available (from KDE) to the developer as a tool to get the UI to do something for the user. Possibly 'environment infrastructure' would be a better term.

* kwallet: should this be considered an application, or as an applet frontend to something (namely the functionality it provides) that should be and should be considered to be an integral part of the KDE framework. I have thought for a long time that authentication management should be intimately intertwined with a framework such as KDE's. My first meeting with it was when I saw the capability model of security (where there was fine grained, abstract authentication management, such that the authority to do something could be sent around in a controlled way.) Right now I think it's an application, but longer term it should not be.

*juk: Again, this is an application. Much of the functionality it provides, however, should not lie in the application. Longer term, the ability to do things like keeping track of MP3's, forming playlists and such should be a feature of the underlying filesystem abstraction in the framework. I'll not
elaborate on this very much here: I'll think this through a little better, read through the other stuff on storage frameworks + the obligatory how BeOS did it, and stick something in my blog.

That said, much of what juk provides as an application should be a trivial thing
to build on top of the underlying framework. It is not at the moment, and hopefully that will change in the future.

*devices applet (kicker): clearly this is an applet. I consider applets not to be applications (and I consider many applications to be applets in disguise... my view: others may or may not share it.)

*universal sidebar (kicker extension): As I see it, kicker is part of the environment, and this is an extension to it. (As you might guess by now, I do not consider plugins to be applications per se.)

*khotkeys2, kdialog, ksplash(ml): part of the framework.

*kmag: desktop gizmo. You do not do work within kmag: it's something to help you when working within some applications.

*as for kmousetool, mouth, Konqi Mozilla-like web sidebar, vimpart, etc. you should get the picture.

Of the things you listed, I consider Kig and Kbuch to be applications, though whether they should be amalgamated into a larger, more general 'KDE Maths Education Assistant' is another question. KGoldrunner is a game (not IMO an application.) I'll count Kopete as an application, but again it should really considered part of the underlying environment. Kontact is an application.
Kcachegrind is certainly an application, as is umbrello. So far as new applications, according to my definition I count about 10 or 11 out of your list. (Again, I am not forcing this view on anyone, just offering an IMO important alternative view to what applications are and how to count them.)

I like to view the application count as a rough indicator as to how much useful stuff there is for getting work done. (So 'three applications' means things like
'KWord, KSpread and Quanta', not things like 'Kicker, Konqueror and KWallet')

The point is that the actual number of applications according to the 'pile-of-code+name=application' definition is not in itself an indicator of much except maybe effort. In many ways, if the same amount of stuff was done by fewer applications, and instead by enriching the framework, the result would be better (and possibly less confusing for the casual end user.)

> KOffice has gotten better (though it isn't counted in the KDE Desktop release)
> and in some places does exceed OOo. look up the word "maturing".
I'm familiar with the word maturing. KOffice has come a long way, and has a long way to go. There isn't an office suite that doesn't.

> as for the GIMP+Cinepaint equiv you mention, hey, great, you've found a place
> KDE doesn't have a better app.
And also a place where, if proper thought is given, KDE can do a better job (as an application.) Between GIMP and Cinepaint, they do a good job of managing the image data. Getting that image management/manipulation/high-performance-display aspect abstracted into an efficient 'engine' so that a nice KDE appliation can be written around it is probably the best way to do things from the KDE point of view.
(I know little about the state of the art with GIMP's development, so I don't know how much or how little GIMP's image manipulation engine is coupled to the UI. Hopefully not that much.)

>to which i'd say where's Scribus
Technically a Qt application last time I looked.

>K3B
I agree that this looks good.

> or the KSVG?
An important and well needed part of the framework.

> and just wait as apps like Kexi get into shape.
The caveat is that, as with all 'just wait for' things, you don't know what you'll get, you don't know whether or not the developers will get bored/fall out/etc. There are, and have been many 'just wait for' things in the long history of free software that haven't come to anything. I sincerely hope Kexi is not one of those. Database frontends tend to be important and useful these days.

> i could go on, but i think you get the point,
So could I. I tend to enjoy a good, reasonably informed and heated discussion, with sufficiently different points of view that the talking doesn't just amount to 'preaching to the converted.'

> which is that both sides have holes in their application coverage.
You tend to suggest that there are two sides: surely there are many more (and many more even than that...)

> ...by the Gtk+/GNOME folks
I'm not here to start up a KDE vs. GNOME holy war. (Please don't think that that is my intention: it is not.)

>I can confidently and honestly say that KDE is filling its application gaps
> at a terrific pace.
But 'filling application gaps' is not the be-all and end-all of producing a good UI environment. Surely it is better to do what you do very well at the expense of a few holes?

> you are also right that the KDE 3.2 release has everything to do with what the > numbers are referring to rather than the numbers themselves.
Yes. That was the main point. The rest was a surrounding discussion (which I thought better to include than a tired quote such as 'there are lies...statistics.')

> you seemed to question whether the numbers actually referred to anything,
> however;
More accurately, I questioned how much meaning the numbers can actually have, giving a few examples as to how they can be misleading or inaccurate depending on how they are calculated and how people read them. Many replies gave further weight to the fact that they can be easily misread and misunderstood. This misunderstanding is why I tend to question the numbers and try to look straight past them.

> let me assure you they do. But most people don't have great attention spans,
> and most people don't like to read. Knowing that, one of the things to
> remember when writing announcements and other such PR bits is that while one
> wants to offer substance, you can only offer so much before it becomes wasted,
> and even retrograde, effort. ergo the shorthand and trotting out, hopefully
>impressive, summary concepts and numbers.
That is a problem. It can be a big problem. Salesmen tend to love using numbers to confuse people for this very reason (they take the numbers and don't have the attention span, motivation or whatever-else to think things through.) I guess there's an art to writing announcements that are deliberately informative (and aim for the minimum confusion) just as there is a whole industry based around doing quite the opposite!

Finally, I am not questioning any factual errors in the piece. I never was: I just don't consider the raw statistics to be very meaningful.

John.

by Ingo Klöcker (not verified)

Konqueror is no application? But I guess Mozilla and Opera are. Where's the difference? Just because Konqueror is more integrated with the rest of KDE it doesn't count as application? Is KDE (whatever that is) an application?

Anyway, as pure mathematician I won't dispute your definition for "application", even if you are pretty much alone with it.

by John Allsup (not verified)

It's an iffy one. In its web browser mode, it quite possibly is. In its file manager mode, it should be considered as part of the underlying environment.
It depends what you see as being built on what. Basically, if you chop the KDE things into those bits that are 'built in' or at least appear to be 'built in' and those that are not, which side of the fence does Konqueror fall on? (Note that I would say that M$IE appears to be a 'built in' part of the Windows user environment, ignoring the question of whether it actually is.)

Would you consider Konqueror as being built in to KDE? I would, and for my mind that disqualifies it from being called an application. (Equally, I would not call M$IE an application, so much as part of the user environment, which being (at least so far as appearances are concerned) integrated into the Explorer, it very much is.)

Any good desktop UI environment will have something that manages files and is considered part of the desktop environment. e.g. the Finder on MacOS, explorer on Windows, and the default file manager applications. People expect these things to just 'be there', and they are. For example, if you start with an empty KDE desktop and open a file window, do you consider yourself having opened any applications? In this context I would say no. The only bit that picks it out as an application is when it is used as a browser, but even then one would consider Konqueror to be KDE's built in browser.

That said, I think the word 'application' is heavily overused. There needs to be a terms for many things, and whether you split things up based on technical definitions (e.g. a KDE application is a program involving a class that extends KApplication) or UI-point-of-view centric ideas (such as a KDE application is a program above and beyond the basic environment that is designed to do some kind of task.) Ok: this is not a good attempt at a qualitative definition, but you get the point. Think first about how someone who knows nothing about how everything is put together will think about it. That is the intuitive idea of what's what, and it makes a lot of sense to keep coming back to it when it comes to explaining things. (This will make things easier when it comes to getting inexperienced people into using KDE: the terminology will make far more 'intuitive' sense far earlier on, and subsequent discussion may be less confusing.)

In any case, the point of view as I put it across was a little extreme in the 'this isn't an application' direction, but I thought it necessary to counterbalance the 'a kicker extension is an application' sort of thinking in the comment I was replying to.

As to Mozilla and Opera: I would consider them applications. They tend to be all enclosing environments dedicated to a particular collection of tasks (i.e those involving using the internet.)

I guess I'll have to think through my point of view of what's what, and try and put it down in writing. It does make a lot of sense, honest, it just requires a little unlearning. That said, part of it involves effectively having one set of definitions for the user point of view and another for the developer point of view. Setting things down in a way that avoids ambiguity is something I've yet to do.

p.s. I also noticed why the 'Quality not quantity' title didn't appear--silly old me stuck it in the email box. Damn, I'm getting old.

John.

by John Allsup (not verified)

A slightly easier way of looking at my perspective on 'what is/isn't an application.'

Consider a mac user who doesn't care about technical definitions or implementation deatils. (We'll assume that its an old one that still
has something called a floppy drive.)
[He sits down at his computer, the desktop is 'empty' except for the usual icons and stuff.]
YOU: Do you have any applications open?
USER: No. I haven't opened anything yet.
[He sticks a floppy in with his work on and 'opens the floppy' by double clicking on the floppy icon.]
YOU: Do you have any applications open?
USER: No. I'm just getting around to that... I've got my work here, and
I'm going to open it up in X
(here X represents his favourite application, e.g. Word, Photoshop, Quark)
YOU: But really, that folder window is an application: it's called the Finder.
USER: Huh? Well, if you say so. But isn't it just my floppy disk with my files on?
YOU try to explain the details to USER. USER gets confused.
USER: Well, personally, I don't care. Applications are things that I
open my documents in. Folder windows are, well, just folders. They're
not application.

[Another time, another user, this time you don't try to confuse them by explaining what the finder really is. He sits down at his computer, the desktop is 'empty' except for the usual icons and stuff.]
YOU: Do you have any applications open?
USER: No. I haven't opened anything yet.
[He sticks a floppy in with his work on and 'opens the floppy' by double clicking on the floppy icon.]
YOU: Do you have any applications open?
USER: No. I'm just getting around to that... I've got my work here, and
I'm going to open it up in X
(here X represents his favourite application, e.g. Word, Photoshop, Quark)
[USER double clicks on the Word document. Microsoft Word opens and the document is displayed on the screen.]
YOU: Do you have any applications open now?
USER: Yes, obviously (feeling patronised.) I've got Word out with my document, see.
YOU: I see.
[USER now double clicks the Excel spreadsheet. Microsoft Excel opens and the document is displayed on the screen.]
YOU: So, which applications do you have open now?
USER: Word and Excel.

Note that the typical user will NOT consider things like the Finder to be an application. (And most Windows users didn't/don't realise that the taskbar, folder windows and now web browser are all part of the (Internet) Explorer 'application'.)

Where the boundary gets a little iffy is things like Windows' integrated IE and KDE's integrated browser. Now consider the 'casual user' sitting down at KDE. Like the previous mac user, he/she does not care about technical details or implementation details, only getting his/her work done.
[He sits down at his computer, the desktop is 'empty' except for the usual icons and stuff, including the KDE bar at the bottom.]
YOU: Do you have any applications open?
USER: No. I haven't opened anything yet.
[He sticks a Zip disk in with his work on and 'opens the disk' by double clicking on the mount zip disk icon.]
YOU: Do you have any applications open?
USER: No. I'm just getting around to that... I've got my work here, and
I'm going to open it up in X.
(here X represents his favourite application, e.g. Word, Photoshop, Quark)
YOU: But really, that folder window is an application: it's called Konquror: you can see its name on the title bar.
USER: Huh? Well, if you say so. But isn't it just my zip disk with my files on? Why does it need to be called Konqueror: isn't just a window with my files in?
YOU: Ok, I agree, it's just a file window. But see that address bar, try typing in the URL for a website in.
USER: He types in 'www.google.com' and google appears.
YOU: Now, do you have any applications open?
USER: I'm not sure. It's sort of like a browser now. Is it an application now that it's a browser, or is this what you meant when you said it's an application before? It's an application that sort of disguises itself as the built in file manager when its not doing any web browsing. But if that's the case, where are the 'built in' folder windows? Are there any?
YOU: (now also confused) Well, Konqueror sort of IS the built in file manager, but it's also the web browser application...
USER: (still confused) I give up. Can I get on with my work now?

You see how it goes. It makes a lot of sense to go back to the basic intuitive view of how people see and expect computers to work, document that and work with it rather than against it (whilst learning is important, making it that little bit more effortless to understand what's going on can surely help most users, whether technically minded or not).

As such, there are two points of view: the 'enlightened' technical users' point of view, where they know what sort of programs need to be running in order for things to appear like an 'empty' intuitive desktop environment. There is also the view of the 'naive' user who just sits down and clicks on what they want, not being interested in how the computer really works, only that it does. They will see things differently. Personally, I think the 'naive' view is a better one in this case, since it is easier to get a good picture in your mind of what should be going on, without getting clouded by implementation details. (My view: others may not share it.)

Thanks everybody for the discussion, I suspect this thread has long since passed the point of being labelled a 'troll fest' in everybody's minds, which was never the intention.

John.

You know your artifical case you build around Konqueror is actually exactly the same with Explorer under Windows.

That being said you indirectly got a point, even though I'm very sure you aren't aware of that: the term 'application' and all related terms (take 'quit' for example) are way too abtract and technical for being included a usable desktop referring to metaphors. KDE already has been moving to a more task oriented (versus application centric) metaphor in the past, I'm sure this will continue and be intensified after the release KDE 3.2, hopefully also getting rid of the remaining inconsistencies.

(The problem that commercial desktop will prefer application centrism due to marketing reasons will probable lead to KDE promotion 'incorrectly' keeping referring to 'applications' since this sadly is the only way branding really works nowadays. See http://www.newsforge.com/software/03/11/05/146225.shtml for a nice article about exactly this topic.)

by Datschge (not verified)

You know you are splitting hairs here, way too many hairs actually.

You talk about applications, applets and shells as if it makes a difference to the end user whether Konqueror is one of those. (Btw. Konqueror is technically a shell for the KPart framework, but I don't see any user caring about that.) Where this does matter is the development, being able to share as much code as possible allows developers to save time, stream line their applications, focus on their purposes, and all that while not having to reinvent every little wheel and even keep consistency with all other appplications in that desktop environment, that's the purpose K desktop environment exist for after all. You could come and say KDE has no single applications, it's all libraries and other shared stuff, and all applications users are using are actually only shells. And you know what, I actually think such a state would be the ideal case for KDE.

And don't come with an excuse that your only point was showing that statistics are worthless, everyone knows that, but you still took the time to churn up a lot of arguments unrelated to that point.

by Aaron J. Seigo (not verified)

> I like to view the application count as a rough indicator as to
> how much useful stuff there is for getting work done.

and then you discount 2/3rds of the useful stuff as not being applications, as if somehow that makes them less interesting because they are stand alone apps. i *could* be pedantic in my writing and label exactly what each thing is (apps / applets / kparts / libraries), but how would that be useful besides to make the announcements even longer (not a good thing ;). when i mentioned you should wait for the final release announcement for more details, i meant it.

in particular your distinction between "underlying environment" and "application" is pretty irrelevant when trying to communicate the delta between this release and the last one to a general audience, which was the point of the announcement. you are correct that enriching the underlying environment can be a better option over stand alone apps, and as you noted many of the new items in 3.2 do exactly that (from KWallet to KHotKeys to libkcddb to....). i think what you say about emphasis on framework, results not just efforts, etc align with the technical reality that is KDE. but most people (e.g. the target audience for this article) don't have the technical background to understand those shades-of-grey(-but-important) differences. when i've got my writer's hat on, i try to write to a specific audience, and this time it isn't you or me, but the average KDE user =)

imagine if KDE actually spoke to the masses in a language they understood and enjoyed.

by Eric Laffoon (not verified)

I've always enjoyed your writing Aaron. However after a few talkbacks your responses start to look like a really long compile string. Reading this reminds me something... Didn't we get to be friends over an argument we had on the Dot? It's good not to be the only hot blooded guy in KDE. Keep up the good fight man. ;-)

by Aaron J. Seigo (not verified)

haha.. yeah, i suck at talkbacks. my informal writing is usually way too verbose and expository of my internal modes of thought to be generally useful =) i also forget to use light-hearted words and phrases and come off sounding amazingly serious.

video would be way better, as i'm a far better speaker than i am a conversational writer.

btw, the new Quanta smokes... yum yum!

by Eric Laffoon (not verified)

> haha.. yeah, i suck at talkbacks. my informal writing is usually way too verbose and ...

Yeah man, whatever dude. ;-) Hey I really do love your writing though. I remember a Linux magazine article where I suddenly experienced a rush of excitement as I realized it wasn't just warmed over newbie fluff, but there were things I didn't know about KDE... Who was this guy... Aha! Nice work!

> video would be way better, as i'm a far better speaker than i am a conversational writer.

And in person would be even better as I'm trying to stay away from video beer.

> btw, the new Quanta smokes... yum yum!

Thanks! That's high praise indeed. Best of all we're just getting up a head of steam. I'm already dreaming about what 3.3/4.0 will look like. ;-)

by Debian User (not verified)

Hi,

let me compliment you for your obvious intelligence. It's a refreshing read.

This is not ironic, but: You being a mathematican and probably even native English speaker is a good excuse for declaring applet and application two different things. It is in the style of people who love to be right.

KDE is a framework. As such many of its apps are services as well as stand-alone applications. Your judgement by the GUI can be best demonstrated by asking you what Apache is. An applet or an application. Last time I thought of it, that was a application, but you are free to define as you like. For communication it's more practical to agree on definitions though.

As to the numbers. Why do you imply that everybody is unaware of how the process of development of KDE works. Most people here know what bug reports are, what wishes mean and so on. Most people here are even part of the process. We enjoy the numbers, because we know what they mean.

Your implication of absence of planning and design is insulting to those who did. The examples were listed. It's no doubt that e.g. Linux 0.1 was really really bad design. To some it seems now it has the best design of all.

I assume you fail to understand how you need bad code to attract people willing to improve it. Development of software is a social process not a mathematical. Esp. with Free Software. It may be true that a lot of individual time is wasted. But that's only so to explore all possibilties. What you demand to happen has an example: GNU Hurd. It took many years to design and probably already next year, it may support virtual memory or filesystems larger than 1G.

GNU Hurd is one of the best planned products and a complete failure compared to Linux that just happened to become nearly useful.

Think about it and share your opinion with me. This bit about intelligence was really not ironic. :-)

Yours, Kay