shift+scroll problem on macos about darktable HOT 40 CLOSED

Fixed in 2.6 branch, will forwardport to master soon.

from darktable.

+1 I have the same issue, Shift+Scroll only increase size of feathering
Workaround use { and } to decrease and increase feathering size (though I had to remap keyboard shortcut due to my keyboard layout)
Darktable 2.6.2
MacOS 10.14.5

from darktable.

I just experienced the same, awkward. I haven't found any workaround except manually move the points.
Also I happen to use a Wacom tablet but then how one is supposed to adjust the feather size without using a scroll wheel ? I didn't try but is there some king of Ctrl+drag and drop horizontally for feather and vertically for opacity ?

Version Master 2.7.0 1154 g1ea1ab272
MacOS 10.14.4

from darktable.

Can you zoom in/out in darkroom?

from darktable.

I've had this issue on dt for Mac over several dt releases. It only occurs with usb pointing devices (e.g. microsoft mouse, logitech trackman): shift+scroll in either scroll-wheel direction on a mask only INCREASES the feather size. It's impossible to decrease the feather size with the scroll wheel of these usb devices.

This issue does not arise with an Apple wireless mouse, nor with an Intuos Pro graphics tablet (which has its own driver).

All other scroll-wheel functions on usb pointing devices work normally (e.g. zoom in/out). The issue only affects decreasing the feather size of masks.

MacOS 10.14.5
dt 2.6.2

from darktable.

If the shift+scroll has this issue on all operations and all other scroll operations work fine then it doesn't seem to be a darktable problem.

from darktable.

@edgardoh This issue does not occur for other types of scrolling within darktable: for example, increasing and decreasing the zoom in the development module works as it should.

The problem only occurs in darktable with the Shift+scroll operation for changing the size of a mask feather. And it only occurs with third-party USB pointing devices (eg a microsoft mouse, a logitech Trackman, etc). It does not occur with the Apple wireless mouse or with an Intuos Pro graphics tablet (both of which have their own drivers).

Then again, I can't think of any other operation in darktable that uses Shift+scroll. Can you think of anything other than changing the size of a mask feather?

So the problem seems very specifically related to one type of operation in darktable only, in so far as it seems to be to do with the way darktable is communicating with non-Apple hardware on the USB bus when the shift key and scroll wheel are operated together. But, to be fair, I can't think of a similar <Shift+scroll> operation in another application to check whether the same thing happens. Can you think of any fairly standard software in which there's a Shift+scroll operation, so I can test it?

from darktable.

@edgardoh OK, I thought of a Shift+scroll operation in another application: if you zoom to enlarge a web page in Firefox so much that you have to scroll horizontally to see the whole page, then Shift+scroll operates the horizontal scroll ( scroll backwards and forwards to move the page left and right).

This works exactly as expected, which suggests that the shift+scroll issue with mask feather size is specific to darktable, and not to shift+scroll operations on the Mac generally.

from darktable.

@dartemisia , I don't use Mac, so I have no idea about other applications on that OS, but in dt you can move a node on the tone curve with no modifiers, with cntrl and with shift.

from darktable.

... in dt you can move a node on the tone curve with no modifiers, with cntrl and with shift.

Isn't that just using the arrow keys, rather than the mouse scroll wheel? I don't see any movement when I use the scroll wheel; but with the arrow keys, you get different 'scales' for the movement of nodes according as you also hold down cmd on a Mac (cntrl on Windows), or shift or nothing. This works as expected on my mac. But, as I say, there's no mouse involved, and that's where the issue is.

from darktable.

If you place the mouse over a node you should be able to move it with scroll, just like with the arrow keys.

from darktable.

@edgardoh Sorry, yes, if I hover the mouse over a node I can scroll its position up and down in +/- 0.1 increments; but the scale of the movement does not change when I press and hold a modifier key (Shift / Opt (Alt on Win) / Cmd (Cntrl on Win) ).

Only when I'm using the arrow keys does the Shift key alone make a difference (up/down arrow press alone gives +/- 0.1 changes; Shift + up/down gives +/- 1.0 changes)

