After some debate last week over whether KDE 2.2 HEAD BRANCH
was ready for a stable release,Waldo Bastian, the KDE 2.2
release coordinator, hasposted
a revised release schedule (also available if you Read More).
The release has been delayed two weeks from Monday, July 16 to August 6.
Though KDE excels at sticking to published release schedules, it seems
to me that stability and security are the developers' primary concerns.And That's A Good ThingTM.

This is to keep you up to date with the status of the KDE 2.2 release. I have
added a bit more time in the schedule in order to fix security problems that
exist with our use of https at the moment. I hope that everyone else can use
this time to do some additional bugfixing. Please be very carefull and send
patches of your changes to a mailinglist for review first. *)

> The number of minutes it takes me to get KWord or KPresenter (Koffice 1.1 Beta 3) to krash is still less then 3 withuot particularly heavy testing :-<.

Hmm? That's not at all my experience. I'm running KDE 2.2 beta from CVS on a two heavily modified Mandrake 7.2 systems and have installed it from RPM on a new Mandrake 8.0 system with 2.2 beta installed from RPM. Both systems are running the new koffice beta, one from cvs and one from RPM. I have not seen any crashes.

What I have seen is absolutely terrible printing! I did a beautiful four page presentation in kword and it took about 20 tries massaging the layout to finally get it to produce a printed copy that did not clip the end of lines. I had to finally insert hard returns in a few places. It's really great until you get to that glaring problem. Aside from that kword is not spectacular but very good for most use and exceptional in a few areas.

One other thing is that it seems to limit my font selection. I hope they fix the printing and keep on with the rest.

BTW you must have something wrong with your install to have kword croaking like that.

Actually I've had a beta 3 build of KWord break on documents with tables that span multiple pages. It seems to work great on simpler documents. What would be nice is if the import filter could bet setup to log the document load process that way we could tell which MS Word feature broke KWord. The entire office suite is comming along nicely, kudos to the programmers.

Very cool. What I can do is replace the text of the document (it's my resume :) with random garbage and post it to bugs if it's still causing problems with the CVS copy. Off to to compile a fresh batch of code.

Hmmm... You could write a small "garbling" script and put it in "Help" maybe, alongside bug reporting. The script would change all letters to "a" (or a random one), and all numbers to "0" (or a random one).

Then no-one would have a reason not to give you the document, and you would have no reason not to ask for one. You could even add a "Submit garbled document" checkbox in the bug reporting tool to boot.

It should be a fairly similar schedual, but they are "unlinked" to allow either to be delayed without holding up the other. If KDE gets delayed too much, then obviously KOffice won't work without the last betas. If KOffice gets held up, then KDE gets released with no problem.

Uhm? You have to install a "locolor" _theme_ to get _some_ locolor icons!? I think that's not acceptable! I hardly believe an admin can tell _any_ user of his Solaris network that he has to activate a special theme when new KDE becomes default (under this circumstances I believe it will never become it).

And there are many many icons missing. In K-menu (Development, Office, Toys, Word-Processing, Game-Submenus), application icons (e.g. Kate), all new entries of control center, KWord lacks half of it's icons. I stop here to summarize.

Better think of an automated process which regularly locates and creates all missing locolor-icons by dithering and installs them under $KDEDIR/share/icons/locolor/ .

> Actually KDE should switch automatically to the locolor-icontheme if it is available just the same way KDE 2.1 did.

KDE 2.1 did this!? I tested switching to an 8bpp display with an existing and a new KDE user: Both times KDE 2.2 did NOT install [a part of (the icons)] the existing "LoColor" KThemeMgr theme. I think you are confusing something:

All my KDE 2.1 installations don't contain a "Locolor.ktheme"-file. The locolor icons are installed in $KDEDIR/share/icons/locolor as fallback for the IconLoader. There is no kthememgr theme installed which would copy the icons to ~/.kde/share/icons/locolor (robbing the users' quotas). Please change kdeartwork's Makefile to install the icons in $KDEDIR/share/icons/locolor rather than creating a ktheme-file which has to be installed manually!

> Well in that case dithering the remaining hicolor-icons on the fly is certainly the betters olution.

Great! I noticed today that linking the 'locolor' dir to the 'hicolor' dir will do the same trick inclusive dithering.

But there is a bug: If you install the locolor-icon theme it stops working! I would expect it to search first user's locolor-icons followed by system-wide locolor-icons and last dithering system-wide highcolor-icons.

>> If you install the locolor-icon theme it stops working!
> In what sense ?

