Bug 457409

Summary:	Accidentally moving out of tab bar's y-coordinate range stops movement
Product:	[Applications] kate	Reporter:	David Chmelik <dchmelik>
Component:	general	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	christoph, waqar.17a
Priority:	NOR
Version First Reported In:	22.04.3
Target Milestone:	---
Platform:	Other
OS:	All
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description David Chmelik 2022-08-02 11:55:06 UTC

SUMMARY
Accidentally moving out of tab bar's y-coordinate range stops movement.

STEPS TO REPRODUCE
1. Try to move tab.
2. Keep moving but accidentally slightly move above or below tab bar.
3. Tabs tops and one must move back within tab bar's y-coordinate range--often multiple times--to resume moving.

OBSERVED RESULT
Accidentally moving out of tab bar's y-coordinate range stops movement. Tab stops and isn't even positioned right but a space appears... one must move back within tab bar's y-coordinate range--often multiple times--to resume moving.

EXPECTED RESULT
Ingore y-coordinate moving tabs; let user continue: only keep checking x-coordinate.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Slackware64 15
KDE Plasma Version: 5 to 5.25.3
KDE Frameworks Version: 5 to 5.96.0
Qt Version: 5 to 5.15.5

ADDITIONAL INFORMATION
Despite TVs get larger & larger, monitors with comparative resolution get smaller & smaller: much, much smaller pixels than older monitors, so some 8K are same size as 4k are smaller than some 1080p. All GUI elements get too small: panels, titlebars, menubars, toolbars, tabbars, infobars, scrollbars, so you CANNOT assume a user will even easily be able to stay within an element's range when still acting on it so absolutely shouldn't expect/make them to.

Best/original tab definers like Firefox don't care if you move out of tab bar y-coordinate range. Worst UI implementers such as Google (zero design sense) do same and worse--if you move out-of-range tab will pop out as a new window. Best to not do that and not stop until user releases (unless some users want option if they move out-of-range, then stop, but would they be crazy or what?)

Comment 1 Christoph Cullmann 2022-08-25 19:43:27 UTC

Whereas I think it is not optimal, if you scale the UI (should be feasible both for X11 and Wayland) you should have no that big issues.

I am not sure if we can really alter this (and if we later not want the same "drag as own windows" behavior as Chromium.

Keeping as wish list, but if nobody steps up to take a look, this will somewhen be closed.

Comment 2 Waqar Ahmed 2022-08-25 19:53:57 UTC

The movement stops because dragging can offer two functions
- rearrange tabs
- move tab to a different split / kate instance

To differentiate between the two, the initial implementation stopped "rearrange" as soon as the cursor left the tabbar. Another side effect was that you would see a "tab" hanging in the middle of nowhere which was weird.

The upcoming release (22.08) improves this behaviour by allowing more flexibility in the case where a user might just be rearranging tabs. If you drag really far away from the tabbar, only then will the rearranging stop. However, note that this is only done for bottom side. If you drag the tab above the tabbar, then it will stop rearranging immediately. It is unlikely the "drag above" case will be fixed, at least from my side since most of the times you drag below or on the tabbar, but if there are a lot of reports that the "drag above" case should also be handled, we can take a look.