On Mon, 2006-06-12 at 11:06 +0200, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > | On Mon, 2006-06-12 at 09:30 +0200, Lars Gullik Bjønnes wrote: > | > Martin Vermeer <[EMAIL PROTECTED]> writes: > | > > | > | On Sat, 2006-06-10 at 15:22 +0200, Lars Gullik Bjønnes wrote: > | > | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > | > | > > | > | > | We have a drawing error with insets. It is very easy to see with the > | > | > | note inset. Just load the userguide, look at the 'Note' inset near > the > | > | > | top, place the cursor within it and see the background and frame > | > | > | change. > | > | > | > | > | > | If the note is not the first item in the paragraph -> no error > | > | > | If the note contains just one paragraph -> no error > | > | > | > | > | > | I so far fail to see just where the logic in our drawing fails, any > | > | > | help appreciated. > | > | > | > | > | > | Is this bug also present in 1.4? > | > | > > | > | > This bug is caused by r13328: > | > | > | > | Am I right in suspecting that what you call a "bug" is in fact my design > | > | choice / visual innovation? If so, I resent it... stop calling names ;-) > | > > | > Possibly. I'd still call it a bug though. > | > > | > We should find a better solution. The Wide() thing really feels like a > | > hack. (And there should be no reason why a Wide() non-Wide() have to > | > be drawn differently.) > | > | I haven't been able to. And I really tried... > > But all the text is drawn identical, it is only the background and and > frame that is drawn "wide".
Yes. The problem (as I remember) was that the frame was "jumping" all the time when typing into the inset. When refreshing only the current row + its background (as the patch tries to do as much as possible) this will lead to a mess of partially painted row backgrounds and non-aligning pieces of frame. As said (or implied), I tried to sanitize this, but didn't succeed. It was just easier to eliminate the vertical frame edges altogether. It would be great if you succeeded where I gave up. As a kludge (similar to Enrico's proposed #ifdefs but easier) you can go into insettext's Tall() method and increase the constant 2 to something bigger. Then the "bug" will only occur for really big (tall) insets, which is where the Mac problem occurs. (Note however that we are rendering too many rows on _all_ platforms. It's only on the Mac that it gets in the way of even the single user.) - Martin
signature.asc
Description: This is a digitally signed message part
