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

List:       koffice-devel
Subject:    Re: More about Events, tools and pointer devices
From:       Thomas Zander <zander () kde ! org>
Date:       2006-10-31 15:38:32
Message-ID: 200610311638.32718.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 31 October 2006 16:16, Boudewijn Rempt wrote:
> On Tuesday 31 October 2006 13:23, Thomas Zander wrote:
> > Take a look at libs/kotext/styles/Styles_p.h and the users of that
> > class in the same dir.
> > Using an enum allows you endless extensibility, even without having
> > extra methods in the class.
>
> As per earlier discussions, I'm not fond of enums because of the
> possibility of clashes

 >The problem is this: there are 
> per-canvas properties that are only applicable for a (set of)
> shape(s) or tool(s).

That sounds really weird to me, and something I'd love to avoid if at 
all possible.

> Like border-width for all shapes with a border 
> or paintop for all shapes that work with Krita's paint tools. And the
> set of flake shapes is extensible with third-party plugins.

I don't think you need to register that per canvas. You can register 
that directly in the Tool. As the selected shapes are registerd in the 
tool already, and of their (temporry) properties can be stored in the 
tool itself.
In other words; changes of properties in a tool itself don't have to go 
via the canvas-repository as there are no other tools that find that 
info interresting until its actually committed to the model (aka the 
actual shapes). After which any tool can just fetch it from the model.

So, as we don't have GUI items that are not directly linked to a Tool, 
there are no cases where flake-plugins want to broadcast changes. They 
just tell the tool directly.

> How should we handle this? Both technically, and interaction-wise, I
> mean.

I don't see any problem with an enum. All widgets that change settings 
either operate on the shapes directly, or have standardized (koffice 
wide) properties.

> > Last meme for this thread; make this KoCanvasResources class a
> > QObject and make it emit a propertyChanged(PropertiesEnum p, const
> > QVariant &v); so tools can connect to that.
>
> Of course. Philosophical point of order: should all tools for a
> canvas always be connected to that signal, or should only the current
> tool be connected to it. My idea is the former, even though that may
> cost us a bit in performance.
I agree on the former.

> In any case, I've started on an initial, simple implementation of the
> class along the lines you outlined. We can extend, fix & improve
> later, I really need something simple that works now.

Fine with me. Your experience with a hacky implementation will be used 
for a more scalable version, then ;)
-- 
Thomas Zander

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