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

List:       koffice-devel
Subject:    Re: flake canvas
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-03-31 6:21:58
Message-ID: 200603310821.58350.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 31 March 2006 04:50, Thomas Zander wrote:

> Thats a lot of methods; you sure that the flake objects will need all of
> those objects?
> What about only adding the methods that the flake library will actually
> call. ?

The thing is -- these are the methods that we have noticed we need already. In 
Krita, that is. Not offering them in an interface class would mean the same 
functionality would be implemented all over the place in the different 
applications, but implemented they would.

Note that these are mostly methods for use by the tools; not the flake objects 
themselves.

>
> One comment on the API;
>
> >     /**
> >      * @return the value of the horizontal scrollbar.
> >      */
> >     virtual qint32 horzValue() const = 0;
>
> Please don't abbreviate method names;

Sure, no problem. (No need to go on and on and on and on and on about it 
either :-))

> Other that that; I would have to read a lot of code in flake to answer the
> need for a canvas; so far I'd like to avoid it based on the idea that
> flake objects should be like OO objects and thus self contained.
> I'd like to know what kind of things the flake lib needs to know from the
> canvas; and why...

I don't want a canvas in flake: I want an interface for the tools to use. It 
looks not unlikely that the tool system will look a lot like Krita's tool 
system (but with the lessons learned applied), so it make sense to look at 
the way Krita makes sure the tools don't need to know about any actual canvas 
implementation.

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