Most noticed occurrence: Select items to print > double click to select current width for normal replace > type '0' > All selected images are now 'X' rated.
I can only change width and height valued by backspacing. David On 10/13/2017 12:29 AM, David Houlder wrote: > On 13/10/17 08:57, Tobias Ellinghaus wrote: >> Am Donnerstag, 12. Oktober 2017, 17:24:30 CEST schrieb Marcello Mamino: >>> I can reproduce the bug on Debian stable, under Xfce, master branch >>> just compiled, every setting default. The steps to follow are >>> *exactly* these >>> >>> 1. Open the "export selected" tab >>> 2. Click in the "max size" filed. >>> 3. Slowly move the pointer *downwards* >>> 4. As soon as the pointer reaches the "allow upscaling" label just >>> below, the input field loses focus >>> 5. Hover on a image, press a number, and the star rating changes >> We are aware of this and know why it's happening. We are not sure how to >> proceed with this though, as grabbing the focus itself is intended (so >> you can >> use the arrow keys to change the dropdowns and sliders), but the >> implication >> is unwanted. So we have to decide what eggs to break and what omelette to >> make. Or something like that. :-) > > I'm of the opinion that the focus-follows-mouse behaviour isn't always > helpful, and leads to errors of the type we're discussing here. > Information display on hover is good (e.g. tooltips and the image info > panel), but for many things that involve a state change, I think it's > preferable to require an explicit focus shift (mouse click or tab key) > first. > > For instance, I have accidentally changed the rating on an image in the > darkroom view due to confusion between the current image in the > filmstrip (the centered and highlighted thumbnail), and the focused > thumbnail - the one that the mouse is hovering over - which can easily > be any random image. > > Another downside of the current focus logic can be demonstrated by > hovering over a text field without clicking (say, the "max size" field > in the export panel) and tapping the up or down arrow key - it changes > the setting of the last dropdown that the mouse happened to fly over on > its way to the text field (in dt 2.2.5, Xubuntu 16.04). > > However, I can see some downsides to requiring an explicit focus shift > in all cases. > > The main one I can think of is shifting focus to a slider without > changing it in the process. The current behaviour allows you to hover > over a slider and crank it up or down a little with the arrow keys or > scroll wheel. Using a click to focus would inadvertently alter its > setting in many cases. > > So here's an idea: make all fields and widgets except for sliders > require explicit focus (mouse click or tab key), on the grounds that > sliders can be inadvertently changed by click-to-focus in a way that > other controls cannot. In the case where a slider was not explicitly > focused, it only has focus while the pointer is hovering over it, and > focus returns to whatever had it before the slider when the pointer > leaves the slider. In other words, hover on a slider temporarily steals > the focus. > > cheers > David > > > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
