Code review comment for lp:~mir-team/mir/cursor-spike-phase-2-resubmit

On Thu, May 8, 2014 at 2:02 PM, Daniel van Vugt
<email address hidden> wrote:
> (6) The API implication that a surface has a single cursor setting is
> misleading. Obviously the cursor will vary over the surface depending
> on the widget. So although the one-cursor-set-per-surface sounds
> wrong, I now realize it does work so long as you make the app/toolkit
> do the hard work of changing the cursor as it moves.
>
> On the other hand, Mir does already have the concept internally of
> input regions (still needs work). But since we already have multiple
> input rectangle support per-surface in libmirserver
> (BasicSurface::input_rectangles), wouldn't it be better to expose
> that to the client API and simply attach a MirCursor to each input
> rectangle? Then the server could do the cursor changes for you. I
> think that's what X and Win32 does... And it certainly eliminates the
> redundancy of asking every toolkit to re-implement cursor tracking.

While that used to be true, I don't think it is still the case - GTK at
least moved away from multiple X11-protocol-windows per window some
time ago. Sometime late in the 2.x series, IIRC.

While exposing subrectangles is appealing for other reasons, I think
the toolkit boat sailed some time ago :)