shift+scroll problem on macos #1977
Comments
|
I just experienced the same, awkward. I haven't found any workaround except manually move the points. Version Master 2.7.0 1154 g1ea1ab272 |
|
+1 I have the same issue, Shift+Scroll only increase size of feathering |
|
Can you zoom in/out in darkroom? |
|
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 |
|
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. |
|
@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? |
|
@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. |
|
@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. |
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. |
|
If you place the mouse over a node you should be able to move it with scroll, just like with the arrow keys. |
|
@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) |
@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 |
|
@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. |
|
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? |
|
@edgardoh I'll investigate this systematically this morning (I hope!), and certainly today... |
|
@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
a) Non-Apple, USB devices b) Apple mouse
a) Non-Apple, USB devices b) Apple mouse (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 b) Apple mouse ZOOM a) Non-Apple, USB devices b) Apple mouse 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. |
|
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. |
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)
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!) |
|
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 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. |
That's a bit beyond my competence. Maybe someone with more skill may want to give it a go. But...
I fear you may be right about this being a device issue, so I'm not optimistic, either.
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. |
|
I've looked over the code. Main function of interest is |
|
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. |
|
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. We still need someone that can duplicate the issue and build from source so it can be tested. |
|
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). |
|
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 |
|
@dartemisia , can you try to scroll the filstrip with and without the shift? |
|
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? |
|
Here's a simple program that emulates horizontal scroll left in X server: Change 6 to 7 for scrolling right. Link/build with |
|
No, I don't want to do this.
El mié., 17 jul. 2019 a las 15:28, parafin (<notifications@github.com>)
escribió:
… 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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1977?email_source=notifications&email_token=AD5LLJMQ63VPWPYEDYVITCTP75QFZA5CNFSM4GOJWMW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2GFPGA#issuecomment-512513944>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD5LLJLZKITEJI4DM76BE73P75QFZANCNFSM4GOJWMWQ>
.
|
|
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. |
|
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. |
|
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 ;) |
|
@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. |
|
@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 |
The filmstrip scrolls left & right without shift and with shift (so looks like shift makes no difference). |
|
Great, so its confirmed for Mac too, thanks. |
|
@edgardoh I tested using a Wacom Intuos Small and works fine, so this is only limited to using the scroll wheel of the mouse. |
|
@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. |
|
@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 |
fixed by introducing wrapper functions that handle horizontal and vertical scroll the same, used them only when shift modifier means smth
|
Fixed in 2.6 branch, will forwardport to master soon. |
fixed by introducing wrapper functions that handle horizontal and vertical scroll the same, used them only when shift modifier means smth (cherry picked from commit 5e0daa8)
Problem: On the current 2.6.0 macos builds, it's impossible to decrease the feather size when drawing shapes.
Steps to reproduce: Open a photo and go to the spot removal module. Select the circle or the oval tool and move the mouse over the photo. Shift+mouse wheel up increases feather size. Shift + mouse wheel down also increases feather size.
Desired behavior: Shift + mouse wheel down should decrease feather size.
This problem seems limited to macos and doesn't occur on the linux builds. I tried reversing the "natural" scrolling direction in system preferences but this had no effect. I'm running darktable 2.6.0 on macos mojave 10.14.2.
If there's a workaround for decreasing the feather size without using the mouse's scroll wheel, I'd be interested.
Thanks!
The text was updated successfully, but these errors were encountered: