[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:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-10-31 15:16:36
Message-ID: 200610311616.39059.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 31 October 2006 13:23, Thomas Zander wrote:

> The concept behind a resource associated with the canvas sounds fine to
> me.
> Having it properties based (name/value pairs settable/gettable without
> an exact name) makes it more extendable and allows you to not have one
> class per app. I'd hate to see app-specific casts in tools as that
> makes it depend on the libraries of that app.

Yes, me too. But I need a really quickly implemented temporary solution 
now :-(.

> 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 -- I got bitten by that when I wanted to add a user QEvent type 
and had to find one that wasn't used before in kdelibs. If these properties 
are strictly per canvas (which is per application), then there is no problem 
with enums, since the set of canvas types is not extensible by third parties.

But I'm not sure that's the case. The problem is this: there are per-canvas 
properties that are only applicable for a (set of) shape(s) or tool(s). 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.

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

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

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.

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