From kde-kimageshop  Wed Oct 15 12:58:43 2003
From: Patrick Julien <freak () codepimps ! org>
Date: Wed, 15 Oct 2003 12:58:43 +0000
To: kde-kimageshop
Subject: Re: class dependencies
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=106622323409476

On October 15, 2003 07:29 am, Michael Thaler wrote:
> Hi,
>
> Yesterday I tried to make a small project using KDevelop3. I intend to
> write a very simple program that uses the krita rendering classes. I
> just want something that allows me to load/save an image and to draw
> single points etc.
>
> The main purpose of this is to have something simple to play with,
> e.g. find out how the rendering stuff really works, find out how quick
> the screen is updated for different tile sizes etc.
>
> It was easy to import KisTile, KisTileMediator, KisTileMgr,
> KisPixelData and other basic classes. It is not easy at all to import
> KisPainter and KisPaintDevice because these classes depend on
> KisLayer, KisImage and KisDoc. KisImage depends on KisLayer,
> KisPaintDevice, KisPainter and many other things. KisDoc depends on
> KisImage, KisLayer, etc. while KisLayer depends on KisImage and
> others.

The layer or image only needs an image to indicate it's owner, nothing else.  
You have a constructor that takes no KisImage argument, i.e. no owner, hence 
it is optional.

I don't see any reference from KisPainter to KisLayer or KisDoc from 
KisPainter.  The reference to the owning image have to do with the undo 
commands, not the painter proper.
I don't see any reference from KisPaintDevice to KisDoc, except again for undo 
commands, this is also optional.  No references to KisLayer.  The KisImage, 
again, is for undo.

>
> This makes it really hard to reuse any part of Krita and it also makes
> the code very hard to understand. Why are there all these circular
> dependencies? IHMO this is not a good design at all.

Really?  I guess I should read scrap that composite design pattern after all 
and just copy & paste that code then :)

However, you do have a point about KisPaintDevice using a KisDoc, KisDoc 
should inherit privately from an interface to handle this.

The owning image aggregate could be made a KisPaintDevice instead of a 
KisImage, although it helps encapsulation, it hurts correctness here since we 
don't want an owning image to be anything else than an image.

>
> I think there really should be a hirachy:
>
> - KisPaintDevice is what KisPainter uses for rendering.

	Nope, KisPainter is what you use to paint on a KisPaintDevice.

> - KisLayer inherrits KisPainter and offers some additional methods.

?!?  KisLayer inherits from KisPaintDevice right now.

> - KisImage contains several layers and has methods to manage these
> layers.

That is what is has, but KisImage is also a KisPaintDevice.

> - KisDoc contains one (or more KisImages)

That is what is has.

>
> KisPainter and KisPaint device should know nothing about KisDoc and
> KisImage etc.

The rational for KisImage is given above, but you have a point about KisDoc 
tho.

>
> Ciao,
> Michael

_______________________________________________
kimageshop mailing list
kimageshop@mail.kde.org
http://mail.kde.org/mailman/listinfo/kimageshop