Re: playground/office/flake

Hello Thomas,

> First version of a Repaint Manager.
> This allows each KoShape to have a repaint() method which will cause the
> canvas to repaint it.
> Design is a bit tricky due to the fact that each object can have more then
> one canvas it works on; I have to work on that a little more but the idea
> is already visible in the KoRepaintManager.h file
>
> The bigest sacrifice I had to make is that KoShapeManager now has its own
> list of the objects and a add/remove for the objects.
> With the ShapeManager being a QObject anyway we can probably add some
> slots to minimize the pain of a shadow administration.
>
> Note that the repaint manager is currently not enabled as there are some
> repainting bugs.
> Edit FlakeCanvas::updateCanvas (in testapp/mainwindow.cpp) to enabled it.

I have some questions to your patch. I don't understand why we need a repaint 
manger for every view. I think one repaint manager for the same data would be 
enough. 
Every canvas would know the repaint manager and the repaint manager would know 
the canvases. Then you say the repaint manger to repaint the object/rect and 
it repaints the canvases. This would minimise the administration for managing 
the objects needed.
I have attached a patch which is doing that. It is still very basic as I had 
not much time this morning and I have to go now. So it still has repainting 
problems but nothing that can't be fixed. At least I hope so . 
I really like to know what all of you think about it and which way we should 
go.

Re: playground/office/flake

Hello Thomas,

(This is a resend as my mailer made other thinks as I wanted.)
> First version of a Repaint Manager.
> This allows each KoShape to have a repaint() method which will cause the
> canvas to repaint it.
> Design is a bit tricky due to the fact that each object can have more then
> one canvas it works on; I have to work on that a little more but the idea
> is already visible in the KoRepaintManager.h file
>
> The bigest sacrifice I had to make is that KoShapeManager now has its own
> list of the objects and a add/remove for the objects.
> With the ShapeManager being a QObject anyway we can probably add some
> slots to minimize the pain of a shadow administration.
>
> Note that the repaint manager is currently not enabled as there are some
> repainting bugs.
> Edit FlakeCanvas::updateCanvas (in testapp/mainwindow.cpp) to enabled it.

I have some questions to your patch. I don't understand why we need a repaint 
manger for every view. I think one repaint manager for the same data would be 
enough. 
Every canvas would know the repaint manager and the repaint manager would know 
the canvases. Then you say the repaint manger to repaint the object/rect and 
it repaints the canvases. This would minimise the administration for managing 
the objects needed.
I have attached a patch which is doing that. It is still very basic as I had 
not much time this morning and I have to go now. So it still has repainting 
problems but nothing that can't be fixed. At least I hope so . 
I really like to know what all of you think about it and which way we should 

Re: playground/office/flake

On Monday 01 May 2006 08:42, Thorsten Zachmann wrote:
> I have some questions to your patch. I don't understand why we need a
> repaint manger for every view. I think one repaint manager for the same
> data would be enough.
> Every canvas would know the repaint manager and the repaint manager
> would know the canvases. Then you say the repaint manger to repaint the
> object/rect and it repaints the canvases. This would minimise the
> administration for managing the objects needed.

I chose the approach of having 1 repaint manager for every ShapeManager 
because its the only way we can have zero administration for managing the 
objects AND the classes outside of the library don't even have to know a 
repaint manager exists.

So, lets see what you created to minimize that...
/me reading diff...

Yes; you introduce administration into the mainwindow _and_ the canvas; 
whereas before the test application didn't even know there was a repaint 
manager.
I'm not sure what you mean by minimizing, this seems to do the opposite.

--

-- 
Thomas Zander

_______________________________________________
koffice-devel mailing list
koffice-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

Re: playground/office/flake

On Monday 01 May 2006 08:59, Thomas Zander wrote:
> I chose the approach of having 1 repaint manager for every ShapeManager
> because its the only way we can have zero administration for managing
> the objects AND the classes outside of the library don't even have to
> know a repaint manager exists.

I guess this would have been clearer if I named the class RepaintManager, 
without the leading Ko.  This because the class is not going to be 
exported and will only be used in this library so no namespace clashes 
can occur.

Not sure how the exporting of symbols in C++ or loadable libraries works, 
though. So I may be wrong with that.

Can someone else comment on that?  Is it a good idea to name 
non-exportable local classes to a name without "Ko" ?

--

-- 
Thomas Zander

_______________________________________________
koffice-devel mailing list
koffice-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

Re: playground/office/flake

On Monday 01 May 2006 08:59, Thomas Zander wrote:
> On Monday 01 May 2006 08:42, Thorsten Zachmann wrote:
> > I have some questions to your patch. I don't understand why we need a
> > repaint manger for every view. I think one repaint manager for the same
> > data would be enough.
> > Every canvas would know the repaint manager and the repaint manager
> > would know the canvases. Then you say the repaint manger to repaint the
> > object/rect and it repaints the canvases. This would minimise the
> > administration for managing the objects needed.
>
> I chose the approach of having 1 repaint manager for every ShapeManager
> because its the only way we can have zero administration for managing the
> objects AND the classes outside of the library don't even have to know a
> repaint manager exists.

So how do you repaint stuff that lays below the objects ( e.g. background, 
objects from master page ) which has nothing to do with flake?

Thorsten

KoText paragraph border rendering

Paragraph borders in KoText currently span the full width of the 
frame, but in OpenOffice/Word they only span the width of the 
paragraph.  (These are the same if the paragraph has zero-length 
margins, but are different otherwise.)

This looks a little silly, particularly when combined with paragraph 
backgrounds which only span the width of the paragraph.

I've attached a patch to:

* Rename some variables: backgroundLeft and backgroundRight become 
leftExtent and rightExtent respectively.
* Use leftExtent as the right-most point of the left border.
* Use rightExtent as the left-most point of the right border.

It still leave some silly behaviour where there is a wide left border 
and the first line in the paragraph has a positive margin offset, but 
it is at least consistent with OO.o in this regard.

Is this OK?  If so, to which branches should I commit?

There's also some indentation in some of my code in KoTextDocument.cpp 
that I'd like to fix at the same time.

Cheers
Martin

Re: playground/office/flake

On Monday 01 May 2006 18:58, Thomas Zander wrote:
> Not sure how the exporting of symbols in C++ or loadable libraries
> works, though. So I may be wrong with that.
>
> Can someone else comment on that?  Is it a good idea to name
> non-exportable local classes to a name without "Ko" ?

I might be wrong, but even if it's not exported by default, I'm not 
sure you can rely on everyone's build toolchain supporting 
visibility.

It's only recently been introduced in g++, right?

In that case, I think the class name would be visible outside the 
library, and either a prefix or a namespace would be appropriate.

Martin

[flake] selection and tools

Yesterday I realized something.  We currently draw the selectonHandles in 
the KoSelection object, but I think thats wrong.
The issue here is that only the InteractionTool (former DefaultTool) will 
want to paint the selection the way its done now.

If you take, for example, a connector tool (for kivio) to add connections 
between two objects then the selection we paint now is not really wanted. 
I guess that that tool would want to draw the connectors instead.

I've been experimenting with a couple of ideas here on how to do this best 
but in the end I always end up with the need for the shapeManager to know 
about the currently active tool.

The API for KoTool is still mostly unused and I'm not sure what the ideas 
are behind most of the methods there. So I'd like you guys to do the 
thinking for me.

* What was the idea on how to manage multiple tools; do we want a class in 
flake that knows about active tool, for example?
* I think we need tools per view; this makes sense to me since selection 
is per view and since most tools will work on the selection, it follows 
that you need that. (or else you will end up not knowing which object to 
alter if you have different selections)
You agree to that?
* what do you think about the above proposal to move painting of selection 
to the tools ?

I'll be at LinuxTag the rest of the week, where they promised I will not 
spend a whole lot of time coding, so take your time to discuss a good 
solution without me :)

A4 template is not standard complaint

Hi all,

the A4 template (paper size) included in KOffice-1.5 is not ISO standard 
complaint. It defines a paper size as 20,99 X 29,67 cm. According to ISO 216 
it should be 21,0 X 29,7 cm [1].

The same bug is in the previous KOffice-1.4.

1. http://en.wikipedia.org/wiki/ISO_A4

Cheers,
Mashrab.
--

-- 
PGP key: www.uni-bremen.de/~kmashrab/kmashrab.asc

_______________________________________________
koffice-devel mailing list
koffice-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

Re: A4 template is not standard complaint

Thanks for notifying us; I just fixed this in svn; so KOffice 1.5.1 will 
will have real A4 pages.

ps. fixed in revision 536507 in branch.

On Tuesday 02 May 2006 11:59, Mashrab Kuvatov wrote:
> Hi all,
>
> the A4 template (paper size) included in KOffice-1.5 is not ISO
> standard complaint. It defines a paper size as 20,99 X 29,67 cm.
> According to ISO 216 it should be 21,0 X 29,7 cm [1].
>
> The same bug is in the previous KOffice-1.4.
>
> 1. http://en.wikipedia.org/wiki/ISO_A4
>
> Cheers,
> Mashrab.

--

-- 
Thomas Zander

_______________________________________________
koffice-devel mailing list
koffice-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel