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, has
posted
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.
Subject:
KDE 2.2 release: current schedule
Date:
Mon, 16 Jul 2001 10:30:59 -0700
From:
Waldo Bastian
To:
[email protected], [email protected], [email protected], [email protected]
Hiya,
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 up to date schedule for the KDE 2.2 release is as follows:
From the release plan:
KDE 2.2 final
- Monday July 16. The HEAD branch goes into deep-freeze. All commits should be posted for review _BEFORE_ commiting.
- Sunday July 29. Last day for translations,
documentation, icons and critical bugfixes commits. - Monday July 30.
The HEAD branch of CVS is tagged KDE_2_2_RELEASE and the day is spent testing
the release a final time. - Tuesday July 31.
The tarballs are made and released to the packagers.
The rest of the week is spent testing the tarballs, packaging and writing the
announcement and changelog. - Friday August 3.
The source and binary packages are uploaded to ftp.kde.org to give some time
for the mirrors to get them. - Monday August 6.
Announce KDE 2.2.
Frequently Asked Questions
Q) Which packages are included?
A) The current list of packages that will be in the 2.2 release is:
- kdelibs
- kdebase
- kdenetwork
- kdegraphics
- kdeadmin
- kdemultimedia
- kdegames
- kdeutils
- kdetoys
- kdepim
- kdesdk
- kdebindings
- kdevelop
- kdoc
- New package: kdeaddons
- New package: kdeartwork
Cheers,
Waldo
--
[email protected] | SuSE Labs KDE Developer | [email protected]
(Ed: For those who have not noticed yet, KDE no longer ships with kdesupport, under the theory that modern distributions already provide the programs forming kdesupport.)
Comments
Wise decision! Waldo, thank you for taking kare of the release schedule in such a professional way. I have still an other kuestion:
Will Koffice also be delayed?
I think it should be. 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 :-<.
I think the basic functionality is there. we need to koncentrate more on the stability, that's klear ;-).
PS: BTW, may be I am I the only one having these problems. Any comments/experiences on the stability of the varoius packages?
> 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.
SD
In fact, the multi-page table was a known problem which David fixed shortly after beta 3...so the good news is that current CVS and the full release should work OK!
As always, if you have specific documents that (a) are causing you problems and (b) are not confidential, then feedback via bugs.kde.org will draw attention to the problem!
Thanks, Shaheed
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.
Thanks
SD
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.
If it fails during an attempt to import a word document, then how could one modify what one can't open?
However, for other cases, not related to importing, but, say related to printing, such might not be bad idea.
Do we really want to optimize for bug reporting ?
Will this make KOffice look good ?
I think that a stable, featureful KOffice in a few years would look great! Helping users help developers will only improve the quality of the software.
> Will Koffice also be delayed?
KOffice is on a seperate schedual, which can be found here:
http://developer.kde.org/development-versions/koffice-1.1-release-plan.html
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.
--
Evan
Kut that out! It's driving me krazy!!!
What about Mosfets changes/addons, will they be included, or available somewhere?
--
Andreas
Score: -1, troll :-)
I hope this additional time will be used to re-add the intentionally from kdebase removed icons for 8bpp displays!
I agree, I would have enjoy to use KDE throught low bandwidth network but the minimum 18 bpp is too much.
Please put back the 8bpp display.
The 8 bpp-icons have just been (re-)added to kdeartwork.
Greetings,
Tackat
/opt/kde2.2/share/icons/hicolor > find . | wc -l
1663
/opt/kde2.2/share/icons/locolor > find . | wc -l
31
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/ .
Sorry, Tackat but it looks like a quick bad shot.
> Uhm? You have to install a "locolor" _theme_
> to get _some_ locolor icons!?
> I think that's not acceptable!
Actually KDE should switch automatically to the locolor-icontheme if it is available just the same way KDE 2.1 did.
> KWord lacks half of it's icons. I stop here to summarize.
Feel free to take care of this task. The locolor-icons were removed from kdelibs/base because they weren't maintained actively anymore.
> Better think of an automated process which
> regularly locates and creates all missing
> locolor-icons
Well in that case dithering the remaining hicolor-icons on the fly is certainly the better solution.
Tackat
> 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.
I agree, but I guess we don't will see this included in KDE 2.2. :-(
> I agree, but I guess we don't will see this
> included in KDE 2.2. :-(
Looks like you guessed wrong. :-)
lists.kde.org
Greetings,
Tackat
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.
#26618 seems to describe this
> But there is a bug: If you install the
> locolor-icon theme it stops working! I would
In what sense ?
> expect it to search first user's locolor-icons
> followed by system-wide locolor-icons and last
> dithering system-wide highcolor-icons.
You seem to be still using hicolor as your icon theme. Go to KControl->Look&Feel->Icons and select locolor as your icon theme.
About #26618, the application cannot assume that locolor is installed anymore, so this is a problem in the application installation.
Greetings,
>> 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.
No, "KDE-LoColor, Lowcolor Icon Theme" is selected. Applying it again, doesn't change anything either.
> 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.
Aaah, I see. You're right, that's a real problem (but different from #26618). Thanks for reporting it.
It's fixed now. Please update your locolor theme from the kdeartwork module.
Greetings
Please don't include kwrite in the distribution unless you add support for at least 100 languages!
Sorry, just joking... :)
Please give it a rest, Per and company... You may take the discussions to our free for all forum.
Thanks,
-N.
I don't know if kwrite will still in KDE2.2, but I'm waiting for its successor "Kate" which seems to be a lot more powerful
I'm excited about Kate too. It's a cool name, and should be a neat program.
I would like to see a creative name for a new IM client. Gnome's GAIM is going through legal battles, when perhaps they could have just thought of a cool name.
I think Kim would be a nice name, standing for KDE Instant Messaging, as Kate stands for KDE Advanced Text Editor.
Richard Stallman said in his recent speech in Boston that coming up with a cool name is part of the fun of developing a program. I agree.
I would like to see a more sophisticated KDE instant messaging tool, perhaps in 2.3, 2.4, or 3.0. This would be useful in the fight against proprietary computing environments.
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 excited about Kate too. It's a cool name, and should be a neat program.
I would like to see a creative name for a new IM client. Gnome's GAIM is going through legal battles, when perhaps they could have just thought of a cool name.
I think Kim would be a nice name, standing for KDE Instant Messaging, as Kate stands for KDE Advanced Text Editor.
Richard Stallman said in his recent speech in Boston that coming up with a cool name is part of the fun of developing a program. I agree.
I would like to see a more sophisticated KDE instant messaging tool, perhaps in 2.3, 2.4, or 3.0. This would be useful in the fight against proprietary computing environments.
sorry for this repeat post. I saw a quote from Caldera I thought would be interesting that I missed, pushed the back button and impulsively reposted form data. Please excuse me for this.
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.
Thanks, KDE developers!!!
I would like to see that too. That programs open on the V desktop that they where started on, even if you change V desktop will it is loading.
The only problem is that I've gotten so used to the old way, that i forget I've started programs, because they don't appear on-screen :).
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.
Although I don't agree with the style of the original poster, I think he has a point on some respect.
In my system, I have 30 kdeinit processes running:
- 3x kicker: 3MB each
- noatun: 5MB (not active)
- 2x artsd: 3MB each (not active)
- 8x konsole: 1.5MB each
- 3x kdesktop: 1MB each
- various other things
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?
Knut
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.
Please respect KDE developers for their efforts.
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!
Here are some innovations that I haven't seen in Windows (maybe they're in ME or 2K, but I haven't had any desire to try them out):
The audiocd:/ ioslave - copy mp3 files directly from an audio CD, without the need for an intermediate program (it's done automagically for you).
Internet Keyword Search: put 'gg:foobar' into the konqy location bar, and take a look what it does :). Same works for more other search engines, plus dictionary, etc. It's also configuratble.
KParts: real embedding of whole applications, which "take over" the window when you want to edit the embedded data.
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.
Text-Previews using mimetype-icon-"watermarks" to display filetype + content. Damn I should have patented that idea ;^) !
Greetings,
Tackat
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....
Will KDE ever have a fairly standards-compliant + feature-full browser? How about embedding, in the vain of the Galeon project?