Flake event handling changes - draft proposal

[Tomas Mecir]

As discussed on irc earlier today, here's my initial proposal to improve
event handling in flake tools. Very much a work in progress.

Problem:
The current method of handling flake tools feels very rigid and inflexible,
which gives a rather poor impression from the usability standpoint. I've
been going over the related code during my yesterday's attempts to improve
the related functionality somewhat in Sheets, only to come to a realisation
that doing so will require a series of improvements in flake itself.

This document contains the initial draft of my proposal to do exactly that.
It is obviously meant to be introduced after the 3.0 release, as a change
as significant as this cannot be merged this close to the 2.9 release.

Usability is the main motivation here, no actual new functionality will be
added (initially, at least, as I believe the changes will allow new
functionality to emerge). As I note, currently the shape tools are fairly
isolated from each other, and the result feels very clumsy. For example if
the user is editing a text document and wants to resize a picture, he needs
to find the shape manipulation tool in the panel, resize, then reselect the
former text manipulation tool. With the proposed changes, he will be able
to simply move the mouse over the picture (and maybe click on it, though I
am a fan of the hover effect here), resize it, then get back to text
editing right away. Many more similar use cases can be devised.

>From the technical standpoint, the main change is that events shall be
processed by all applicable tools, rather than only the active tool. The
tool manager will serve as the arbiter, deciding which tool actually
receives the event based on information that the tools provide. The concept
of the active tool remains, but becomes much less significant, as users
will be able to use functionality offered by these tools even if they are
not currently active (this mostly applies to the shape manipulation too,
which I would ideally like to make entirely transparent, if possible).

Technical list of changes - some of these may need alterations:
- We construct a priority list of tools belonging to each shape - some
tools are generic, most are specific to a single shape (this mostly already
exists, though some priorities will change)
- Event processing gets split into two stages
- Stage 1 - preprocessing:
  * here we query all the tool/shape combinations that are at the affected
(clicked, whatever) position, topmost shape first; for keypress events, we
query the active tool (TODO - maybe more than that?)
  * each tool determines whether it wants to process the event, and its
priority in doing so
  * the tool will mainly decide this based on whether it is active, most
tools will just be idle while inactive
- Stage 2 - actual event processing:
  * the tool with the highest priority receives the actual event
  * if the tool returns that it did not process the event after all, the
next tool receives it, etc (this may not even be necessary, but it may
simplify the tool logic)
  * upon processing the event, the tool can return one of these return
codes: "not processed", "processed", "processed and make this tool the
active one"
  * these return code options are one of the most important parts of this
proposal - they will allow us to switch between tools much more fluidly
than currently, and it will also allow some tools to process events without
actually becoming active; for example, we could allow the manipulation tool
to process shape resizing attempts, while still keeping the editing tool
active
- Additionally, there will be a stack of "default" tools, which will be
processed if the user clicks in the area where no shape is located (this is
mainly for Sheets, as its main canvas is not a shape, but other apps may
benefit too)
- Furthermore, some events will be partially processed by the tool manager
itself - this will mainly affect mouse dragging; each tool currently
processes this itself, which will no longer be feasible under the new
rules. As such, the mouse movement event will also include the initial
point of the drag action - this will allow us, for example, to have click
events routed to one tool, while allowing 'click and drag' functionality to
be processed by another (e.g. situations where clicking would be processed
by the editing tool, while dragging would cause the shape to be moved).
- To be determined: need to decide if we want to keep the "currently active
shape" concept at the tool level (ie, each tool has its own), or move it to
the shape/tool manager level; I'm thinking the latter. Overall I'd like to
de-emphasise the "currently active shape" concept as much as possible,
letting users e.g. fluidly work on multiple shapes at once, but this may
not be feasible, mostly because of keyboard shortcuts.

This is just the initial draft, so please point out anything obvious that I
may be missing.

I also volunteer to get all this done and working :)

Thoughts?

/ Tomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20150202/0f091a08/attachment.htm>