In the locolor-icon theme missing icons are not dithered anymore. As soon as I apply it e.g. the Kate icon in Kicker changes to "unknown" icon. After "dcop kicker restart" e.g. the icons of the game-submenus changed to "unknown" icon too.

> You seem to be still using hicolor as your icon theme. Go to KControl->Look&Feel->Icons and select locolor as your icon theme.

> In the locolor-icon theme missing icons are not dithered anymore. As soon as I apply it e.g.
> the Kate icon in Kicker changes to "unknown" icon. After "dcop kicker restart" e.g. the icons
> of the game-submenus changed to "unknown" icon too.

The trouble with GAIM is not the name, but rather the network. AIM is a proprietary network. KDE includes an AIM client, called Kit. It _could_ be renamed to Kim, but the problem of the proprietary network is still there.

I think if KDE is going to include any sort of IM program, it should be a Jabber client. Jabber is the open-source decentralized IM system (see jabber.org for more info, or jabbercentral.com for clients).

I would suggest including the client I'm working on, Psi, but it requires Qt3. Konverse would be a better choice, since it is a KDE program. Maybe it should be included in the KDE distribution? If it doesn't replace Kit, it should at least be there alongside it. This would be a great promotion of Jabber as well. Unfortunately, Konverse (and Psi, for that matter) are not in fully usable states. But that will change for sure.

I'm sure many people with modem connections will like the new kwm behavior where windows are placed on the desktop where it was launched. Now someone can switch to a new desktop, start conqueror, and switch back to the window they were working in. Then in a few seconds their window should be ready with their homepage. I'll just like the fact that it's the behavior that I expect, since I have a fast computer and a fast network connection :-)

I know this is just a minor improvement, but there are ones all over that will greatly improve KDE. There are all kinds of reasons why KDE is my favorite interface.

As for major improvements, Kooka and KDEPrint are most exciting to me. I hope those working on the KOffice project get WYSIWYG improved soon. Scanning and printing are particularly important to the desktop user, and I look forward to being able to do digital photography easily with KDE.

It is amazing how much progress has been made with KDE. There are so many ease of use, performance, and stability reasons to use it over Windows or Mac OS X, not to mention the sharing of software makes for a better society.

Seeing as how there's already a couple of folks asking about KOffice, I've got a similar kind of status request. Anybody know what all is going on with Quanta? Last I looked in the CVS, nothing has been updated for over 2 months. No updates on the SourceForge page either.

Is the project dead? As I recall, last major KDE release the developers of Quanta spent a healthy amount of time working on KDE 2.0. Is that the case this time as well, or should I just give up on hoping for a high quality HTML/PHP editor for KDE?

