Add click-at-start and click-at-end as alternative to continual mousing to highlight text

[astent]

If the units of annotation are long, or the annotator has shaky hands or tendinits, then continual mousing to highlight text may introduce errors in the annotation. As an alternative to mouseDown-drag-mouseUp, could clickToStart-and-ControlkeyplusclickToEnd be used? The annotator would click at the start of the segment, then hold the shift/ctrl/alt key down and click at the end of the segment. Javascript can pick up the control key as well as the mouse event.

I think this a very sensible suggestion and something we should include. +1 and assigning to @amadanmath for v1.4. Also, we need to discuss which modifier keys that are still available and maybe even open another issue for how we will proceed with assigning key bindings.

[spyysalo]

This is already available: hold down CTRL on the first click, release CTRL, and hold down SHIFT for the second click. For documentation, search for "CTRL" in http://brat.nlplab.org/manual.html .

Actually, now that I check this, the documentation is somewhat incomplete, suggesting that this only works together with double-clicks, which would limit the feature to spans beginning and ending at token boundaries. Labeling as doc and lowering priority.

Also, we might consider adding some visual hint that this type of selection has started.

[amadanmath]

@spyysalo: Two questions:

There's some problems with ctrl+click thing, in that Macs think you want a right-click, and it pops up a context menu. For now, would it be okay if we treated Ctrl, Alt and Option in the same way, as synonyms, for this purpose? Then users can choose the one that doesn't do weird things on their system.

Also, with a tiny patch, I can make it so that we also have similar thing for arcs: ctrl/alt+click for start, then click for end. Want?

[spyysalo]

@amadanmath : yes please to having this for arcs :-)

Just one thing: I'm not sure if we want to commit all three of ctrl+alt+option to this function, as there may be other uses for KB+mouse combos in the future. How about leaving alt unused for now?

[amadanmath]

Option == Alt, so I can't separate them unless I go sniffing for user's system. (Not that I can't do that, just saying.)

So I could have Mac people use Option where Win people use Ctrl; but then if we bind Win's Alt to something, what would we bind Mac UI to?

Alt-ernately, I could make it so that single click on annotation (without a modifier) triggers the arc mode, but we had some (as of yet completely hypothetical) thoughts about confirming tentative annotations using single click...

But the problem remains that my current machine, a Mac, insists on popping a context menu every time I do what you just described:

This is already available: hold down CTRL on the first click, release CTRL, and hold down SHIFT for the second click.

so providing an alternative to Ctrl seems like a Good Idea (tm). It appears no-one tested this on a Mac before :)

[spyysalo]

OK, I was confusing option and command on the mac KB and didn't remember that CTRL-click is hard-bound to a context menu in OSX.

I don't like two "plain" single-clicks for arc, we have a bunch of ideas for single-click that this would block, and I expect this would give a lot of false positives.

Reserving ctrl+alt(/option) for this could be OK, but I'm leaning a bit more toward having a mac-specific solution rather than losing the ctrl/alt distinction everywhere. Would command be usable for this? @ninjin : any preference?

@spyysalo: No preference really, I know that Mac has "special needs", so I won't go against treating them as special.

[amadanmath]

Macs now use Cmd instead of Ctrl everywhere. This includes Cmd-F. Cmd-G and Cmd-K used in search, as well as using Cmd prevent the Span dialog upon selection.

In addition, Ctrl (Cmd) click on a span will now initiate arc mode.

[spyysalo]

Works for me, thanks!

@astent : if you're willing to try this out, you can either pull the most recent master or download a nightly build from http://weaver.nlplab.org/~brat/nightlies/ tomorrow.

[spyysalo]

@amadanmath : after trying this for a bit, I like the CTRL-click + click for arcs a lot. In fact, this makes the CTRL-click + SHIFT-click for spans seem pretty cumbersome by comparison. Would it be hard to change this also to CTRL-click + click?

Also, while we're at it ... would it be hard to have KB shortcuts for arc types active during arc drag, so that the arc type dialog could be avoided by just clicking on the appropriate key while hovering on the "target" annotation?

[amadanmath]

after trying this for a bit, I like the CTRL-click + click for arcs a lot. In fact, this makes the CTRL-click + SHIFT-click for spans seem pretty cumbersome by comparison. Would it be hard to change this also to CTRL-click + click?

Yes. Maybe. I don't know.

The thing is, we're relying on normal selections. OS says selections are extended via shift-click. So it's actually not our code doing anything on shift, just detecting a selection. The ctrl in that case is detected by us, and just prevents a popup (so that you get the chance to do your shift-click later). It might be possible to manipulate the selection directly when we detect a simple click, but I'm not very confident in my ability to do so. So, very hard.

Unless - we did not manage to get the normal selections working on Firefox, and we're using an alternate mechanism we received from Mr Scerri. AFAIK, we never really looked at it past what I described in #418; it might be adapted to other browsers as well, and we might stop relying on OS selections. If we do that, then we can do whatever the hell we want. :p However, as I noted in the linked issue, it is not quite the same experience, and we might run into problems. Thus, hard.

Also, while we're at it ... would it be hard to have KB shortcuts for arc types active during arc drag, so that the arc type dialog could be avoided by just clicking on the appropriate key while hovering on the "target" annotation?

Probably possible; you might want to open a separate issue.

Currently the keys map to selecting the appropriate radio button; but no radio buttons are shown. If we can just say that we're manipulating the hidden radio buttons, it should be simple. If not then a rethink is in order, becomes harder. Experimentation needed. :p