from darktable.

Can you zoom in/out in darkroom?

@edgardoh yes I can zoom in/out with scroll in darkroom.

I will try to test using a magic mouse and a Wacom tablet will post later for now I'm using:

Darktable 2.6.2
MacOS Mojave 10.14.5
Logitech MX Master 2S

from darktable.

@edgardoh Aha! My report above was what happened when I use a non-Apple USB device. But when I use the Apple wireless mouse, the shift key does indeed change the scale of the movement from =/-0.1 to +/-1.0, so the issue is, it seems, to do with how darktable interprets the shift+scroll information from non-Apple USB pointing devices.

from darktable.

That's not what I expected. So far, with the masks, shift and cntrl are recognized, we know that because you can change the size, feather and opacity of the masks. Scroll is working fine, we know that because the amount of the change is correct. The issue is with the sign of the amount, it should be positive in one direction and negative in the other, but it seems to have always the same sign, and that only with the shift.

On the tone curve, on the other hand, it seems that the shift and cntrl are not recognized, so the amount of the change is always the same and the sign is correct (you are moving the nodes up and down).

Can you double check all this to confirm it?

Also, can you try to zoom in/out with cntrl and shift and see what happens?

from darktable.

@edgardoh I'll investigate this systematically this morning (I hope!), and certainly today...

from darktable.

@edgardoh >>> Here are the results of my checks on the matters you asked about.

First, I should say that I've tested with two non-Apple devices: a Logitech Trackman wired (connects to USB socket) and a Logitech Trackman wireless (has a receiver that's plugged into a USB socket); and I've checked a few things with a Microsoft wireless mouse (which again has a USB receiver for comms), which behaved no differently from the two other USB devices.

I've also tested the scroll behaviour with a Bluetooth-connected Apple Magic Mouse.

Below, I use 'fwd (forward)' for rotating the scroll wheel away from me, and 'back' for rotating the scroll wheel towards me.

MASKS

1. Using a circular mask

a) Non-Apple, USB devices
Scroll: size of mask changes +/- on scrolling back/fwd
Shift+scroll: changes the size of the feather + only on scrolling both back and fwd
Cntrl+scroll: changes the mask opacity +/- on scrolling back/fwd

b) Apple mouse
Scroll: size of mask changes +/- on scrolling back/fwd
Shift+scroll: changes the size of the feather +/- on scrolling back and fwd
Cntrl+scroll: changes the mask opacity +/- on scrolling back/fwd

2. Using a brush

a) Non-Apple, USB devices
Scroll: changes brush hardness +/- on scrolling back/fwd
Shift+scroll: changes the size of the feather + only on scrolling both back and fwd
Cntrl+scroll: changes the brush opacity +/- on scrolling back/fwd

b) Apple mouse
Scroll: changes brush hardness +/- on scrolling back/fwd
Shift+scroll: changes the size of the feather +/- on scrolling back/fwd
Cntrl+scroll: changes the brush opacity +/- on scrolling back/fwd

(Additional note: when using Cntrl+scroll to change mask/brush opacity, the % opacity indication above the picture correctly reflects the changes that the mouse is producing; but the mask opacity slider in the panel does not move from its central (0.00) position.)

TONE CURVE

a) Non-Apple, USB devices
Scroll: moves node in 0.1 increments +/- on scrolling fwd/back (note direction of scroll for + and - is reversed as compared with Masks)
Shift+scroll: node does not move at all, whether scrolling back or fwd (though 'working..' appears briefly on the picture area while scrolling.)
Cntrl+scroll: [EDITED] node moves in tiny increments +/- on scrolling fwd/back. (This needs five or six scroll wheel rotations to see any change in the first decimal place of the displayed values for node position or change.)

b) Apple mouse
Scroll: moves node in 0.1 increments +/- on scrolling fwd/back (note again change in direction of scroll for + and - with respect to that seen for Masks)
Shift+scroll: moves node in 1.0 increments +/- on scrolling fwd/back
Cntrl+scroll: appears to move node in very small increments (less than 0.1) +/- on scrolling fwd/back

