Clarify how to install a release

[qadzek]

The instructions in README.md on how to install from the master branch are clear:

git clone https://github.com/rvaiya/keyd
cd keyd
make && sudo make install
sudo systemctl enable --now keyd

However, if one prefers to install a stable release, instructions seem to be absent. I tried to run the following:

curl -o keyd.tar.gz -L https://github.com/rvaiya/keyd/archive/refs/tags/v2.5.0.tar.gz
tar xf keyd.tar.gz
cd keyd-2.5.0
make

The make command seems to succeed (a bin directory is created), but an error is still thrown: fatal: not a git repository (or any of the parent directories): .git. This error has come up before: https://github.com/rvaiya/keyd/issues/602

Thanks again for this magnificent tool.

[Consolatis]

Detecting a single click as double click might be possible due to the physical button or labwc detection logic doing weird things (maybe by a jumping clock or similar) but I really don't know how the tiling case can happen unless you bound some SnapToEdge action to something like maybe drag.

Do you use a full rc.xml (e.g. started as a copy of rc.xml.all) or a minimal one using <default /> for the mousebinds? There were some changes over the releases in the default bindings so a minimal one could potentially improve things.

[tsujan]

I don't know the code, but I doubt that a single click is detected as a double click because tiling has nothing to do with double clicking in my config.

I guess it may be related to the snapping range, which I've set to 4. I'll test with a greater value, especially with 10, which is the default value for Qt.

unless you bound some SnapToEdge action to something like maybe drag.

I haven't.

Do you use a full rc.xml

Yes.

All in all, this isn't a big deal; don't waste your time on it. I'll report back with 10 as the snapping range. If it still happens with that value, then it may be worth investigating.

[tsujan]

Changing it to 10 had no effect. (EDIT: Actually, it made it worse.)

I think what's missing is a combination of drag distance and drag delay.

In Kvantum, for dragging Qt windows from anywhere inside them, I considered two factors: drag distance and drag delay. If the drag distance is greater than a value (usually 10 px), the drag will start regardless of the delay. If the the mouse doesn't move but is kept pressed for an interval more than the value of the drag delay (usually 500 ms), the drag could start again regardless of the drag distance, i.e., on slightest movement. This combination prevents an inadvertent drag and provides a "natural feeling".

[tokyo4j]

I considered two factors: drag distance and drag delay

I think we can implement drag delay.

We already have <snapping><overlay><delay><inner|outer> which defines the delay to show the snapping overlay, so we can change them to <snapping><delay><inner|outer> and make it define both overlay delay and drag delay.

I'm not sure it's worth implementing drag distance though, because we will then need to add another configuration option and record the distance every time the cursor motion handler is called.

EDIT:

Changing it to 10 had no effect. (EDIT: Actually, it made it worse.)

So I suppose your click (press & release) is easily detected as a drag (press & motion & release), but it almost never happens with my mouse. Are you aware of anything special about your pointing device that causes this issue?

[Consolatis]

If increasing the snap range made it worse this sounds like a click being detected as a drag. Does it only happen for windows very close to some screen edge? In either case a work around could be to set the snap range to 0 (e.g. completely disabling the mouse based snapping) or to 1 (mouse has to be within a single pixel of the edge in a move operation).

I am pretty sure we've dealt with this before in the case of cursor emulation for tablet pens where its very difficult to detect a click / double click as the slightest bit of movement would be detected as drag operation. I am not sure about the details here though. CC @jp7677 in case you remember the details.

[tsujan]

I logged into kwin_wayland and saw that its title-bar showed a behavior compatible to the above-mentioned combination.

Increasing the snapping range had a worsening effect only because, now, it happens at greater distances.

I'm not sure it's worth implementing drag distance though …

Maybe.

[tsujan]

In either case a work around could be to set the snap range to 0

I use mouse snapping on a regular basis ;)

or to 1

I think 1 should decrease the probability a lot. Thanks.

[tokyo4j]

I am pretty sure we've dealt with this before in the case of cursor emulation for tablet pens where its very difficult to detect a click / double click as the slightest bit of movement would be detected as drag operation.

