Tools

[Boudewijn Rempt]

On Tuesday 04 November 2003 14:53, Patrick Julien wrote:
> 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.

To say nothing of there not being enough tools :-)/

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

Nice and clear. I was really surprised at the status aparte of the paste tool.

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

In this scenario, why would the view even need to know which is 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.
>

But is this how an app should work? If I'm painting, I don't want to have the 
color of the pencil tool change when I select a new color for the bucket 
tool. 

And this gets more interesting when you realize that while there is one 
pointer (because of silly windowing system limitations), there are several 
active tools: one for each mouse button, and one for each end of a pen. If I 
flip the pen, I want the smear tool with its particular settings, patterns, 
whatnot, and if I flip it back to the stylus, I want the brush, pencil or 
whatever it already was back, with its settings.

I don't want changes in brush, in pattern, in gradient to propagate to all 
possible tools at the same time.

If every tool observes these changes, than the tools should know whether they 
are active, and whether they are supposed to pick up the change, or keep 
their old settings.

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

That depends a lot on how people working with a paint app thing the app should 
work. If you see every document as a sheet of paper, then it's natural to 
keep the tool settings no matter which document you have active; after all, 
just because I shuffle a sheet of paper, doesn't mean I also magically have a 
new pencil in my fingers. 

So I'd associate a set of settings with every device -- core pointer, stylus, 
eraser (don't confuse that with the eraser tool -- it's just the chewing end 
of the wacom pen, and one that I've always got associated with smear in the 
gimp), and don't change those settings because I change documents.

I would also have the tools remember their settings if they are deactivated. 
Just because the user clicks on the brush and starts painting doesn't mean 
that when he clicks back on pencil that he doesn't want his old pencil back, 
instead of one with magically updated patterns, gradients, colours or 
brushes.

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

It would be ideal if installing tools was as easy as dropping them in the 
right directory... 

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

Hey -- that's not boring, unless you share your thoughts I won't be able to 
guess them...

-- 
Boudewijn Rempt | http://www.valdyas.org/index2.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20031104/5071a6f1/attachment.pgp