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

List:       koffice-devel
Subject:    Re: Events, tools and pointer devices
From:       Thomas Zander <zander () kde ! org>
Date:       2006-10-13 11:04:23
Message-ID: 200610131304.27436.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 12 October 2006 22:50, Boudewijn Rempt wrote:
> I'm working to make flake work with tablets, so I can port Krita to KoTool.
> However, it's complex thing, so I'm sharing my thoughts with you lot:

Nice overview, thanks for working on this! :)

> The tool manager needs to map between all known devices (mouse, tablet
> uid's) and all tools, so the user can use the pan tool with the mouse and
> the paint tool with the stylus.

We currently just forward the events from the canvas to the currently active 
tool.
Which means that we can't change tools based on input event without coding 
that in each tool there is. (bad idea).
This means that we should rewrite all canvasses to redirect to a proxy class 
(toolmanager probably) which will change the current tool if needed before 
passing the event on.

> Additionally, if the user has more than one 
> stylus (for instance) they want to have a thick red screening brush for one
> stylus and a thin black over brush for the other stylus. Therefore, for
> every discovered unique device, we need the complete set of tools:

> map ( class KoInputDevice(pointertype, tabletdevice, uid) : vector(tools) )
> -- this is complexer than the old KisInputDevice which only distinguished
> between pointertype.

Agreed;
we currently have a:
    QMap<KoCanvasController*, QMap<QString, KoTool*> > m_allTools;
where the QString is the id from the KoToolFactory.

In other words; one tool per canvas, per tool-type.
To also have a tool per inputtype we should alter this to:
    QMap<KoCanvasController*, QMap<QString, QMap<QString, KoTool*> > >
Where I suggest we have the second QString be a concatenated pointertype and 
tabletdevice id's.  (something like "12-1").

> Only one device can have the current pointer: the difficulty is in
> determining which device the user has in their hand. (Krita gets it wrong
> sometimes). This can be done with the TabletEnterProximity and
> TabletLeaveProximity events. These are delivered to QApplication, not the
> widget, but we need to be notified of ourselves them anyway.
4.2 got some specialized methods for that in QApplication. See for example how 
KoToolManager::movedFocus() is reached. The connect is:
    connect(QApplication::instance(), SIGNAL(focusChanged(QWidget*,QWidget*)),
        this, SLOT(movedFocus(QWidget*,QWidget*)));
Pretty sweet ;)

> The toolmanager therefore needs to somehow determine which KoInputDevice
> instance the user is actually using

KoInputDevice?
Since thats a perfect one to one mapping to a KoTool instance, I kind of 
assumed that we don't need another class.

> Krita uses X11 directly to get its events because plain Qt3 didn't give us
> enough events. We are not certain whether Qt4 will do, but we are going to
> try. Qt4's tablet event is much improved in any case

I'm aiming for using Qt4.3 for KOffice2 so any missing things / bugs should be 
pushed to and fixed in Qt if possible.

> Whenever a tablet event arrives on the canvas, pressure and other
> characteristics should be changed according to the users "fist" or
> preferrer pressure curve. Do we do this in every canvas, or is their an
> easy way to make this generic for all of KOffice? Remember that we don't
> have a shared canvas implementation.

As I pointed out at the start of this email, we will have to have a proxy that 
takes the events and processes them to pass onto the actual tool. I'd say we 
can do this pre processing there.
But my first idea was to actually put this adjustment in the constructor: 
KoPointerEvent(QTabletEvent *)

> Any pointer event should then be passed onto the tool. Difficult decision:
> should we make a generic pointer event that includes all tablet
> information, or add a QTabletEvent handler to KoTool.h? Krita does the
> first, making life easier for tool implementors, but QTabletEvent is so
> rich, we may want to deliver it as-is.

I'm very much against that as I think the tools should treat all events as 
tablet events, including mouse events.  (naturally the toolmanager uses the 
events directly to do switching of tools).
A mouse event is just an event with normal pressure and no tilt.

Adding a couple of getters in the KoPointerEvent and a constructor based on 
the QTabletEvent was what I had in mind when designing this stuff.

> What have I forgotten? What shall we do?
Thinking about it a little longer, the proxy class I suggested above can be 
just one or two methods.
So; what about
  KoPointerEvent *KoToolManager::handle(QInputEvent *);
This method will not only be a simple factory method but get out the mouse and 
tablet events to switch inside the toolManager.

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