Flake event handling changes - draft proposal

[Boudewijn Rempt]

On Tue, 3 Feb 2015, Inge Wallin wrote:

> Hi Tomas,
>
> In Words this default operation is text editing and in sheets cell editing. In
> Stage, it would be the same as in Words, except the text boxes are actually
> movable and resizable so they are selectable. In Karbon and Flow everything
> you do is edit shapes, so there is no default operation other than deselecting
> all shapes.  (I could be wrong here, please inform me if I am.)

Well, you're missing Krita in your list...

When working on flake, people really should keep Krita in mind _all the 
time_, because Krita, right now is an application that is used by hundreds 
of thousands of people. It might have escaped people's notice, but Krita 
is not just the biggest Calligra application, it is one the biggest KDE 
projects at the moment.

And any changes to KoToolManager are _really_ dangerous. The code is 
extremely convoluted, complicated and there are hacks around issues all 
over the place that have to do with tool activation. The problem is that 
Thomas Zander's original tool manager design was typical, and the 
next, bigger, problem is that flake imposes one interaction model on a 
set of applications that simply shouldn't work the same way.

Now the right solution might be fork flake in two: one flake for 
krita/karbon/flow (and it might even be a good idea to just drop karbon 
and add the karbon-specific functionality to Krita's vector support) and 
one flake for office apps. But I wouldn't do that until after the 3.0 
porting. The port should be done without any refactoring, otherwise we'll 
be in KOffice 2.0 territory again!

> The good thing about this solution, as far as I can see, is that it would mean
> very small changes to flake and none to any shape. So this should be possible
> to get in before 2.9. We shouldn't be doing this now, but the current user
> interaction problems are so horrible that I think we should make an exception.
> And this is especially since 3.0 will probably be quite unstable and buggy and
> should be regarded more like a tech preview than a real release.

No! Don't even think of it -- we should be releasing, not tinkering with 
the interaction. Sure, it's all horrible, but it's been horrible since 
2006, which is almost nine years. Let's not break stuff just when we're 
about to release. I'm already getting dozens of pings every day about when 
we're finally going to release Krita 2.9.

Boudewijn