[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: time to move on to qt44
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2008-05-12 10:35:49
Message-ID: 200805121336.32167.mail () dipe ! org
[Download RAW message or body]

On Monday 12 May 2008, Thomas Zander wrote:
> On Monday 12. May 2008 01:25:56 Sebastian Sauer wrote:
> > The Qt4+KDE4 stack we build up just is yet not that rocking stable like
> > the Qt3+KDE3 stack we had and to force users to trade there
> > tested+stabelized Qt4.3+KDE4.0.3 stack against a new and not so well
> > tested combination to get right of those 3-4 #ifdef's in our code, just
> > doesn't sound like a good idea to me.
>
> We have to release koffice with Qt 4.4, though, so if you talk about end
> users you have to take that into account.
> Textshape undo facilities needs 4.4 for example.

y, true too. Well, most of us are using qt-copy+kde-trunk anyway (using as 
compiling against or did anybody already switched to kde4?)

> > So, why not just wait those additional ~3 months where
> > we already did wait even longer till 4.4 was released or is it really
> > that big pain for us to have some #ifdef's some months longer in and to
> > provide a well tested upgrade-path? Or do we depend on something new
> > within 4.4 like woc, webkit, ... we need to use asap?
>
> In Qt 4.4 we put a LOT of features other then the big ones you mention;
> there are dozens of new features and bugfixes in text rendering alone. The
> QAtomicInt will be a class that Krita will benefit from quite a lot as
> KOffice classes are not very well guarded against multithreading. With this
> class we can fix that.  Again, as a quick example.

ok, sounds logical. Thanks for that samples. Well, maybe we can ask what 
Cryille and boud are thinking here (cause you named Krita *g*) and if I am 
the only one with a bad feeling here then just do it :)

> I personally don't buy your argument that we should wait in order to give
> the user the best solution possible.

Well, I guess our highest priority should be to decrease the entry-barrier to 
work on koffice as much as possible.
But that's more a generic question. Will we also switch to 4.5 or 4.6 asap 
without looking at the kde-stable version that is out (or not out) at that 
time? I really don't hope so.

> There is the assumption in there that all problems will be magically fixed
> in the mean time.  But if you don't use it and don't report or fix those
> problems, how do you expect that to happen?
>
> Fact is that this is all open source software and KOffice is one of the
> more demanding users of the APIs. This means that you will find issues that
> nobody else finds, and to get them fixed you need to indeed tell upstream
> about them. I hope thats not too much work.

Oh, we try to. E.g. ~2-3 days ago Pierre did report a problem that loading the 
opendoc1.1-specs with KWord now crashes in 4.4-scribe while it was working 
fine before. Okular btw maybe too (no idea if it's the same bug cause atm it 
asserts for me already on startup somewhere in kdelibs/kdecore/* - hmpf).

So, the moment Pierre did point me at it and after spending some time to look 
at the qt-sources, I already sayed "ignore it". That's based on past 
experience. He did not followed that, wrote a bugreport and answer was that 
we should provide a trimmed down testcase (uh, of KWord?) Ergo: We ignore it 
now cause there are more important things to do within KWord.

Same with the KWStatusBar-crash that is now fixed in 4.4 while it was already 
known at 4.3/4.2 times (it was the same issue we had with multiple views 
crashing in KWord). Wasn't it even you who sayed we should ignore it? ;)

So, all in all new bugs/problems doesn't mean to get them fixed faster. It 
just means that you have to prioritize some more things and will probably 
waste some more time to work around something that prevents you from working 
on other things that have a bigger priority for yourself.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]