Belatedly -- just seeing this on the list... What David and Alex are writing is totally reasonable. This is one of those things where the accreted code logic allows for certain behaviors which are different from what users may expect -- or want.
My guess is that the picker is modal (and turns off when masks or crop lines are present) because all of these elements are drawn on top of the darkroom's center view UI via ad hoc code after the image is drawn. There's semi-convoluted logic about which -- if any -- is drawn. And when a user clicks on the UI, there's some more ad hoc code to determine whether the click is on an overlay UI element (color picker, crop box, mask) or if the user is dragging around a zoomed in image. It's probably possible to adapt the current code to display multiple UI overlay elements, each responding to mouse clicks, so it's clear which is in front (probably color picker would always be in back). A proper way to fix this could be akin to the lighttable revamp a few years ago, where the UI became rendered as overlayed GTK widgets (even if GTK itself isn't that friendly to this concept). Removing the assumption that there is only one mouse-sensitive UI overlay on the center view would probably open up a bunch of other good feature ideas. There are some places where the modal nature of pickers make some sense: there's the left panel's global picker (which can remember one or more sample points/areas), then right panel modules can have one or more picker, and each picker may have its own location and may be an area or a point picker. But the center view only allows for moving the currently active picker. I did some work on the color picker last summer, which was my follow-up to yet other significant work. My memory was that part of the work was to make it slightly less modal. (Perhaps including making the left panel colorpicker #'s and histogram/scope update when using per-module color pickers.) I think I also tidied the logic of when a colorpicker was drawn, and how the data was passed around internally. A core realization was simply that, even though there are many possible pickers in darkroom view, only one is ever active. This simplifies the code. I've been too swamped to do much on darktable, but what Patrick writes about opening a feature request (if there isn't one already?) sounds good, to remember that there's work to be done here. -Dan On Thu, Apr 21, 2022, at 11:17 PM, Patrick Shanahan wrote: > * Alex Delaforce <[email protected]> [04-21-22 22:29]: >> I had a similar query a couple of months ago that I put on the lists. So I >> second this request. >> >> My point was that the color picker prevents some functions in the modules >> but unless you know this you can spend time clicking around wondering why a >> function doesn't work. Either have the module running in the background as >> suggested by David or have some indication that makes it obvious that the >> color picker is active when a blocked function is selected - maybe a popup >> next to the mouse (though I think this is an atypical behaviour). >> >> Thanks as always to the devs >> Alex >> >> On Fri, 22 Apr 2022 at 02:15, David Vincent-Jones <[email protected]> >> wrote: >> >> > I like to use the CP module a lot. I use it most often when I am using >> > other modules and need to take care that L values are staying within range. >> > My problem is that the action of CP disables the use of masks and features >> > in other modules. I cannot even crop without turning off CP activity. >> > >> > This is one module that I would like to see running freely in the >> > background .... would that be possible? >> > >> > >> > >> > ____________________________________________________________________________ >> > darktable user mailing list to unsubscribe send a mail to >> > [email protected] >> > >> >> ____________________________________________________________________________ >> darktable user mailing list >> to unsubscribe send a mail to [email protected] > > > unlikely to happen w/o someone at least taking the initiative to file a > feature request. > > https://github.com/darktable-org/darktable/issues/new?assignees=&labels=&template=feature_request.md&title= > > > -- > (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri > http://en.opensuse.org openSUSE Community Member facebook/ptilopteri > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc > ____________________________________________________________________________ > darktable user mailing list > to unsubscribe send a mail to [email protected] ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
