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.
@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? 
)
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.
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
@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.
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.
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
The CLI seems to require the specific binary:
/Applications/darktable.app/Contents/MacOS/darktable-bin
Sadly, when I start it with < -d all >, it exits with an error…
##########################
(darktable-bin:4660): GdkPixbuf-WARNING **: 10:25:47.333: Cannot open pixbuf loader module file ‘/opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache’: No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
(darktable-bin:4660): Gtk-WARNING **: 10:25:47.333: Could not load a pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Abort trap: 6
###########################
However, lib/gdk-pixbuf-2.0/2.10.0/loaders.cache does exist: but on a Mac, there’s no /opt/local, so of course it isn’t in there!
I’m not going to mess about trying to unscramble this, as my installation works perfectly from the GUI, and I don’t have time to do all the troubleshooting simply to generate a debug log file for github. 
Thanks for helping.
I get the same error when running
/Applications/darktable.app/Contents/MacOS/darktable-bin
but not when I use
/Applications/darktable.app/Contents/MacOS/darktable
Specifying -d all to the latter also doesn’t cause any issues.
@saknopper >>> Mmm… using just /darktable is working now. (Must have misspelled something again - need more coffee & croissants!)
Also, /darktable -d all is working, but I can’t find the log file. I thought it was sent to
/Users/[user]/.cache/darktable
but it’s not there. In that directory, there’s only
cached_kernels_for_AMDRadeonPro555ComputeEngine
and
mipmaps-abf8c41f84cb7bcf0eef6f895945b3232607c553.d
Any ideas where the log file goes?
(…Or do you have to specify a logfile name and path in the CLI options?)
…Ah, it only outputs to the terminal, so you need to redirect the standard output.
“it only outputs to the terminal, so you need to redirect the standard output.”
Just for anyone new to this, and trying to follow my painful creeping towards the right method, you put this into the terminal:
/Applications/darktable.app/Contents/MacOS/darktable -d all > Desktop/log.txt
(Of course, you can change Desktop/log.txt to a different path and file name if you prefer.)
(Phew!)
@archiemac, thanks for speaking up.
By the way, @paperdigits, hope you don’t get me wrong that I’m trying to file a bug report here in this forum. I merely spoke out my thoughts, that’s all.
@archiemac, I will try with my Apple USB mouse tomorrow, I don’t have a magic mouse though, and don’t intend to get one just to serve this purpose. I haven’t been touching on Linux for about 5 years ever since I left my job as an IT engineer. Nonetheless, I will see if my old PC is still wiling to serve me with a Linux OS.
Thanks all.
@lonetree >>> I’m really interested to hear how the Apple USB mouse performs for resizing the mask feather, as the only USB devices I have are not Apple. Your results may help us understand whether this is a USB issue. (Do you know whether the Apple USB mouse uses an Apple driver or just the basic USB interface?)