[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:36:39
Message-ID: 200805121437.33902.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, 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 );

or in qt-copy with (though I guess that's sub-optimal);

Index: qtextlist.cpp
===================================================================
--- qtextlist.cpp       (revision 804489)
+++ qtextlist.cpp       (working copy)
@@ -242,6 +242,8 @@
 */
 void QTextList::remove(const QTextBlock &block)
 {
+    if (! block.isValid())
+        return;
     QTextBlockFormat fmt = block.blockFormat();
     fmt.setIndent(fmt.indent() + format().indent());
     fmt.setObjectIndex(-1);
@@ -255,6 +257,8 @@
 */
 void QTextList::add(const QTextBlock &block)
 {
+    if (! block.isValid())
+        return;
     QTextBlockFormat fmt = block.blockFormat();
     fmt.setObjectIndex(objectIndex());
     block.docHandle()->setBlockFormat(block, block, fmt, 
QTextDocumentPrivate::SetFormat);
_______________________________________________
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]