I saw some discussion about this on the core-devel list, they where planning to put Quanta on the next release of kde (2.3 or 3.0 whathever).
The authors seem to be occupied with their work, but will restart programming soon (ok, ok, soon is relative, it can be today or next month, I don't know, sorry).

This may sound like a flame, but it is just a little glimpse of reality.

One thing that would really help is if they were to actually TEST the system. I am still running KDE 2.1, but I wish I were back at 1.1.2, at least that never crashed, and I don't push KDE any more now than I did then, and it is still very slow and unstable. Word of advice to you KDE developers, TEST THE ENVIRONMENT UNTIL IT BREAKS, THEN TEST IT SOME MORE!!!! KDE is getting so bad, it is sinking almost to the level of Winblows. I am a developer, and I want speed and power, I don't care about DCop, which just bogs down the system. I took one look at the ps -awx output and nearly went insane, the kdeinit fork for dcop is (VSZ)13 MEGS!!!! Now where the hell did they go from 100k in the benchmarks to 13MB in the practice? And I thought the session manager was supposed to stay out of the way, how does that take up 13 MB of virtual memory? There must be memory leaks somewhere. Now, did someone happen to write a "desktop2kdelnk" program, the reverse of kdelnk2desktop?

All I can say now is their actions are getting to be stupid, sacrificing performance, speed, memory, and stability for some more bells and whistles that half of us don't want or need? That is plain stupid. I just say they should go back to writing code like in KDE1.1.2, now to fish out my Mandrake 7.1 CD's for the kde1.1.2 source...I know their somewhere around here...

apart from the fact your writing style is not really forum-compatible, you most probably have a problem with your kde installation. kde 2.1 was perfectly stable for me, dcop is not that big here (and i experimented a lot with dcop yet ...)
if you really think you have discovered bugs, please report them instead of the vague whining you do here. in my experience, kde developers really investigate bug reports..

I know you're just trolling, but I want to get rid of some misunderstanding of memory usage. dcopserver's /proc/#pid/status tells me:
VmSize: 15500 kB
VmLck: 0 kB
VmRSS: 860 kB
VmData: 340 kB
VmStk: 24 kB
VmExe: 36 kB
VmLib: 14460 kB
Since you're a programmer you should now that VmLib is shared between all applications. This leaves about 340+24+46=410kB of memory consumed by dcopserver.

This is just the memory used on the heap. I think for each of these, this is quite a lot in terms of memory consumption. Also, for some I cannot understand why multiple processes are running, e.g. artsd. Maybe these are threads...

What really scares me, though, is that there is a lot of infrastructure missing:
- no memory management to track leaks (after 2 months being logged in, even the smallest leak becomes a big problem)
- no tracing

For instance, 'artsd' likes produce some deadlock in the kernel (at least that's my theory) and wastes a lot of resources that way. But there is no other way to support the developer in finding the problem that to say: "there is a problem". How are the odds that this will be fixed? Not very good, I'd say. I was hoping that this particular problem will be fixed in 2.2 (I reported it a while ago), but it still appears in beta1. Having a trace facility in place would help very much by being able to take a trace when the problem occurs.
This is a common feature in commercial applications. Why not in something as complex as KDE?

I thought you actually sounded like a troll. You need to take a look at your installation. Even if you're a "developer" you likely have not done it correctly. Please understand that the aim of the KDE project not to produce the same thing as twm. KDE is a sophisticated environment. KDE developers try to create the best environment on any platform, and this means there will be some extra space. Unlike Microsoft, etc. KDE developers are true innovators and are working with the GCC creators to improve the speed of the program. They are using realistic requirements to create good systems.

You say KDE developers are real innovators. I use KDE and I am quite pleased with it. But I wonder which innovations you mean! Is there any cool feature (and usefull, too) that MS had not first?
I realised this when I did the change from Windows to KDE. My girl friend, who is far away to be a computer specialist, didn't even remarked, that she was working with KDE and not with Windows.
Maybe there are innovations from the developer's point of view. But the users must look very carefully to see the real differences between Win and KDE. Of course there are thinks working better in KDE, but I wouldn't call them innovations!

OK, the audiocd:/ is an improvement. The next Windows generation will support this and burning CD as well, as far as I know.
The "gg:xxx" is not bad but, in my eyes, not a breakthrough. If you want to start sofisticated searches you have to go directly to the Google site as well. Of course you could set parameters into the gg-Statement, but then we have a fundamental problem: we must decide: command line or GUI. And KDE-user prefer the GUI, I guess.
KParts: This does Windows as well. They call it OLE or something like this.
A really innovation for me is the possibility to access FTP within the open dialog of any application.

Is this really an innovation? And Windows does this as well (I'm not sure, I use Windows very seldom.).
I admit, it is a nice feature. Specially for me, for whom the optic is very important. If a program looks ugly, it will be a problem for me to use it.
By the way: on my system if I change the content of a text file the text preview doesn't update.
My opinion is: KDE is not more or less full of innovations than Windows. I could mention as many innovations in Windos as you probably could for KDE:
* menu items that disappear if they aren't used often
* the web view for directories which tells you how many free space you have (helpfull for beginners)
* auto completion in IE

If you feel so strongly that KDE needs more testing, why don't you start building the sources from CVS every few days, and submit some quality bug reports? Better still, seeing as you are a developer, why not debug some of the problems yourself, and submit some quality, well tested patches?

Or if you really don't like the direction KDE development is taking, why not produce your own fork of the KDE 1.1.2 sources, and add the features that you do think are worthwhile? I'm sure no one would be offended, and you would probably attract a number of other developers who feel the same way as you - after all, if you look at apps.kde.com you will see many projects that continue to release new versions based on the 1.1.2 libraries.

Actually, several people have visited my home page for my new DE, based on a new toolkit, which will be similar to KDE 1.1.2, so the stability will be apparent. If you know anyone who would like to code this, have them send me some mail. As for building from CVS, and bug reports/patches, I am too busy to do that, and my computer isn't even on the internet, I am doing everything through CD's and floppys with multi-volume archives. And, what I've noticed is that it isn't KDE that's really the major issue, it's just really too slow, it's really kdevelop running in KDE, which refuses to place itself correctly on startup, and some other problems that I won't mention, since this isn't a kdevelop forum.

As a little history, KDE 2.1 Beta was probably more stable for me, just slightly, though. Maybe the problem is in my compiler....does anyone have any problems using KDE compiled with gcc 2.95.3?

Enough of this, I think I've learned my lesson...don't post messages that sound like flames...if you want it done right, do it yourself...blah, blah, blah...and use IceWM with kdesktop for speed, power, and memory considerations....