ZOOM

a) Non-Apple, USB devices
Scroll: zooms +/- on scrolling fwd/back (note direction of scroll for + and - is again not same as for masks). Zoom range is from 'image fits screen' to 100%
Shift+scroll: does nothing. No zoom - image size stays at 'fits screen' whether scrolling back or fwd
Cntrl+scroll: zooms +/- on scrolling fwd/back. Zoom range is from 8% to 1600%

b) Apple mouse
Scroll: zooms +/- on scrolling fwd/back (note direction of scroll for + and - is again not same as for masks). Zoom range is from 'image fits screen' to 100%
Shift+scroll: zooms +/- on scrolling fwd/back. Zoom range is from 'image fits screen' to 100% (i.e. seems just the same as simple scroll)
Cntrl+scroll: zooms +/- on scrolling fwd/back. Zoom range is from 8% to 1600%

I hope this provides clear enough details on scrolling with and without the two modifier keys. If there's anything I've missed, or anything further you'd like me to check, just let me know.

from darktable.

Very strange that the cntrl does nothing on the tone curve, the changes are very small, maybe you missed it?

Let's say, to simplify, that the problem is with the shift+scroll only, and it happens everywhere. Since is working fine with some mouse and not with others, then the others are somehow generating different values for the event. Different doesn't mean wrong, maybe is some event that darktable don't support yet. Easiest way is to check if there's some setting or configuration for the mouse, and you can tell the mouse to behave like an Apple one.

from darktable.

Very strange that the cntrl does nothing on the tone curve, the changes are very small, maybe you missed it?

