[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 11:29:14
Message-ID: 200805121430.22788.mail () dipe ! org
[Download RAW message or body]

On Monday 12 May 2008, Sebastian Sauer wrote:
> On Monday 12 May 2008, Sebastian Sauer wrote:
> > 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).
>
> ah, --noincremental helped here once more :)
>
> anyway, it seems to be even another crash new in 4.4;
>
> [KCrash handler]
> #4  0x00002b67bbecf59a in QTextDocumentPrivate::beginEditBlock (this=0x0)
>     at
> ../../include/QtGui/private/../../../src/gui/text/qtextdocument_p.h:204 #5 
> 0x00002b67bbed6f2f in QTextDocumentPrivate::setBlockFormat (this=0x0,
> from=@0x7ffff3839c50, to=@0x7ffff3839c50, newFormat=@0x7ffff3839be0,
> mode=QTextDocumentPrivate::SetFormat) at text/qtextdocument_p.cpp:741 #6 
> 0x00002b67bbf0d7ac in QTextList::add (this=0x2569410,
>     block=@0x7ffff3839c50) at text/qtextlist.cpp:260
> #7  0x00002b67c464bb5b in OOO::Converter::convertList (this=0x8d9970,
>     element=@0x7ffff3839ea0)
>     at
> /home/kde4/svn/_src/kdegraphics/okular/generators/ooo/converter.cpp:366 #8 

The crash can be fixed in okular by;

QTextList* list;
QTextBlock prevBlock;
//some code to determinate prevBlock
- list->add( prevBlock );
+ if( prevBlock.isValid() ) list->add( prevBlock );

_______________________________________________
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]