Scroll wheel problem in darktable for MacOS

I tend to use an iMac for photoediting, as the screens on my Linux machines aren’t as good. Version 2.4.4 of darktable for Mac generally works OK for me.

But there’s one persistent problem: changing a mask’s feather size with ‘shift + scroll’. Movement of the mousewheel in either direction only increases the size of the feather. I’ve tried several other mice (by various manufacturers), and all have the same issue. The only devices on which ‘shift + scroll’ works correctly are (a) the scroll wheel on my Wacom Intuos Pro L tablet; and (b) the scroll function on an Apple wireless mouse.

I suspect this is an issue specific to darktable on MacOS, as the Logitech Trackman works fine with darktable 2.4.4. on Debian Stretch.

(I prefer to use the Trackman as I get RSI problems with standard mouse devices.)

Has anyone else noticed this issue with darktable for Mac? And, more particularly, does anyone have any thoughts about a fix — apart from the obvious cludge of using an Apple mouse to do scrolling where needed! :wink:

TIA for any thoughts.

2 Likes

I guess it is a problem from how the Trackman (or scroll wheels in general) works on Mac. I used darktable with the MacBook trackpad and all was fine…

Maybe you can have a look in the Trackman settings and see if there is something funky there?

To make my comment clear, Based on the experience with the trackpad I think it is not a darktable issue, but more a MacOS driver/way to interpret scroll wheels …

@Daniel_Catalina Thanks for your reply. I’m not sure it’s entirely an issue due to MacOS rather than darktable, because the mouse wheels of various devices do work correctly in other Mac software, and with other aspects of the darktable GUI — just not with darktable’s ‘shift + scroll’ .

What’s odd is that the problem is specific to ‘shift + scroll’ for changing feather size. Odd.

I should say that like most ‘third-party’ mouse devices with scroll wheels that I’ve tried, the Trackman doesn’t have its own driver. You just plug in the USB cable. (The Wacom tablet does have its own driver). I suspect the problem is due to the way darktable interacts with the native MacOS mouse driver.

How do I pass this information to the devs who maintain darktable for Mac?

This post may be old. But I can say @archiemac is right. I’m using DT on a 2 Mac, one Mac Pro and iMac, both machine have the same behavior, and I’m stuck with the over-sized feather.

Anyone knows how to reset to default? Hopefully the developer can acknowledge this bug and solve it in the next release.

@lonetree Just to update you, I’m now on DT 2.6.2 for Mac, and the problem continues. I’ve solved my problem by keeping an Apple wireless mouse on the desk, just for use with DT, to Shift + Scroll the feather on masks. (The little mouse is quite happy to do just one job; and as it doesn’t eat much, or make much noise, and sleeps dreamlessly when I’m doing other stuff, we’re quite happy with our job-specific arrangement.)

I can confirm that this issue happens with me on 2.6.2 as well, regardless of the mouse that I use. My current workaround is to use the keyboard shortcuts [ ] { } instead of the mouse wheel. It’s annoying.

Maybe add a +1 to the open issue here: shift+scroll problem on macos · Issue #1977 · darktable-org/darktable · GitHub

Hi @archiemac , @bobsaget,

thanks for replying. Especially to @bobsaget. Thanks for the keyboard shortcut, at least for the moment I can reduce the size of the feather, otherwise, it’s almost useless.

Hope the developer can acknowledge this issue soon.

Cheers.

There are only a few people working on Mac related things. It is not a question of acknowledgement, but a lack of proper bug report, a proper error log, debug, or other information that’d help someone fix this for you.

It don’t happen on every Mac, as this works fine on the iMac I have.

1 Like

@paperdigits, lucky for you then.

For me, all my Mac are facing the issue, so can’t deny the fact that this is an issue.

It won’t be fixed unless one of you who actually has the problem opens a bug report on github, provides some logs or a gdb dump, and works with the developers to solve it.

The forum post is not a bug report.

I’m sure you see the problem with that advice, @paperdigits. DT is now being used by people who are just photographers, who don’t know where to find a log (no, not in the woodshed!), who have absolutely no clue what a gdb dump is (nothing to do with waste disposal, by the way), and wouldn’t know where github was, let alone how to set up an account there, and adopt the correct protocols for submission.

