Jump to content

Calligra/Libs/Flake/Tools And Pointers

From KDE Community Wiki
Revision as of 17:59, 6 December 2010 by Cyrille (talk | contribs) (Created page with 'KOffice 2.0 will, like Krita 1.x be able to work with graphics tablets. It will be possible to have different tools active for different pointers. For instance, it will be possib...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

KOffice 2.0 will, like Krita 1.x be able to work with graphics tablets. It will be possible to have different tools active for different pointers. For instance, it will be possible to assign the Pan tool to the mouse, the Airbrush tool to the airbrush stylus, the Eraser to the eraser and the freehand vector tool to the stylus.

Qt pointer overview

The different pointers that the user can use as input device get separated into two categories; the mouse and the tablet.

  • a Mouse: Any mouse, including the touchpad of a laptop. Generates QMouseEvents
  • a Tablet: Any tablet pointing device, except for the tablet mouse. Generates QTabletEvents that when not accepted morph into QMouseEvents

A tablet event can come from a variety of pointer devices, divided into two categories:

  • Pointer (pen, cursor, eraser, unknown) see QTabletEvent::pointerType()
  • Device (nodevice, puck, stylus, airbrush, 4dmouse, rotationstylus) see QTabletEvent::device()

To add to this complexity, users of fancy graphics tablets often have more than one stylus device, each with a unique id. See QTabletEvent::uniqueId() The users often use these as a painter or draughtsmen uses his bush of brushes or bristle of crayons: for different types of brush, sizes, colors etc.

If we get a tablet event we can determine what kind of pointer thingy was used, and we get the unique id for that thing. The unique id does not distinguish between eraser tip and pen tip, so it's not unique enough. Plus, not all tablets support a unique id.

In KOffice all this complexity is mapped to unique KoInputDevice objects.

Workflow

When a user has the physical choice of multiple input devices his choosing one should be enough to tell the application the goal of his actions. If a user picks up an eraser and uses that on his tablet, the result is that the application switches to the eraser and forward the user actions to that eraserTool.

For the sake of configurability we simple remember the last used tool for each unique input device and switch back to that tool when the user picks up the associated input device.

On top of that, we map those tools to the active canvas with the result that two views of the same document can mean the stylus will activate different tools. This makes a lot of sense if you try to use the opposite solution; sharing the tool between all views which gets confusing quickly due to the selected object being per view.

Requirements

  • one active tool per pointing device per canvas [done]
  • the tool is to remain active even when the pointing device leaves the canvas area, only to change when it moves over another view where another tool is active [done]
  • the pressure and other characteristics of the advanced input devices needs to be delivered to the events that arrive at the tools [done]
  • it must be possible to globally change the pressure characteristics using a curve.

Query: should we have individual pressure characteristics per type per device? Or is one basic curve enough? (we tend towards the latter). Whichever way, this/these curve(s) needs to be stored in the config file.