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

List:       koffice-devel
Subject:    Re: playground/office/flake
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-05-01 20:25:28
Message-ID: 200605012226.40074.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 01 May 2006 19:58, Thomas Zander wrote:
> 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" ?

Perhaps -- but with the idea of a repaint manager inside Flake, I've got some 
problems. I'm fairly sure that the strategy for painting objects depends a 
lot on the application -- an application like Karbon/Kivio would have 
different needs than Krita, and KWord would be different again. Flake should 
bring the behaviour, the interaction together, not become another canvas. If 
a common canvas implementation is necessary we should again look very 
seriously a qgraphicsview.

Btw, I noticed today that qgraphicsview puts the z-order in the individual 
grpahics items, too, but it also has an advanced index mechanism to retrieve 
objects.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

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