I entirely appreciate that there’s not a large team of help-desk staff just waiting to provide cheerful support to naive users. (Rather, I guess there’s just one guy, or maybe a couple, who generously volunteer their time and expertise to port dt to MacOS.)

But will there ever be a way that an innocent user can draw attention to a problem without having to master bug reporting 301 first? (OK, I guess you’ll say, “Sorry, no there won’t!”)

@lonetree >>> Use an Apple wireless mouse for scrolling the mask feather, or use the [ ] and { } keys. Just don’t hold your breath to see this problem, which affects just the small minority of us who use Macs, get fixed any time soon. (Have you ever thought of installing Archlinux on an old Windows desktop, and putting DT on that? :wink: )

This is where the expectations of those who generally use a proprietary OS and applications rub up against the culture of community in Free Software. There aren’t people who are just photographers, but rather everyone in the commubity, developers, uses, packagers, patchers, builders, etc come together to make a better application.

Nobody here started just knowing. We all had to choose to figure it out. I didn’t know where the log was, but it is documented in the manual. I didn’t know what gdb was, but I found it using a search engine. Github is one search away. You don’t need to write a perfect bug report (and you won’t), but people there will help you extract the information they need.

1 Like

But will there ever be a way that an innocent user can draw attention to a problem without having to master bug reporting 301 first? (OK, I guess you’ll say, “Sorry, no there won’t!”)

Your guess is correct. Have a look on the number of active code contributors on github, then it’s quite easy to get it.
If bugs are reported - be patient and you‘ll get repsonse when someone had time for the issue and prioritized it in the same way you did. So help them making it easy to understand the issue. There are plenty of issues around - and most devs needs to prioritize. Guess, which are prioritized: well documented or just ‚something is weird‘ issues

1 Like

@paperdigits @MStraeten >>> Thanks for your thoughtful replies. I have been using GNU/Linux and free software applications for at least fifteen years, and have spent hours communicating with one developer or another about a bug in some particular application. I also know that only a very small number of devs may well be looking after some specialist application in their free time on a couple of evenings a week (or a month!). And I’m also aware that a port to MacOS of an application designed and optimised for Linux may be particularly prone to issues around hardware interfaces (which I’m pretty sure is what this issue is about); and that the person responsible for porting the application simply won’t have time to cover every variant of hardware, particularly if it’s not standard on the target platform.

But we all use hundreds of applications, and we all come across bugs and glitches in them. There are only so many hours in a day, so a person whose just wants to use the application to do a job (editing photographs, say) may just want to ask on a forum if anyone has found a fix for some niggling issue. For some applications, the devs hang out on the main forum, and contribute advice where they have time. So one assumes it might be worth asking on a forum whether anyone has come across the issue and has a fix. And I’d understand entirely if the reply was, in effect, that there isn’t a fix, and the issue is a bit too ‘niche’ to get a lot of work, but you could submit a bug report on the relevant reporting system if you’ve got the time. That would be fine as an answer, without a lecture on the fourth of the four freedoms.

My fix for this issue? Use the Apple-specific hardware (i.e. a wireless mouse) when needed; or use the keyboard shortcuts. Simples.

@lonetree @bobsaget

Thanks to Tyler Henthorn for opening another issue about this on github this morning…

https://github.com/darktable-org/darktable/issues/2786

@bobsaget already mentioned the earlier issue report on github…

https://github.com/darktable-org/darktable/issues/1977

…though Tyler’s new issue #2786 seems to refer to behaviour that’s the inverse of that reported in #1977: he sees only decreasing feather size irrespective of scrolling direction, whereas most other reports are about scrolling either way only increasing the feather size.

1 Like

OK, I’ve looked in the manual, searched the net, looked at the package contents, checked the installation files, and looked in program settings; and I still can’t find a man page for the Mac port, or how to turn on debug logging. And dt doesn’t want to start from the CLI on a Mac.

I may just be being stupid. Grateful for any instructions!

You can start from the CLI by using (for example):

/Applications/darktable.app/Contents/MacOS/darktable

Thanks! (I’d just realised, while having coffee and croissants, that I’d mispelled part of the path!)

Thanks again.

No problem! I can imagine coffee and croissants can help with a lot of things :wink: