Opened 4 years ago

Closed 4 years ago

#176 closed defect (fixed)

Scroll wheel does mad things in Dive Info tab: tags and date/time field

Reported by: torvalds Owned by: Dirk Hohndel <dirk@…>
Priority: major Component: Qt-UI
Version: current git - add SHA in description Keywords:
Cc: Plattform (please give specifics in the ticket text): Linux

Description

.. well technically you *can*, but it also starts editing the dive, so it's effectively unusably annoying.

Change History (6)

comment:1 Changed 4 years ago by admin

So in the current git version it doesn't do that for me - but I seem to remember that there are a couple of different ways that scroll is emulated under X, so maybe I'm just lucky with the events that my touchpad sends?

Can you verify this? Otherwise I'll close :-)

comment:2 Changed 4 years ago by DirkHH

  • Resolution set to worksforme
  • Status changed from new to closed

Current git (d541b9fd421c) happily scrolls the notes for me (without going into edit mode)
Could you check if this works for you now? If not, please reopen.

Last edited 4 years ago by DirkHH (previous) (diff)

comment:3 Changed 4 years ago by torvalds

  • Component changed from Android Companion App to Qt-UI
  • Resolution worksforme deleted
  • Status changed from closed to reopened

It's still broken for me.

Apparently the *notes* have now been special-cased, so you can scroll inside them, but check what happens if you use the scroll-wheel and the whole window scrolls (not just the note section), and the mouse cursor happens to go over the field above it - the tag field.

Or even worse - look at what happens if you scroll-wheel over the "Start time" field. The time will magically change, *and* the "dive is being edited" doesn't even come up. Augh.

comment:4 Changed 4 years ago by DirkHH

  • Summary changed from Cannot scroll in dive notes using scroll wheel to Scroll wheel does mad things in Dive Info tab: tags and date/time field
  • Version changed from 3.1 to current git - please provide SHA in your description

Created a useful Title for the report and updated it to reflect the correct version.

Verified with SHA d541b9fd421c

comment:5 Changed 4 years ago by DirkHH

Here's feedback from Linus:

So the way I expect my scroll-wheel to work is that if I'm in a
scrollable region, it scrolls that region first - and then when it
hits the end of the region, it starts scrolling the "next" scrollable
frame or window. That's how it works pretty much everywhere else.

And your (Lubomir's) "tweak the scrolling while inside the notes" actually stops
scrolling the whole "Dive Notes" window, if the "Notes" section is
selected. Which isn't what I expect (or what other applications do).

So the only thing I really _don't_ expect is that it starts editing
things as it scrolls past them. Yes, people edit things with the
scroll-wheel too (say, you have a drop-down choice thing, and want to
scroll through it), but that happens only after you've opened the
drop-down thing explicitly, not because you happen to scroll past the
drop-down entry in a window.

comment:6 Changed 4 years ago by Dirk Hohndel <dirk@…>

  • Owner set to Dirk Hohndel <dirk@…>
  • Resolution set to fixed
  • Status changed from reopened to closed

In d117becad83a42f49e17bc151ce5ecc11e4dc8cf/subsurface:

Improve MainTab? behavior when using the scroll wheel

This gets the behavior close to what we really want.

  • scroll wheel no longer enters edit mode when over the tabWidget
  • scroll wheel doesn't modify dateTimeEdit, nor does it enter edit mode
  • scroll wheel still scrolls both the notes and the full widget

The only oddity is that when clicking on either the dateTimeEdit or the
tabWidget we don't immediately turn on the 'being edited' warning (as we
do for all the other widgets). For those two widgets the user has to press
a key before edit mode starts.

I think this Fixes #176

Reported-by: Linus Torvalds <torvalds@…>
Ideas-by: Lubomir I. Ivanov <neolit123@…>
Signed-off-by: Dirk Hohndel <dirk@…>

Note: See TracTickets for help on using tickets.