Krite website

[Patrick Julien]

> Thanks! It's the kind of thing I'd like to find when I get involved with a
> pre-existing project :-).

I've been thinking about tools since I read this document.  Allthough a lot of 
work has been done to generalize them, but it's still not enough.

Originally, the tools we're members in KisView and they we're created from 
there.  The state of the tools we're in KisDoc.  I changed this so that tools 
had their state and KisView called a factory to create tools.  This was a 
long and boring task, however it gave an abstraction so that eventually tools 
could be plugins.

However, that being said, this is what I would like to do:

1) The paste tool is still a special case since we need it for the "Paste" 
menu action.   I want the paste tool to become a simple adapter.  I want to 
create some kind of ClipboardManager class first.  Then the paste tool only 
becomes and adapter that conforms the ClipboardManager manager to the tool 
interface.

This means the view can now use the ClipboardManager instead of creating the 
paste tool directly.  The paste tool is no longer an exception.

2) I want to remove the new methods Boudewijn added for setting attributes on 
tools.  I believe that the current settings should be broadcasted and not 
set.  I would like KisView to become itself a subject in the observer design 
pattern.  Every tool now becomes an observer.  This, I think, offers a lot of 
advantages than just merely setting the state on the active tool.

The main ones being:

i) the view doesn't need to know about more than the current tool.
ii) Tools that have dialogs, and all tool dialogs should be modeless, can 
change to reflect the current state.

So basically, if every view is a subject and every tool an observer, everytime 
the view changes state, we can adapt all the tools to reflect this.

However, this leaves one question unanswered:  If tools are single instances 
and koffice applications can have multiple views and frames, how do we 
actually have tools that play well with this?

I believe the answer to this lies in the memento experiment that was cooked up 
for tools a while back.  We simply keep one memento per tool per view.  
Hence, everytime we switch view, we just take a snapshot then reset all the 
tools to the memento of the view receiving focus.

Finally, I would have like to use signals and slots for this broadcast, but 
I'm not convinced I'll be able to.  If I can't, I would use a single 
std::multimap in some kind of mediator for all the connections.

3) I want to use the Extension Interface pattern more, the goal here would be 
for KisView and KisDoc to no longer be exposed from anywhere outside of the 
'core' directory, including subdirectories of core.   This would make the 
tools a lot more independent.  This has already started with KisDoc 
inheriting privately from KisUndoAdapter.

KisView should inherit privately from
	KisToolControllerInterface (or maybe just hold a KisToolController instead?)
	KisMementoCaretakerInterface
	KisCanvasStateSubject

KisToolInterface has a standard is-a relationship to
	KisMementoOriginator
and inherits privately from:
	KisCanvasStateObserver

4) Load the tools externally.  Think this was is pretty obvious, no 
explanations needed here.

I've been thinking about some other parts of krita too, anyway, don't want to 
bore anyone either :)