The KOffice team today released the first bug-fix release in their 1.5 series. Critical bugs in KSpread, KWord and Krita were fixed, thanks to the helpful input of our users. We also have updated languages packs. You can read more about it in the press release and the full announcement. A full changelog is also available. Currently, you can download binary packages for Kubuntu and SUSE.
hey, every big app has its crashes. Kword isn't that bad, at least not for me... i have just one reliable crash: type in a url, hit space or enter - and kaboom. just put autosave on 1 min, and don't forget to save (name) a doc as soon as you started it - or there is no autosave (kword should really fix this).
If your copy of Koffice/Kword is crashing that oftern, there obviously something really wrong with how you compiled it or how your system is setup.
Remove an 'optimization tweaks' and stick to conservative CFLAGS and recompile; for me, I'm using FreeBSD with the following FLAGS, -Os -pipe -fno-strict-aliasing -funroll-loops -fschedule-insns2 and I have yet to experience a crash or any of the problems I hear people complain about here.
I understand that because it was too late in the release progress to do anything about it but is there a patch out there to fix whatever this critical error is?
"The KOffice release announcement mentions some post-release discovered issues with Kexi - the SUSE rpms already contain the patches to fix these so don't hesitate to upgrade your KOffice because of that."
> I understand that because it was too late in the release progress to
> do anything about it but...
No, it was not too late. The bug (+ patch) has been discovered on Friday, release has been on Tuesday. Emailing the patch to the thee to ten packagers does not need three days. At least the Suse packages already include the fix.
Yes, it was too late. It was a week after the source packages were created for the first time. We recreated the packages two times for other bugs during that week. If we had recreated the source package again, the release wouldn't have been until Friday. Recreating the source packages, asking the packagers to recreate their binarie packages again does take a week. We decided not to wait.
> We recreated the packages two times for other bugs during that week.
Just do it a third time or release an additional RC.
> If we had recreated the source package again, the release wouldn't have been
> until Friday.
I think the release was an Tuesday, not Firday. (see www.koffice.org, dot.kde.org,...).
> Recreating the source packages, asking the packagers to recreate their
> binarie packages again does take a week.
No, it does not take a week. At least you could ask the packagers, how long they would need. But you did not even try. I think that the Kubuntu people would have managed to update the packages and Suse actually *did* include the fix:
From the Suse-RPMs changelog:
* Fri May 19 14:00:00 2006 [email protected]
- Kexi: fix forms plugin not being loaded
- Kexi: fix possible data loss in forms
So you have the funny situation that the Suse packages are better than the original source tar balls. Thanks, Stephan Binner!
As I said -- instead of telling me what to do, telling me I'm wrong and calling me lazy, do the work yourself. Deal?
I don't think that anyone is saying that you are lazy.
However, when a critical bug is found, the release MUST be delayed to fix it. To do otherwise is irresponsible.
The Debian packages (just uploaded) also contain the fixes :)
Are there packages for Sarge?
Is there a plan to put packages into http://www.backports.org/ ???
That would be great, 'cause it would prolly also mean there could be kliks, no?
> So you have the funny situation that the Suse packages are better than the original source tar balls.
Could you please stop publishing these theories, anonymous? Boudewijn Rempt has done good work by releasingthe stuff, and the patches come from me in the same day when the sources of problems were identified. One of the packages was worked out thanks to valuable Stephan's hints.
The announcement contains a link to the patches in "issues" section.
Packagers are not working 24x7, if you're curious and there is not only KOffice in the world to package. On other world you might expect we should close our mouths and do not disclose the problem...
> Could you please stop publishing these theories, anonymous?
Those are no theories but facts.
Using tar.gz => Kexi does not work
Using Suse RPMs => Kexi works very well
All in all: This is a large step for Koffice!
And using Suse, RedHat, Mandriva, Debian etc, etc RPMs/DEBs of the Linux kernel are in almost all cases better than the tar.gz of the same version at Kernel.org. Your point is what exactly?
Kexi Patches: Full Details
Will the Kubuntu packages be backported to Breezy?
You mean: will someone create koffice packages for ubuntu breezy :o)
Exactly ;-) If I knew how to I would be glad to make them myself.
One should suspect that if Jonathan Riddell didn't make the packages, kdelibs in Breezy makes inviable to package koffice-1.5.1 for it...
Or switch to Suse, they provide packages for Suse 9.2, Suse 9.3, Suse 10.0 and Suse 10.1.
Yeah, the scary part is you are using Kubuntu instead of Suse in the first place. That is scarrry.
/me looks at his laptop running kubuntu
/me looks at his desktop running suse
ok. so am i, like, doubly screwed? ;)
The KDE (and particularly KOffice) guys seemed to have really got their marketing and public image worked out well in the last few months, but then I read this:
"a critical bug discovered too late in the release process to do anything about"
Ummm.... How can it be too late in the process to do anything about? Just don't send out the release announcement.
If you have known RC bugs in your release, it doesn't go out. That way you don't look stupid because you don't have to tell some people they should upgrade and others that they shouldn't.
(Remembering why I use Debian...)
come on, many commerical products come out with critical bugs.... :D Look at XP, it's almost ready for release, according to debian standards ;-)
WinXP probably needs another couple of years of bug fixing before it's ready for release ;)
Here's a common point that's coming up time and time again just recently... this isn't a relative thing ("at least we're better than M$/Adobe/insert-favourite-company") this is sometimes about absolutes.
Yes, releasing KOffice with only 1 or 2 RC bugs is probably better than most M$ Office releases but it's still crap for the end user. (And have you ever seen a M$ press release advising users of Access not to upgrade to the latest release?)
> Ummm.... How can it be too late in the process to do anything about?
> Just don't send out the release announcement.
Exactly. Could have been as simple as that.
Or even better:
After the bug has been discovered (patch has been available since May, 19.), apply the patch and send emails to the few packagers to redo the packages.
Packages are available by now for Kubuntu and Suse. The Sue packages even include the Kexi fix. So only the Kubuntu people had to be emailed.
But someone was to lazy and thought "Let's just release it without the bugfix"...
Hey, Hans! Thanks for volunteering to be our next release manager. Let's see how you juggle a data-loss critical bug in a released version of KSpread versus waiting another week with released.
You by yourself asked "I'm wondering if we
shouldn't skip 1.5.1 altogether". So I don't think that a one or two day delay would have caused much harm.
Yes, and? That was one possibility. Discussion on IRC helped me make the decision to release anyway. Of course, today it turns out that the Kexi bug isn't a regression, so the warning wasn't necessary, and we could have released Friday anyway.
I must agree.
What is it that causes this problem which has also occurred with KDE?
One of the advantages of OSS should be one of flexability in the release schedule. However, there seeems to be some compulsion to kick releases out the door before they are 100% ready. If this happens often, it will reflect poorly on the quality of our software.
Yes. The "some compulsion" in this case was a grave bug in KSpread that would cause data loss for users. In the end, the kexi problem turned out to be not all that critical -- that we thought it was critical was just because of a misunderstanding.
All software will always be released with bugs. If you go for the rigid cmm level 1 quality standards the "bug" will be that the software by the time it's ready is no longer what the users need.
It's impossible to both release early and often and release only when ready -- you can do one or the other, but not both.
Sophistry does not solve quality issues.
Nor, does rhetorical devices and logical fallacies.
Why is it that we keep hearing such rationalizations rather than discussions of how to improve quality?
Whether releasing "early and often" or only when the release is ready is not a valid dichotomy. If you reduce this argument, you are advocating releasing before the release is ready -- clearly not a good idea. This is NOT a binary proposition; there is plenty of ground in the middle between these extremes.
When is a release ready to be released? This is a good question for which there isn't a good answer. However, it is easy to tell when a release has been released before it is ready.
KSpread had a critical dataloss bug in the previous version, fixed in the new RC. The more the release is delayed, the more people run into the bug, and lose their data. Hence, it is a _very good idea_ to get the next release out as soon as humanly possible. That Kexi also had a critical-but-turned-out-not-to-be bug discovered complicates matters, but as I don't believe that one caused dataloss, it was the right decision to release ASAP. There is -nothing- more important than protecting your users' data (and security).
Is this difficult to understand? It's certainly not as simple as the "wait until every bug is fixed" mantra.
Why not releasing another RC?
from the Krita homepage:
"Now Krita is a capable image editor and a great platform for future development. The current release of Krita (version 1.5.0) has too many features to list them all:"
How can a program be called a "capable image editor" if it even lacks a usable blur or sharpen filter? If the save-as-JPEG dialog is only usable by try-and-error? If the auto-contrast filter creates clipped highlights? Those are basic features which should work!
Are there additional plugins (Unsharp mask sharpening, adjustable gaussian blur,...)? I don't think so, as the Krita homepage does not contain the word "plugin". :-(
But all in all, Krita is a promising technology study. If they only would *include* some good plugins or at least good plugin-creation-HOWTOs. (Some time ago I tried to do an unsharp-mask-sharpening script by my own (very simple, just overlay an inverted gaussian blured version of the original image), but Krita even does not support gaussian blur, so even an own script was no help. Had to go back to gimp and digiKam...)
> How can a program be called a "capable image editor" if it even lacks a
> usable blur or sharpen filter? If the save-as-JPEG dialog is only usable by
> try-and-error? If the auto-contrast filter creates clipped highlights? Those
> are basic features which should work!
O.K., I try to improve the sharpen and blur filters.
> But all in all, Krita is a promising technology study. If they only would
> *include* some good plugins or at least good plugin-creation-HOWTOs. (Some
> time ago I tried to do an unsharp-mask-sharpening script by my own (very
> simple, just overlay an inverted gaussian blured version of the original
> image), but Krita even does not support gaussian blur, so even an own script
> was no help. Had to go back to gimp and digiKam...)
Actually, writing plugins for Krita is quite easy. A good starting point is the pixelize filter (it is in krita/plugins/filters/pixelizefilter). Just copy the files from the pixelizefilter in a new directory, rename them to whatever you like. The central function is KisPixelizeFilter::process where the actual filtering happens. Maybe I write a HOWTO if I find some time.
Blog about Krita plugins:
Example plugin for Krita:
We're not a "they" -- we're a "you". Which means that you can contact us and share your knowledge with us. You say the blur and sharpen filter are unusable -- have you tried coming up with a good description of what a usable sharpen and blur filter need to provide? Have you tried finding good algorithms for us to implement? There's a mailing list, there's irc. And you need to be in time: after feature freeze, nothing can be done. And the last time someone complained about the sharpen filter was after 1.5 had gone into feature freeze. Sorry, but we cannot change the GUI anymore after feature freeze.
I am working on a plug-in howto, Cyrille has an unsharp mask filter and lots of other improvements in his krita-plugins pack, so there's progress, but if you care about improvements, you need to get involved. And that doesn't necessary mean coding; it just means approaching us and sharing your expertise. Random bits of opinion posted on the dot don't help.
> You say the blur and sharpen filter are unusable -- have you tried coming up
> with a good description of what a usable sharpen and blur filter need to
> provide? Have you tried finding good algorithms for us to implement?
Come on, have you ever used the sharpen filter by yourself?
It's a simple sharpen filter without any adjustments possible and it's strength is *way* to strong. Good algorithm? Just look at any other image editor, it's called "unsharp mask".
Gaussian blur? Again, the needed adjustments are lacking. If you click on "gaussian blur" you expect a dialog with preview and a control to set the radius.
> Sorry, but we cannot change the GUI anymore after feature freeze.
Then maybe your feature freeze is too strict?! Adding one or two plugins should not cause any regressions. And If I remember correctly, an additional plugin-pack is in the pipeline, too.
> Random bits of opinion posted on the dot don't help.
Seems to help quite a bit :-)
> Cyrille has an unsharp mask filter and lots of other improvements in his
> krita-plugins pack
Where can I read more about it? Krita Homepage?
I don't want to file several bugzilla-entries if Cyrille has working unsharp mask and gaussian blur filters.
> > Sorry, but we cannot change the GUI anymore after feature freeze.
> Then maybe your feature freeze is too strict?! Adding one or two plugins
> should not cause any regressions.
True, but regressions isn't the only concern, adding plugins means adding strings to translate, and for the sake of translations team we can't do that either.
> > Random bits of opinion posted on the dot don't help.
> Seems to help quite a bit :-)
I hope that we will see more bugs report ;) as for the adjustable blur and unsharp mask they were allready in krita-plugins svn for a month ;)
> Where can I read more about it? Krita Homepage?
> I don't want to file several bugzilla-entries if Cyrille has working unsharp > mask and gaussian blur filters.
You can read about them here (or when I blog about them on planetkde.org):
It's not userfriendly, but less time consuming than managing a website ;)
I seldom have time to actually use Krita you know -- I spend way too much time coding, packaging, writing plugin manuals. In any case, if you want me to take enthusiastic action, you had better be a little more friendly and courteous. And I have not changed my plans in any perceptible way by the ill-mannered comments on the dot: I am currently engaged in the depressing work of porting Krita (and KOffice) to Qt4 and that consumes all my time.
In any case since you seem to know such a lot about the way we work, it surprises me that you don't know why we have such a strict feature freeze: it is to enable the translators to do their work. Their life is difficult enough as it is.
Cyrille's cool plugin pack does contain unsharp mask, red eye removal and lots of other cool stuff, but it did already so before "Max" began to clamor for it. I seem to remember that work on unsharp mask was started because Larry on the Krita mailing list asked about it and helped us figure out what to do.
> And I have not changed my plans in any perceptible way by the ill-mannered
> comments on the dot: I am currently engaged in the depressing work of
> porting Krita (and KOffice) to Qt4 and that consumes all my time.
When KDE arrives, I'm sure 99% of all KDE users will have Qt3 around for some time. There are just too many third party applications which are based on KDE3 and/or Qt3.
Compatibility with KDE3 and Qt3 apps is a necessity for KDE4.
So from a user's perspective it's not very important if Krita is a qt4 or qt3 application. (I know that Krita is unfortunately part of the Koffice project... which makes those things more complicated).
So if porting Krita it Qt4 consumes all your time it could be that nobody will be interested in Krita when KDE4 finally has arrived.
Why not attract contributors and developers with a usefull and polished Krita 1.5.x and 1.6?
Don't take me wrong, I don't want to tell you what to do, but I have seen, that I did contribute to DigiKam but not to Krita. Why? DigiKam complies with "release early, release often".
From a user's perspective it's just much more worthwhile to improve DigiKam's working unsharp mask filter (now it's possible to use a very large radius (>50 pixel) to enhance the contrast of an image) than to file wishlist items for lacking basic features.
Krita could attract many users and developers with a good 1.6 release (or 1.5.1 + additional plugins + scripting/plugin Howto).
There will be a 1.6 release, which will be out in october if I remember correctly. Not all of the KOffice components will have added features in 1.6, but fast development of Krita was one of the driving reasons for us adding a 1.6 release at all.
> So from a user's perspective it's not very important if Krita is a qt4 or
> qt3 application. (I know that Krita is unfortunately part of the Koffice
> project... which makes those things more complicated).
> So if porting Krita it Qt4 consumes all your time it could be that nobody
> will be interested in Krita when KDE4 finally has arrived.
Shocking arrogance, rudeness, and ignorance are always such a delightful combination. Please, keep up these helpful posts---they really boost the spirits of all who are donating massive amounts of their time to create useful software and giving it to us for free!
Have you perchance followed the near-death of GnuCash because of its foundation on GTK1? And signs of its rebirth given that the GTK2 port is nearing completion? I for one say B.R. and others seem to know what they're doing, and am grateful for the wonders they are achieving.
Heh. I had forgotten about GNUCash. I think KMyMoney is better since it evolved faster (and is runner-up in the Sourceforge awards this year!) as it seems many KDE apps do. IIRC GNUCash made the unfortunate decision of using Scheme as its scripting language. Like aRts, it probably seemed like a good idea at the time.
I have only three words to answer "report, report, report". How are we to guess what the users need if they don't tell us ? So go to bugs.kde.org, fill report, or contact us on [email protected]. For instance, for the unsharp mask filter, someone speak about it on the lists, it was too late for the 1.5 release, but in a few days I had it to krita-plugins.
1) for the save as jpeg dialog, I am looking for bug entry, and I can find none related to that, as it is boring job I am waiting for a few people to vote for it...
2) for the adjustable blur, we should be ashame not to have included it earlier, it was a 5 minutes work... and it will be solved in a few day when I find the time to release krita-plugins
3) for the plugin HOWTOs, there is one who is included in the krita sources, true, it's a little bit hidden and not complete, but once again we need some input about it to improve it (krita/doc/Developing Krita Plugins.odt for the reference)
So please, contact us directly either through bugs.kde.org or our lists, it's the best way to help us improve krita.