initial refactor of Interactions.qml to add better support for touch screen gestures #114
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: zach/z-bar-qt#114
Reference in New Issue
Block a user
Delete Branch "feat/improved-gestures"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This reworks the way Interactions.qml works under the hood, changed from using a single large
MouseAreato multipleDragHandlerandHoverHandlertypes. Shouldn't break any current functionality.x < -20-1and+1respectively, depending on active workspaces on attached monitors.I will most likely add configuration options for customizing both the gesture actions and drag thresholds.
Known issue:
Currently if a workspace is focused but there isn't a toplevel window which is focused, the gestures will not work correctly due to the input handler dropping inputs when the
centroidpoint leaves the border bounds. This is unfortunately a Qt/Quickshell bug that would require ugly workarounds to fix.It works well. The only part that is a bit iffy is doing the two finger gesture, especially with a thin border. It was my suggestion to do two fingers, feels a bit bad. Another suggestion could be:
The notification center can be opened from the bar button itself. The only semi-conflict would be that swiping down now opens the settings window, which does not hide the nc-button, so that is fine for now.
Overall, I approve.
@@ -87,3 +84,2 @@target: nullif (pressed && dragStart.y < bar.implicitHeight) {if (dragY > 20)Could this value also be a variable that takes a percentage of horizontal pixels on the display (or size of display eg a 14 inch display vs 24 inch).
Was it intentional to make this comment on line 89? Because then I don't really know what you mean, since that is deleted code.
Ah, yea you are right. Sunlight made it hard to see when I made the comment. Line 93 seems like the added relevant code.
I meant; how many pixels are needed in a swipe motion before it is recognized (if it is 20px)? My original comment speaks on that.
To add to this, I reread the original post. My question stands if this could be dynamic depending on display size for example.
Does it work better with larger borders? Maybe 4 or 6? The issue is mainly that it shouldn't have exclusive control over too much of the borders of the screen, and unfortunately Quickshell has no way of passing pointer events to windows. Otherwise I could've had larger activation borders without using more space.
Yes, it is better with larger borders. That makes me unsure what way would be a passable way of changing workspaces and share that space with the nc. Perhaps there is no good way at this moment.
Currently, a single swipe can move more than one workspace. In some cases, it moves up to 10 workspaces to one direction. Are there guardrails on how many workspaces a single swipe can move?
I also realized, what would happen if user has an external display. That display is on workspace 2. If user would swipe to workspace 2, it would do the movement to the external display? Or would it skip external display and move to the next free/empty workspace?
Found bug.
I will look into adding logic to prevent more than one workspace switch.
The original post mentions that it focuses relative
-1and+1workspace on the current monitor, meaning it will swap from workspace 1 to workspace 3 if workspace 2 is occupied by a different monitor.I could make it so that changing workspaces is the lower-half, while opening sidebar is upper?
The workspace swipe skipping workspaces has been resolved in db6051457f.
Found a new minor bug, but somewhat tedious bug with the two finger swipe to reveal the nc. This could be resolved with the change you suggested with the upper vs lower solution. I will write it in more detail if the bug persists.
6926880074 resolved multi-touch. May be merged in my book. New issue to create a settings window for configuration.
Apologies for the dependency spam. Was testing something, but it did not do what I expected.
Everything works as intended.
Merge is approved.
Discussion point/idea for the future:
Would it not be easiest to slide left and right with one finger on the bottom border instead of the left and right sides. That would open up the possibility of having painting, nc, osd etc be specifically accessible from their perspective sides.
I think we can absolutely add gestures for all parts of the UI, but I also think they're not mutually exclusive. For example we can make it so opening the drawing popout will activate with a gesture from the middle of the left edge, while the lower part of the left edge swaps workspaces, and then something else above, etc.
Maybe once I figure out a good way to handle multi-touch gestures we can make even more advanced gesture configurations.