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

List:       koffice-devel
Subject:    Re: Bug: Line width in paragraphs which belong to a list
From:       Florian Merz <FlorianMerz () gmx ! de>
Date:       2008-03-12 16:13:48
Message-ID: 200803121713.48664.FlorianMerz () gmx ! de
[Download RAW message or body]

Am Samstag, 8. März 2008 schrieb Thomas Zander:
> Hi Florian.
Hi Thomas,

> I never did apply your patch. The concepts and ideas looked very
> promising! Cool stuff :)
Thanks.

> Btw, is it in svn yet? Did you request an svn account yet?
No, it's not in svn yet and I don't have an account. Is it a good idea to 
commit this in such an early stage?

> On Wednesday 5. March 2008 13:28:39 Florian Merz wrote:
> > when I tried to make my spacing tool aware of lists I noticed, that
> > there seems to be a bug in the text layouting code (svn trunk from
> > about a week ago):
>
> I wrote that code quite some time ago, it would not surprise me that
> there are some bugs left :)

I'm sorry to say, but you're right, there are a few bugs left. I found some 
when testing my own tool. It's mostly related to the position of the list 
counter. I'll add them to b.k.o when I have some spare time.

> > To reproduce it create a paragraph and fill at least two lines
> > completely up to the right border ("a b c d e f g h ..." works fine).
> > Then turn this paragraph into a list. The first line will be layed out
> > properly, but the second line is too wide. It seems like the
> > calculation of the non-first lines doesn't take counter width and/or
> > counter spacing into account.
>
> Thanks. Good catch!
> Not sure if anyone will have time to fix it soon, you may want to file a
> bugreport so it doesn't get forgotten.

Will do...

> > I also have a question on a different matter:
> > Is there a signal, which gets emitted when a relayout of the text has
> > been done?
>
> No, there is currently not.  For completeness sake, let me give a short
> overview of the way it works now.
> The layouting is done in-thread currently by doing chunking. Meaning it
> layouts about one page per event and then goes back to the event loop.
> The screen is repainted all the time while layouting since we do an
> update of the shape per paregraph we finished.

I though about using a QTimer to add myself to the event queue right after 
the layouting, but if the layouting is done in chuncks then this won't get 
me anywhere.

> > Right now I call the layout() function of the KoTextDocumentLayout
> > myself, but I'm afraid this might block the user interace on bigger
> > paragraphs, and this also causes the layout not to flow around other
> > shapes. So I'd rather let the text engine do the layouting and get a
> > notice when the results are in.
>
> Could you give me a little overview of what you are trying to accomplish?
> I mean; what results are you waiting for ? :)
> Any suggestions are appreciated, we can probably think of a good way to
> make this work :)

My tool provides user interface elements (which I called rulers in lack of a 
better name) which can be used to change the spacing of a paragraph. The 
user can drag a ruler with his mouse and once the mouse button is released 
the change is applied to the paragraph. This change schedules a relayout of 
the paragraph, and this invalidates the position of all rulers.
For example, a change in the left or right margin can influence the position 
of the bottom margin. To paint the rulers at the correctly I need to know 
this position, but the exact position can only be known after the layout 
has been finished for this paragraph.

This is how I think it should work:
1. user drags a ruler and then releases the mouse button
2. tool writes new values to the paragraph style and the block format
3. relayout is triggered by the layout engine
4. tool waits for the relayout to finish (with the current paragraph)
5. tool reads the updated position of the paragraphs from the text layout
6. tool updates the position of the rulers and repaints them
7. tool waits for user input

Right now, I replaced step number 4 by a call to layout() directly. This 
means the text is layed out all at once, and the tool can retrieve all the 
needed information afterwards. This not only destroys responsiveness, but 
for some reason the layout also doesn't flow around other shapes.

> > I know there is an update() signal defined in
> > QAbstractTextDocumentLayout, and it is emitted in QTextDocumentLayout,
> > but grepping KoTextDocumentLayout revealed that it never gets emitted
> > in the KoOffice implementation.
>
> Right, we may want to emit that, Qt does it in documentChanged(), which I
> think is before any layouting is done. I guess it would be wise to follow
> that rule to have minimum surprises.
Ok, so this doesn't seem l ike the signal that I need. What I would need is 
either a "layout finished completely" signal or a "layout finished for 
paragraph x" signal.

> Have a good weekend.

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