Maybe you mean <menu><ignoreButtonReleasePeriod> which prevents unintentionally closing menu? Another possibility is <resistance><unSnapThreshold> which prevents unintentional un-maximization.

[Consolatis]

I am pretty sure we've dealt with this before in the case of cursor emulation for tablet pens where its very difficult to detect a click / double click as the slightest bit of movement would be detected as drag operation.

Maybe you mean <menu><ignoreButtonReleasePeriod> which prevents unintentionally closing menu? Another possibility is <resistance><unSnapThreshold> which prevents unintentional un-maximization.

Possibly that this was the one I had in mind, really not sure right now. I do think we had a discussion about this topic quite a while ago and I think it was about high polling mice and tablet pens (which also send lots of coordinate updates).

[tsujan]

Now I think that with 1 for the snapping range (default?), this shouldn't happen to anyone in practice. If so, there may be no need to any change. After all, keeping the code uncluttered may be more important.

Feel free to close this report if you agree, and thanks for sharing your insights.

[Consolatis]

Having a required minimal distance + canceling delay between press and release to be detected as drag sounds like a good option to me. Even if hardcoded rather than configurable by the user.

[jp7677]

Maybe you mean <menu><ignoreButtonReleasePeriod> which prevents unintentionally closing menu?

That is also the one I remember where initially the implementation didn’t worked for tablet pens.

[tokyo4j]

Having a required minimal distance + canceling delay between press and release to be detected as drag sounds like a good option to me. Even if hardcoded rather than configurable by the user.

OK, then we have two options to fix tsujan's issue:

1. Change <snapping><overlay><delay><inner|outer> and <snapping><delay><inner|outer> and apply the delay not only for snapping overlay but also for actual snapping
2. Having a required minimal distance + canceling delay between press and release to be detected as drag

And now I prefer (2.) as a more general solution.

FWIW, Openbox has <mouse><dragThreshold> which defines "How many pixels you need to drag for it to be recognized as a drag operation". But having hardcoded value as a starting point sounds good.

EDIT: One concern of (2.) is that the distance of cursor movement required for a maximized window to be un-snapped becomes <mouse><dragThreshold> + <resistance><unMaximizeThreshold>, because the former is applied before Move action and the latter is applied after it.

[Consolatis]

I think the overlay delay is only for visual feedback and should not influence the snapping itself. And as this is a more generic issue and just happens to affect snapping in this case due to the mousebind being bound to the Move action I feel like 1 isn't the correct solution.

The values proposed by @tsujan (10px + 500ms) sound good to me. So we'd need to have access to the coordinates and timestamp for the press event and then react to it in the cursor move event. From a quick look we already have press_msec and the cursor context in seat->pressed. The cursor context only has sy and sx though which are likely ~~empty~~ wrong (as they are the node relative coordinates) on a SSD press.

EDIT: One concern of (2.) is that the distance of cursor movement required for a maximized window to be un-snapped becomes <mouse><dragThreshold> + <resistance><unMaximizeThreshold>, because the former is applied before Move action and the latter is applied after it.

Good point.

Edit: The cursor context also has the node though so we should be able to derive the actual global coordinates from those values.

[johanmalm]

Thanks for analysis. Feels like we should implemented <mouse><dragThreshold>. Openbox defaults to a value of 8.

Ref:

• https://openbox.org/help/Configuration#Mouse
• https://github.com/labwc/labwc/blob/24c199aeefa2197c4e7831ac6915c84c2a1f3558/src/input/cursor.c#L602-L615
• https://github.com/labwc/labwc-scope/blob/main/README.md#29-configuration---mouse

[UrbanDesimator]

On a similar them can you tell me how to disable doubleclick title maximise please. I have tried the code in the pastebin with "none, empty and blank" minus the # with no success and not found anything in docs. I could not work out how to get github to allow the code in comment tried code `` which did't work. Thanks

https://pastebin.com/x1Kg2Eq8

[tokyo4j]

@UrbanDesimator You can overwrite the default mousebind with an empty mousebind:

    <context name="Title">
      <mousebind button="Left" action="DoubleClick"></mousebind>
    </context>

If you still cannot make it work, open a discussion, as your question is a bit out-of-topic.

As for posting codes in github, see github documentation.