Yes, you're quite right. As I observed with the Apple mouse, the changes are very small; but you can see the values for the node positions changing after only a few scrolling movements. However, you need to do five or six rotations of a non-Apple mouse scroll wheel before the displayed values for node position or amount of change show any increase or decrease in the first decimal place. I just hadn't gone on scrolling for long enough! (I've edited the observation report above accordingly, to avoid confusion for readers)

Let's say, to simplify, that the problem is with the shift+scroll only, and it happens everywhere. Since is working fine with some mouse and not with others, then the others are somehow generating different values for the event. Different doesn't mean wrong, maybe is some event that darktable don't support yet. Easiest way is to check if there's some setting or configuration for the mouse, and you can tell the mouse to behave like an Apple one.

There aren't any separate configurations settings on a Mac for an Apple and non-Apple mouse. The settings for a generic USB mouse are very basic: scroll direction; tracking speed; scrolling speed; double-click speed; and position of primary button (left or right). When you connect an Apple mouse, the settings interface changes completely, and you get all sorts of Apple-specific options, to do with 'secondary click' and 'smart zoom' and swiping between apps and between pages. It's clearly got a very different driver.

My guess is that the numeric outputs about scrolling with modifier keys coming from the Apple mouse driver are being interpreted entirely correctly by darktable. However, what Apple's generic USB hardware and OS interfaces for the non-Apple devices send isn't what 'darktable for Mac' expects. (Apple is a bit notorious for doing things its own way!)

I'm beginning to wonder whether this isn't a case of 'you pays your money and you takes your choice' when dt is ported to Mac: you can make dt use the Apple mouse driver outputs OR you can make it use the generic USB outputs. For whatever Apple-ish reason, one or other of these is slightly non-standard. So, either way, you risk annoying one or other sets of users: those who use a proprietary Apple mouse, or those who use a genric, non-Apple USB mouse. "You can't please all of the people all of the time!" Short of dt somehow detecting whether the mouse is Apple or non-Apple, and changing it'd interpretation of the data they send, it may not be possible fo dt to handle both. So maybe the maintainer's best guess is that users of Macs will be using other Apple hardware.

What we could do with is someone using an Apple USB mouse (rather than the commoner wireless ones), to inform us about how that behaves.

What do you reckon?

(PS: I've just had the thought that, if you're not a Mac user, you may not be aware that an Apple Magic Mouse (yes, they really do call it that!) does not actually have a scroll wheel. It has a smooth uniform surface, under which is a net of sensors that detect the movements of your fingers (including whether you're tapping or swipping with one or two fingers — gestures which can do different things). To simulate scrolling a mouse wheel, you simply stroke one finger towards you or away from you on the surface of the mouse. It's not at all surprising that the outputs from this exotic device may be a bit non-standard!)

from darktable.

At this point I can't think of anything other than doing a remote debug. For that I'll need for someone to build from source a PR that I'll enter and do some testing, probably several times.
I've done this a couple of times for darktable, but in this case I'm not very optimistic, if what's needed is to add support for some device I won't be able to do it.

That's on darktable side, you can also try to find out if there's some way to make a non-apple mouse to behave like an apple one, but I cant' help with that.

from darktable.

At this point I can't think of anything other than doing a remote debug. For that I'll need for someone to build from source a PR that I'll enter and do some testing, probably several times.

That's a bit beyond my competence. Maybe someone with more skill may want to give it a go. But...

I've done this a couple of times for darktable, but in this case I'm not very optimistic, if what's needed is to add support for some device I won't be able to do it.

I fear you may be right about this being a device issue, so I'm not optimistic, either.

That's on darktable side, you can also try to find out if there's some way to make a non-apple mouse to behave like an apple one, but I cant' help with that.

I don't actually think that's possible. I think the best hope is for this problem to be taken up by someone who works with Macs and understands how dt behaves in that environment. Ideally that would be someone involved in porting dt to Mac; but I entirely appreciate that they may not have the time to prioritise this.

One slim hope is that @tylerhenthorn, who posted a related issue #2786, will be able to test his wired Apple USB mouse, to find out whether that has the limitations of non-Apple USB devices, or whether it behaves like the Apple wireless mouse.

For now, thanks very much, @edgardoh, for your suggestions and guidance, and for spending time on this issue.

from darktable.

I've looked over the code. Main function of interest is dt_gui_get_scroll_unit_deltas, and also see the scrolled callback in gtk.c where it's used.
Given the fact, that Shift+scroll means horizontal scrolling in other applications (at least for non-Apple mice, which don't have horizontal scroll by other means) I think that's what happens here too. DT registers horizontal scroll, and then faulty logic in scrolled function interprets it as vertical up scroll (independent of direction of horizontal scroll). So I guess this issue is possible to reproduce on any OS if one scrolls horizontally (some mice can do it). Horizontal scroll should probably be ignored (I don't think DT uses it anywhere). This though won't solve the issue of non-Apple mice not being able to Shift-scroll on macOS. Another solution is to interpret horizontal scroll the same as vertical, this will fix this issue. Third option is to use different modifier key and leave Shift unused. @edgardoh, which option would you like to implement?:))

from darktable.

One thing to check if we go with option 2 (horizontal scroll == vertical scroll) is if Shift key modifier is still being reported in this case. Probably it's removed, so we need to add it back, making horizontal scroll == Shift + vertical scroll.

from darktable.

The dt_gui_get_scroll_deltas() and dt_gui_get_scroll_unit_deltas() handle the horizontal case the same way, not sure the difference between those two.

On filmstrip.c the _lib_filmstrip_scroll_callback() and in the timeline.c _lib_timeline_scroll_callback() are using the dt_gui_get_scroll_unit_deltas() with the x parameter, so that should be taken in account for any modification.

Anywhere else the x parameter is not used, so it will be safe to make the GDK_SCROLL_LEFT and GDK_SCROLL_RIGHT to behave like the up and down.
For the filmstrip case maybe we can duplicate the dt_gui_get_scroll_unit_deltas() as it is now, is not pretty, but is the safest way due to our limitations on reproduce it.

We still need someone that can duplicate the issue and build from source so it can be tested.

from darktable.

dt_gui_get_scroll_deltas() and dt_gui_get_scroll_unit_deltas() are fine, it's scrolled() in gtk.c who's at fault. It can be changed to use x delta as I described (option 2). At least it should check the case when delta_y == 0 (option 1 and 3).
As for reproduction - as I said it probably can be reproduced on Linux also if you have a mouse with horizontal scroll (usually it's wheel tilt left-right) or a touchpad. I'm willing to test a patch against 2.6.x branch on macOS (haven't yet tried building master).

from darktable.

I was going for the less intrusive option, this issue happens everywhere when the shift+scroll is used, so we'll have to change the logic everywhere those two functions are called. Since the horizontal scroll is not used, is easiest to change this two functions.

I don't have such a mouse or touchpad, so I can do a proof-of-concept PR, but that will be in 2.7

from darktable.

@dartemisia , can you try to scroll the filstrip with and without the shift?

from darktable.

Not sure that "less intrusive" is a correct way to fix things. IMHO dt_gui_get_scroll_deltas() and dt_gui_get_scroll_unit_deltas() are implemented correctly, so what do you want to change in them? Remove possibility to report horizontal scroll?

from darktable.

Here's a simple program that emulates horizontal scroll left in X server:

#include <X11/extensions/XTest.h>                                                                                                                  
int main (){
  Display *dpy = NULL;
  dpy = XOpenDisplay(NULL);
  XTestFakeButtonEvent(dpy, 6, True,  CurrentTime);
  XTestFakeButtonEvent(dpy, 6, False, CurrentTime);
  XCloseDisplay(dpy);
  return 0;
}

Change 6 to 7 for scrolling right. Link/build with -lX11 -lXtst. Start the resulting executable with some delay, so that you can position the mouse where you want it. Now you can try to reproduce the issue.

from darktable.

from darktable.

Well, let's wait for someone else, I don't have time right now either. At least now we know the cause of this bug.

from darktable.

less intrusive means we don't have to change things everywhere.

My thinking is, nowhere the horizontal scroll is taken into account (other than the filmstrip) but it seems it should be, so let's have a function that returns the vertical scroll taken into account the horizontal one. For that, the easiest way is to rename the current function as *_xy() and make the dt_gui_get_scroll_deltas() and dt_gui_get_scroll_unit_deltas() to return the x with both the horizontal and vertical scroll.

from darktable.

I have a mouse with a horizontal scroll wheel and did a quick test using darktable 2.6.2 on Linux.

Scrolling the filmstrip with the regular mouse wheel and the horizontal one yielded equal (correct) results.

Adding a brush mask to an image in the darkroom worked as expected using the regular mouse wheel. But using the horizontal mouse wheel the brush would only get bigger when scrolling either way. This applies both when holding the shift button and without holding the shift button.

Hope this helps! If I can do more to help, please let me know ;)

from darktable.

@edgardoh, changing dt_gui_get_scroll_deltas() and dt_gui_get_scroll_unit_deltas() prototypes will require some changes in all the same functions, but I'm fine with your idea. The only question is: are we sure, that horizontal scroll won't be required in the future? But I guess it's better not, due to all the problems we are discussing here.

from darktable.

@saknopper , that's good enough for me to confirm the issue, tanks for testing it.

@parafin , my idea is to keep the current functions (with a different name) in case the horizontal scroll is ever needed, and to call them inside the new one. This is very theoretical anyway, let's see when implemented how it works.

Let's wait now for someone that can build it in 2.7

from darktable.

@edgardoh

@dartemisia , can you try to scroll the filstrip with and without the shift?

The filmstrip scrolls left & right without shift and with shift (so looks like shift makes no difference).
The same is true for both Apple wireless mouse and non-Apple USB mouse.

from darktable.

Great, so its confirmed for Mac too, thanks.

from darktable.

@edgardoh I tested using a Wacom Intuos Small and works fine, so this is only limited to using the scroll wheel of the mouse.

from darktable.

@jmtscaff , ok, seems reasonable that a device that can send horizontal scroll is sending a vertical scroll event even with the shift.

I'm still wandering if there's a setting or configuration for this, maybe there's a way to make the shift do not invert the orientation of the scroll, or to map another key for that.

from darktable.

@edgardoh Yeah tried that by switching from natural scroll direction to Standard and have the same result... The Logitech Master S2 that I use also has a horizontal scroll wheel at the side and tried that but same result, the feather just grew

from darktable.