[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Fwd: Re: playground/office/flake
From: Boudewijn Rempt <boud () valdyas ! org>
Date: 2006-05-02 19:08:29
Message-ID: 200605022108.29792.boud () valdyas ! org
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/mixed)]
Hm. This one never seem to have arrived.
--
Boudewijn Rempt
http://www.valdyas.org/fading/index.cgi
["forwarded message" (message/rfc822)]
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 #10 (application/pgp-signature)]
[Attachment #11 (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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic