Good change in my opinion, experienced this problem myself even with slower units.
Might need to check that we don't move th mouse to follow the unit and still accept that as a second click though.

When I need to select a moving unit and all with his type, I just press F and double click on it.

I think, the suggested way is less obvious for players, because mouse is clicked outside of unit, but still selects something (looks like a bug/hack, no?). So I could suggest to not modify double click, but use something like Alt+LMB on any unit to select all of this type, then it'll be obvious for players.

In D326#12839, @vladislavbelov wrote:

When I need to select a moving unit and all with his type, I just press F and double click on it.

I think, the suggested way is less obvious for players, because mouse is clicked outside of unit, but still selects something (looks like a bug/hack, no?). So I could suggest to not modify double click, but use something like Alt+LMB on any unit to select all of this type, then it'll be obvious for players.

In particular I'm not fond of that new pixel distance constant. We already have three different way to detect doubleclicks. If they were merged as proposed in #4414 and if this feature request as proposed by causative was accepted, then it could still be implemented by saving the entity type on the first click and then selecting all of them on the second click.
Do have to say though that doubleclicking and alt+doubleclicknig on units to select all of that type seems quite intuitive, while having to use the follow unit function for fast moving units seems to be a workaround too.

There could also be a hotkey to select all units of the current type, so we could have a selection of a single unit (or a lasso selection for extremely fast moving cavalry) and then pressing a hotkey an arbitrary time afterwards to solve the issue.

Alt+LMB might work too, but must be checked whether it conflicts with something (doesn't iirc).

That was an already existing feature that I just preserved. It looks like disabling camera follow when a new unit is selected, was added in revision 9764.

Build is green

Updating workspaces.
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!

http://jw:8080/job/phabricator/850/ for more details.

@causative ping, #4631

I've had a lot of problems with double clicking to select units in a22. I double click but it doesn't select all the units, so then I double click again, but still no luck. So I triple click or quadruple click and then it selects all the units for a moment before going back to one because I've clicked once too many and cycled through. It's very frustrating.
I'll try to experiment in the coming days, see if I can consistently reproduce the issue, and maybe revert this patch and see if that helps. (I guess it's possible that this was an issue in a21 too and I just don't remember.)

Possible hint: I use a pen rather than a mouse, so often (or always?) there's some tiny jitter between clicks.

It is a problem with jitter. For example, in an earlier version causative used a squared distance threshold of 10, which meant offsets of (0,3), (1,3), and (2,2) were acceptable. But to increment "clicks" it seems the mousebuttondown offset can only be (0,1) or (1,1). With my pen on a small tablet and large monitor, I miss that all the time.

Failure, mousebuttondown offset (0,2):

clicked entity = 1788, ev = ({type:"mousebuttondown", button:1, state:1, x:341, y:562, clicks:1})
clicked entity = 1761, ev = ({type:"mousebuttonup", button:1, state:0, x:341, y:563, clicks:1})
clicked entity = 1761, ev = ({type:"mousebuttondown", button:1, state:1, x:341, y:564, clicks:1})
clicked entity = 1761, ev = ({type:"mousebuttonup", button:1, state:0, x:341, y:564, clicks:1})

Successful double-click, mousebuttondown offset (1,1):

clicked entity = 1776, ev = ({type:"mousebuttondown", button:1, state:1, x:332, y:675, clicks:1})
clicked entity = 1771, ev = ({type:"mousebuttonup", button:1, state:0, x:332, y:674, clicks:1})
clicked entity = 1771, ev = ({type:"mousebuttondown", button:1, state:1, x:331, y:674, clicks:2})
clicked entity = 1771, ev = ({type:"mousebuttonup", button:1, state:0, x:331, y:674, clicks:2})

I didn't revert the changes, but I'm guessing the "doubleclick hack" that was removed was making things work okay back in a21.

But to increment "clicks" it seems the mousebuttondown offset can only be (0,1) or (1,1). With my pen on a small tablet and large monitor, I miss that all the time.

The idea was that we shouldn't reinvent the wheel (i.e. not hardcode timeouts and mouse distances between clicks), but use SDL to parse input events.
I assume that your unintentional-doubleclick issue might therefore also apply to other places that use SDL to detect doubleclicks (if the multiplayer lobby doubleclick join bugs, the issue might just be hidden by not enough things using doubleclicks).
So the generic solution to me seems to add a new config option to change the interval with SDL.

However I couldn't find any way to modulate the mouse settings with SDL anywhere. Apparently there are undocumented environment variables, like SDL_VIDEO_X11_MOUSEACCEL.
Apparently there is or has been (SDL 1.2 instead of SDL2?) this function SDL_GetClickInterval(). But I couldn't find a setter.
https://forums.libsdl.org/viewtopic.php?p=44357
https://discourse.libsdl.org/t/click-count-and-events/20826/8

It's hardcoded by SDL in SDL_mouse.c: SDL_double_click_radius = 1. https://fossies.org/linux/SDL2/src/events/SDL_mouse.c There was some discussion on changing the value here: https://forums.libsdl.org/viewtopic.php?p=51852. Perhaps someone could submit a patch to SDL to increase the default radius and add a setter.

In D326#31792, @causative wrote:

It's hardcoded by SDL in SDL_mouse.c: SDL_double_click_radius = 1. https://fossies.org/linux/SDL2/src/events/SDL_mouse.c There was some discussion on changing the value here: https://forums.libsdl.org/viewtopic.php?p=51852. Perhaps someone could submit a patch to SDL to increase the default radius and add a setter.

Good research causative! In that file we can also find SDL_SetDoubleClickTime, it should be exposed as well.
Ubuntu 16.04 still ships with SDL 2.0.4, while 2.0.5 is released since a considerable time. So either we'd have to make use of the new function optional or give the distribution an incentive to update SDL.
Someone could write a ticket to keep track of this.

It's not fixed in SDL 2.0.5, we'd need to submit a patch to a future SDL version. Ubuntu 17.04 does come with SDL 2.0.5.

Double clicking has been working much better now that I know I need to click in the same spot twice. It's not perfect (because of the small radius), but it's not frustrating anymore.

Refs rP24698