Re: [darktable-dev] possible data loss scenario
I was also trapped by the loss of focus. I found a very simple parade. I modified the shortcuts r, 1,2,3,4 and 5 for the light table and darkroom to CTRL-r, CTRL-1,..., CTRL-5. Since I have no problem! JP Le 25/10/2017 à 23:51, Patrick Shanahan a écrit : * Alexander Rabtchevich [10-25-17 15:07]: I've provided all the required steps in the thread before, step by step. Maybe it's better to spend some time for reading before blaming, isn't it? One of the user-cases is: start editing in some edit control (image size for export etc.) If the cursor occasionally leaves the control for some other control (except label), the latter steals focus and the keyboard input is not hooked by the original edit control one is actually typing in. If one is typing digits at that moment, they are interpreted as star rating. If any images are selected, that rating is mutually applied for them. If one have selected some images by some search criterion, including rating, applying wrong star rating can be fully destructive as that cannot be undone without the full knowledge about the set of affected images and their initial ratings. With respect, Alexander Rabtchevich Patrick Shanahan wrote: * Alexander Rabtchevich [10-25-17 12:12]: Hello Yesterday I've almost lost my data again. That time that hadn't happened because no images were selected. It's some kind of Russian roulette to change image size. With respect, Alexander Rabtchevich David Vincent-Jones wrote: 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 cannot you provide steps and conditions which led to your "almost" condition that someone may provide a solution? only you can see and experience what is in front of you, other just have to guess or summons their crystal balls, or iron or perhaps your methods need examining. the *only* time I recall "almost" loosing data was when I was being quite foolist and in too much hurry mode. but I caught myself, re: almost. and I have "trash" disabled. I read the list and have read your posts and I have used dt extensively for several years and cannot recall more than once or twice having the mouse pointer "wander", but I use a track-ball. Maybe that is the difference. I did suggest you examine your methods and maybe you can minimize or stop the "cursor from leaving control" and stop almost losing data. and I cannot recall nor see that any "blame" has been assigned you, only a suggestion that your methods may be suspect. skin thin? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Aw: Re: [darktable-dev] possible data loss scenario
Hello Let's consider the problematic cases and try to make some suggestions. As I recall, there are several possibilities of unintentional actions: 1. In the darkroom mode, ratings etc are applied to an image under cursor, not to the selected or processed one. That can occasionally lead to unpredicted and even unnoticed results if mouse cursor have been moved to the filmstrip. A possible solution: apply changes to an image from the filmstrip if it is selected. Should it be applied to the whole number of multiple selected images or to the one and only under cursor - it is a question of settings. But the image should be already selected. 2. Focus steal from text input controls without explicit mouse click. As I understood from the discussion, it is mainly made for spinbuttons controls. So let's consider the use-case of spinbutton control. Does it need keyboard actions? Yes, maybe. In which case? If keyboard was used for navigation I guess. That is traditional tabs switch between controls within a window. Opposite, in the case a _mouse_ was used to select (simply hovering over the control), keyboard cursors are hardly used to change its value - it is much easier to use a scroll button from the same mouse. So if the control has received focus with click or keyboard, it's OK to it to hook keyboard actions. In the other case, it can only hook mouse actions. And focus for keyboard input remains for the last clicked control or at least the keyboard actions are translated to it. Any thoughts? With respect, Alexander Rabtchevich > Von: "David Vincent-Jones" > There are standards that most have used across numerous systems and over > many years. > > Double click to select a word element or number and then simply type-in > a replacement. This input method is respected across all programs on my > system .. except for darktable on which it can, unfortunately, lead to > lost material. > > As you suggested I have now trained myself to to handle dt input in a > different manner; it would however be preferred if a more common method > was available. > > David ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
There are standards that most have used across numerous systems and over many years. Double click to select a word element or number and then simply type-in a replacement. This input method is respected across all programs on my system .. except for darktable on which it can, unfortunately, lead to lost material. As you suggested I have now trained myself to to handle dt input in a different manner; it would however be preferred if a more common method was available. David On 10/25/2017 02:53 PM, Patrick Shanahan wrote: * David Vincent-Jones [10-25-17 12:39]: The steps that I detailed (below) were quite specific David On 10/25/2017 09:18 AM, Patrick Shanahan wrote: * Alexander Rabtchevich [10-25-17 12:12]: Hello Yesterday I've almost lost my data again. That time that hadn't happened because no images were selected. It's some kind of Russian roulette to change image size. With respect, Alexander Rabtchevich David Vincent-Jones wrote: 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 cannot you provide steps and conditions which led to your "almost" condition that someone may provide a solution? only you can see and experience what is in front of you, other just have to guess or summons their crystal balls, or iron or perhaps your methods need examining. the *only* time I recall "almost" loosing data was when I was being quite foolist and in too much hurry mode. but I caught myself, re: almost. and I have "trash" disabled. why would you continue to use a method/approach that causes you that kind of concern. ?? double click ?? windows ?? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
* David Vincent-Jones [10-25-17 12:39]: > The steps that I detailed (below) were quite specific > > David > > > On 10/25/2017 09:18 AM, Patrick Shanahan wrote: > >* Alexander Rabtchevich [10-25-17 12:12]: > >>Hello > >> > >>Yesterday I've almost lost my data again. That time that hadn't happened > >>because no images were selected. It's some kind of Russian roulette to > >>change image size. > >> > >>With respect, > >>Alexander Rabtchevich > >> > >>David Vincent-Jones wrote: > >>>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 > >>> > >>> > >cannot you provide steps and conditions which led to your "almost" > >condition that someone may provide a solution? only you can see and > >experience what is in front of you, other just have to guess or summons > >their crystal balls, or iron or > > > >perhaps your methods need examining. the *only* time I recall "almost" > >loosing data was when I was being quite foolist and in too much hurry > >mode. but I caught myself, re: almost. > > > >and I have "trash" disabled. > why would you continue to use a method/approach that causes you that kind of concern. ?? double click ?? windows ?? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Registered Linux User #207535@ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
* Alexander Rabtchevich [10-25-17 15:07]: > I've provided all the required steps in the thread before, step by step. > Maybe it's better to spend some time for reading before blaming, isn't it? > > One of the user-cases is: start editing in some edit control (image size for > export etc.) If the cursor occasionally leaves the control for some other > control (except label), the latter steals focus and the keyboard input is > not hooked by the original edit control one is actually typing in. If one is > typing digits at that moment, they are interpreted as star rating. If any > images are selected, that rating is mutually applied for them. > > If one have selected some images by some search criterion, including rating, > applying wrong star rating can be fully destructive as that cannot be undone > without the full knowledge about the set of affected images and their > initial ratings. > > > With respect, > Alexander Rabtchevich > > Patrick Shanahan wrote: > >* Alexander Rabtchevich [10-25-17 12:12]: > >>Hello > >> > >>Yesterday I've almost lost my data again. That time that hadn't happened > >>because no images were selected. It's some kind of Russian roulette to > >>change image size. > >> > >>With respect, > >>Alexander Rabtchevich > >> > >>David Vincent-Jones wrote: > >>>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 > >>> > >>> > >cannot you provide steps and conditions which led to your "almost" > >condition that someone may provide a solution? only you can see and > >experience what is in front of you, other just have to guess or summons > >their crystal balls, or iron or > > > >perhaps your methods need examining. the *only* time I recall "almost" > >loosing data was when I was being quite foolist and in too much hurry > >mode. but I caught myself, re: almost. > > > >and I have "trash" disabled. I read the list and have read your posts and I have used dt extensively for several years and cannot recall more than once or twice having the mouse pointer "wander", but I use a track-ball. Maybe that is the difference. I did suggest you examine your methods and maybe you can minimize or stop the "cursor from leaving control" and stop almost losing data. and I cannot recall nor see that any "blame" has been assigned you, only a suggestion that your methods may be suspect. skin thin? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Registered Linux User #207535@ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
I've provided all the required steps in the thread before, step by step. Maybe it's better to spend some time for reading before blaming, isn't it? One of the user-cases is: start editing in some edit control (image size for export etc.) If the cursor occasionally leaves the control for some other control (except label), the latter steals focus and the keyboard input is not hooked by the original edit control one is actually typing in. If one is typing digits at that moment, they are interpreted as star rating. If any images are selected, that rating is mutually applied for them. If one have selected some images by some search criterion, including rating, applying wrong star rating can be fully destructive as that cannot be undone without the full knowledge about the set of affected images and their initial ratings. With respect, Alexander Rabtchevich Patrick Shanahan wrote: * Alexander Rabtchevich [10-25-17 12:12]: Hello Yesterday I've almost lost my data again. That time that hadn't happened because no images were selected. It's some kind of Russian roulette to change image size. With respect, Alexander Rabtchevich David Vincent-Jones wrote: 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 cannot you provide steps and conditions which led to your "almost" condition that someone may provide a solution? only you can see and experience what is in front of you, other just have to guess or summons their crystal balls, or iron or perhaps your methods need examining. the *only* time I recall "almost" loosing data was when I was being quite foolist and in too much hurry mode. but I caught myself, re: almost. and I have "trash" disabled. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
Am 13.10.2017 um 02:12 schrieb Jonathan Richards: > On 12/10/17 22: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 > Ah, yes. This behaviour is identical on the KDE build that I reported > above. I did not move the cursor downward before. > Jonathan >> 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. :-) > What about a confirmation dialog before DT changes the star rating on a > large number of selected images? Or an undo stack that remembers star > ratings and can restore them after a mistaken commit? Alexander's > original report was about losing many decisions on star rating, after all. I'd indeed also wish if ratings (such as star ratings, reject, or similar) were undo-able, because every once in a while the mouse pointer hovers over the film strip in darktable mode, and I press r, not having noticed the mouse went down from the main image, and I accidentally reject a different image... (And I've stopped using Wayland/Mir stuff because they'd sometimes let an event such as a mouse click get noticed by one popup and the underlying control at the same time, which I do not see when using Xorg). ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
The steps that I detailed (below) were quite specific David On 10/25/2017 09:18 AM, Patrick Shanahan wrote: * Alexander Rabtchevich [10-25-17 12:12]: Hello Yesterday I've almost lost my data again. That time that hadn't happened because no images were selected. It's some kind of Russian roulette to change image size. With respect, Alexander Rabtchevich David Vincent-Jones wrote: 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 cannot you provide steps and conditions which led to your "almost" condition that someone may provide a solution? only you can see and experience what is in front of you, other just have to guess or summons their crystal balls, or iron or perhaps your methods need examining. the *only* time I recall "almost" loosing data was when I was being quite foolist and in too much hurry mode. but I caught myself, re: almost. and I have "trash" disabled. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
* Alexander Rabtchevich [10-25-17 12:12]: > Hello > > Yesterday I've almost lost my data again. That time that hadn't happened > because no images were selected. It's some kind of Russian roulette to > change image size. > > With respect, > Alexander Rabtchevich > > David Vincent-Jones wrote: > >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 > > > > cannot you provide steps and conditions which led to your "almost" condition that someone may provide a solution? only you can see and experience what is in front of you, other just have to guess or summons their crystal balls, or iron or perhaps your methods need examining. the *only* time I recall "almost" loosing data was when I was being quite foolist and in too much hurry mode. but I caught myself, re: almost. and I have "trash" disabled. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Registered Linux User #207535@ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
Hello Yesterday I've almost lost my data again. That time that hadn't happened because no images were selected. It's some kind of Russian roulette to change image size. With respect, Alexander Rabtchevich David Vincent-Jones wrote: 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 ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
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
Re: [darktable-dev] possible data loss scenario
On 14/10/17 03:53, Alexander Rabtchevich wrote: As I understand, the desired action to be click-less is mouse scrolling over a control. Yes, but also... Why should it hook keyboard actions? So you can use the arrow keys, and maybe page-up, page-down, etc. to adjust the slider. Maybe the hover could just temporarily steal focus for those keys, but it might be less confusing to grab all keyboard input and just discard keystrokes that don't mean anything to the slider. That would fail gracefully in the sense that the discarded keystrokes can't wreak havoc in some other widget. cheers David ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
Hello David Houlder wrote: 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. The idea is sound. *Any* unintended keyboard action *is* data loss. The scenario could be different, but it can lead even to physical removing of a photo. Why not? Assign it 0 rating or click Del to remove unneeded digit or a letter in a control. And the confirmation dialog to Del key may be passed through automatically. And latter remove the *accidentally* assigned image physically. As I understand, the desired action to be click-less is mouse scrolling over a control. Why should it hook keyboard actions? With respect, Alexander Rabtchevich ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
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
Re: [darktable-dev] possible data loss scenario
On Thu, Oct 12, 2017 at 11:57 PM, 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. :-) If I may offer a suggestion, I would say that grabbing the focus should necessitate a click. Even ignoring Alexander's problem, the current implementation is broken (at least under Linux+Xorg+Xfce). If the "max size" field has focus and I press the arrows I can adjust the number. Then I move the mouse down to "allow upscaling", and the arrows adjust this setting. Fine, but now I do the opposite action and move the pointer back to "max size": for no good reason the arrows keep controlling the "allow upscaling" setting. It must be either focus-follows-pointer or focus-follows-click, while now it seems to be a random mix of these. Yours, Marcello Mamino. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
On 12/10/17 22: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 Ah, yes. This behaviour is identical on the KDE build that I reported above. I did not move the cursor downward before. Jonathan > > 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. :-) What about a confirmation dialog before DT changes the star rating on a large number of selected images? Or an undo stack that remembers star ratings and can restore them after a mistaken commit? Alexander's original report was about losing many decisions on star rating, after all. > >> I have a second, loosely related problem with number keys and stars. I >> take this opportunity to ask the devs if it's a bug or a feature. >> Image X has one star. You click on the star, and the star is removed. >> This makes sense because there is no other way to remove that star. >> You hover on image X that has one star, you press 1, and the star is >> removed. This makes no sense, because if you want to remove the star, >> you can just press 0. It's also frustrating when you see image X >> suddenly vanish. Is this by design? > > This used to be by design and was changed in the development version. There > is > still some minor issue left but we are certain that the upcoming release will > be intuitive to use in this regard. > >> Yours, >> Marcello Mamino. > > Tobias > signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] possible data loss scenario
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 have a second, loosely related problem with number keys and stars. I > take this opportunity to ask the devs if it's a bug or a feature. > Image X has one star. You click on the star, and the star is removed. > This makes sense because there is no other way to remove that star. > You hover on image X that has one star, you press 1, and the star is > removed. This makes no sense, because if you want to remove the star, > you can just press 0. It's also frustrating when you see image X > suddenly vanish. Is this by design? This used to be by design and was changed in the development version. There is still some minor issue left but we are certain that the upcoming release will be intuitive to use in this regard. > Yours, > Marcello Mamino. Tobias signature.asc Description: This is a digitally signed message part.
Re: [darktable-dev] possible data loss scenario
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 I have a second, loosely related problem with number keys and stars. I take this opportunity to ask the devs if it's a bug or a feature. Image X has one star. You click on the star, and the star is removed. This makes sense because there is no other way to remove that star. You hover on image X that has one star, you press 1, and the star is removed. This makes no sense, because if you want to remove the star, you can just press 0. It's also frustrating when you see image X suddenly vanish. Is this by design? Yours, Marcello Mamino. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
On 10/10/17 18:11, Alexander Rabtchevich wrote:
> Hello
>
> And the scenario is still working.
> 1. Select an image in the lighttable mode.
> 2. Click into the edit window Max size in the export dialog.
> 3. Move mouse just slightly outside the edit window. It loses focus
> immediately.
> 4. Type the digit you want. It is recognized as rating for the image
> being selected.
>
> The item 3 is the problematic one. Why does the edit control loose
> focus? One haven't clicked outside the control. A mouse is not
> guaranteed to keep its exact position just after it has been released -
> and it _is_ released to type digits on a keyboard.
>
> With respect,
> Alexander Rabtchevich
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
>
>
Roman, Alexander
As it happens, I have just recompiled darktable version
2.3.0+971~gf092843 on my system, and I followed Alexander's scenario,
given above.
At step 3, the edit window *keeps* the focus, and I can continue to type
in it even if I move the mouse cursor all the way back over the
lighttable pane.
My hardware is AMD Phenom II CPU, nVidia GeForce 460 GPU. Software is
KDE Neon LTS User Edition 5.8, KDE Framework 5, Plasma desktop, nVidia
drivers version 375.82
Neon is using Xorg:
jonathan@Odin:~$ ps -ef | grep X
root 1205 1192 3 13:21 tty7 00:02:44 /usr/lib/xorg/Xorg
-nolisten tcp -auth /var/run/sddm/{b2c334be-1a6a-4ae0-8858-0511d6b0c079}
-background none -noreset -displayfd 18 vt7
Xorg version information:
$ /usr/lib/xorg/Xorg -version 2>&1
X.Org X Server 1.19.3
Release Date: 2017-03-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-87-generic x86_64 Ubuntu
Current Operating System: Linux Odin 4.10.0-35-generic
#39~16.04.1-Ubuntu SMP Wed Sep 13 09:02:42 UTC 2017 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.10.0-35-generic
root=UUID=ddb4c2a2-33b1-4edf-99bc-322be3d2badc ro quiet splash vt.handoff=7
Build Date: 25 July 2017 01:30:08PM
xorg-server 2:1.19.3-1ubuntu1~16.04.2 (For technical support please see
http://www.ubuntu.com/support)
Current version of pixman: 0.33.6
Happy to help drive out this bug, if I can. I hate data loss!!
Regards
Jonathan
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
xdpyinfo | grep version version number:11.0 X.Org version: 1.18.4 Mate is build as a consequence of gnome 2. Current version is based on gtk3. Linux Mint 18.2 uses Ubuntu 16.04 package base. With respect, Alexander Rabtchevich Roman Lebedev wrote: I have standard Mate from 18.2 Mint and proprietary AMD GPUpro video driver. (Yes, but that does not answer the question. I have no clue what mint does by default. Is it X or not?) ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
On Tue, Oct 10, 2017 at 8:28 PM, Alexander Rabtchevich wrote: > Yes, I'm pretty sure :) > > When cursor reaches another control somewhere within the main window, the > edit window looses focus. It should be some control (slider, another edit > window etc), not a label. > I have standard Mate from 18.2 Mint and proprietary AMD GPUpro video driver. (Yes, but that does not answer the question. I have no clue what mint does by default. Is it X or not?) > With respect, > Alexander Rabtchevich > > > > > > Roman Lebedev wrote: >> >> The item 3 is the problematic one. Why does the edit control loose focus? >> That sounds like a bug. It is *not* intended behavior. >> Is this normal X or wayland/mir/etc? >> Are you *sure* you don't accidentally mouseclick right after 3. and before >> 4. ? >> > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
Yes, I'm pretty sure :) When cursor reaches another control somewhere within the main window, the edit window looses focus. It should be some control (slider, another edit window etc), not a label. I have standard Mate from 18.2 Mint and proprietary AMD GPUpro video driver. With respect, Alexander Rabtchevich Roman Lebedev wrote: The item 3 is the problematic one. Why does the edit control loose focus? That sounds like a bug. It is *not* intended behavior. Is this normal X or wayland/mir/etc? Are you *sure* you don't accidentally mouseclick right after 3. and before 4. ? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
Not OP, but chiming in, I have also been bitten by the focus-follows-mouse model in Darktable. Very tricky to use any of the text inputs. I've been reluctant to complain because I use a pretty esoteric WM (StumpWM) which doesn't interact well with some of Darktables widgets (like the left-click arc "fine" adjustment). I also noticed that a couple of versions ago Darktable stopped recognizing the scroll wheel on one of my input devices (trackpoint on keyboard works, scroll wheel on mouse doesn't). Seems to be a global GTK issue (gedit has the same problem). Non-GTK applications work fine. On Tue, Oct 10, 2017 at 10:11 AM, Alexander Rabtchevich < alexander.v.rabtchev...@gmx.net> wrote: > Hello > > And the scenario is still working. > 1. Select an image in the lighttable mode. > 2. Click into the edit window Max size in the export dialog. > 3. Move mouse just slightly outside the edit window. It loses focus > immediately. > 4. Type the digit you want. It is recognized as rating for the image being > selected. > > The item 3 is the problematic one. Why does the edit control loose focus? > One haven't clicked outside the control. A mouse is not guaranteed to keep > its exact position just after it has been released - and it _is_ released > to type digits on a keyboard. > > With respect, > Alexander Rabtchevich > > > ___ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscribe@list > s.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
I have had similar problems when typing and have found images re-rated ... it is also really confusing if the sort is set by the rating and the image 'disappears'. David On 10/10/2017 10:11 AM, Alexander Rabtchevich wrote: > Hello > > And the scenario is still working. > 1. Select an image in the lighttable mode. > 2. Click into the edit window Max size in the export dialog. > 3. Move mouse just slightly outside the edit window. It loses focus > immediately. > 4. Type the digit you want. It is recognized as rating for the image > being selected. > > The item 3 is the problematic one. Why does the edit control loose > focus? One haven't clicked outside the control. A mouse is not > guaranteed to keep its exact position just after it has been released - > and it _is_ released to type digits on a keyboard. > > With respect, > Alexander Rabtchevich > ___ > 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
Re: [darktable-dev] possible data loss scenario
On Tue, Oct 10, 2017 at 8:11 PM, Alexander Rabtchevich wrote: > Hello > > And the scenario is still working. > 1. Select an image in the lighttable mode. > 2. Click into the edit window Max size in the export dialog. > 3. Move mouse just slightly outside the edit window. It loses focus > immediately. > 4. Type the digit you want. It is recognized as rating for the image being > selected. > The item 3 is the problematic one. Why does the edit control loose focus? That sounds like a bug. It is *not* intended behavior. Is this normal X or wayland/mir/etc? Are you *sure* you don't accidentally mouseclick right after 3. and before 4. ? > One haven't clicked outside the control. A mouse is not guaranteed to keep > its exact position just after it has been released - and it _is_ released to > type digits on a keyboard. > > With respect, > Alexander Rabtchevich Roman. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
Hello And the scenario is still working. 1. Select an image in the lighttable mode. 2. Click into the edit window Max size in the export dialog. 3. Move mouse just slightly outside the edit window. It loses focus immediately. 4. Type the digit you want. It is recognized as rating for the image being selected. The item 3 is the problematic one. Why does the edit control loose focus? One haven't clicked outside the control. A mouse is not guaranteed to keep its exact position just after it has been released - and it _is_ released to type digits on a keyboard. With respect, Alexander Rabtchevich ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
Here is the result of the output of cat darktable/build/src/version_gen.c #ifndef RC_BUILD #ifdef HAVE_CONFIG_H #include "config.h" #endif const char darktable_package_version[] = "2.3.0+974~g4c0754d"; const char darktable_package_string[] = PACKAGE_NAME " 2.3.0+974~g4c0754d"; const char darktable_last_commit_year[] = "2017"; #else #define DT_MAJOR 2 #define DT_MINOR 3 #define DT_PATCH 0 #define DT_N_COMMITS 974 #define LAST_COMMIT_YEAR "2017" #endif The machine is: Linux Mint 18.2 Mate 64, AMD Phenom 1075, AMD Radeon 580, 24G RAM. With respect, Alexander Rabtchevich ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Aw: Re: [darktable-dev] possible data loss scenario
As I recall, I selected images with Ctr+A, entered new export path (Crtl+V, editing) - maybe in counter turn. Then I edited X resolution of the export, then selected y resolution digits in the control with mouse and started to enter digits. I thought dt hanged (it wasnot so, it was working changing rating), so I closed it and it closed without crash. When I opened it again I saw no images in the collection. After some investigations images were found with 0 rating. With respect, Alexander Rabtchevich Gesendet: Montag, 09. Oktober 2017 um 15:42 Uhr Von: "Patrick Shanahan" An: darktable Betreff: Re: [darktable-dev] possible data loss scenario * Alexander Rabtchevich [10-09-17 08:32]: > I'll do it at 6 O'clock. > Gesendet: Montag, 09. Oktober 2017 um 15:17 Uhr > Von: "Roman Lebedev" > Can you please show the output of $ cat darktable/build/src/version_gen.c > ? > > Gesendet: Montag, 09. Oktober 2017 um 13:51 Uhr > > Von: "Roman Lebedev" > > wrote: > >> git master > > Uhm, that is confusing. Which commit, specifically? > > > > I have expected that it was fixed by > > 5f87ee20f6589cb8ff995fd4dcce4506471dd5ec, > > which was first in 2.2.2 fwiw, I have 4c0754d03 and when "collect images" input box has focus, it keeps focus no matter where the mouse is positioned unless another area is "clicked". I have mis-typed here as a result but noted and take caution. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode ___ 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
Re: [darktable-dev] possible data loss scenario
* Alexander Rabtchevich [10-09-17 08:32]: > I'll do it at 6 O'clock. > Gesendet: Montag, 09. Oktober 2017 um 15:17 Uhr > Von: "Roman Lebedev" > Can you please show the output of $ cat darktable/build/src/version_gen.c > ? > > Gesendet: Montag, 09. Oktober 2017 um 13:51 Uhr > > Von: "Roman Lebedev" > > wrote: > >> git master > > Uhm, that is confusing. Which commit, specifically? > > > > I have expected that it was fixed by > > 5f87ee20f6589cb8ff995fd4dcce4506471dd5ec, > > which was first in 2.2.2 fwiw, I have 4c0754d03 and when "collect images" input box has focus, it keeps focus no matter where the mouse is positioned unless another area is "clicked". I have mis-typed here as a result but noted and take caution. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Registered Linux User #207535@ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Aw: Re: Re: Re: [darktable-dev] possible data loss scenario
I'll do it at 6 O'clock. With respect, Alexander Rabtchevich Gesendet: Montag, 09. Oktober 2017 um 15:17 Uhr Von: "Roman Lebedev" An: "Alexander Rabtchevich" Cc: darktable Betreff: Re: Re: Re: [darktable-dev] possible data loss scenario On Mon, Oct 9, 2017 at 2:53 PM, Alexander Rabtchevich wrote: > Pull from yesterday. Sounds scary. Can you please show the output of $ cat darktable/build/src/version_gen.c ? > With respect, > Alexander Rabtchevich > > Gesendet: Montag, 09. Oktober 2017 um 13:51 Uhr > Von: "Roman Lebedev" > An: "Alexander Rabtchevich" > Cc: darktable > Betreff: Re: Re: [darktable-dev] possible data loss scenario > On Mon, Oct 9, 2017 at 1:49 PM, Alexander Rabtchevich > wrote: >> git master > Uhm, that is confusing. Which commit, specifically? > > I have expected that it was fixed by > 5f87ee20f6589cb8ff995fd4dcce4506471dd5ec, > which was first in 2.2.2 > >> With respect, >> Alexander Rabtchevich > Roman. > >> Gesendet: Montag, 09. Oktober 2017 um 13:42 Uhr >> Von: "Roman Lebedev" >> An: "Alexander Rabtchevich" >> Cc: darktable >> Betreff: Re: [darktable-dev] possible data loss scenario >> On Mon, Oct 9, 2017 at 9:50 AM, Alexander Rabtchevich >> wrote: >>> Hello >>> >>> Yesterday I almost lost a three-years work. I selected 4-stars images >>> since >>> 2015 in lighttable and started to type image resolution in export >>> settings. >>> Cursor shifted a little from the control window due to mouse movement and >>> dt >>> recognized typed digit as a rating number. For my luck it was zero, not >>> 1, >>> so dt assigned 0 stars to the images and later I found them all. If the >>> mouse had shifted when I had been typing 1, I would not be able to >>> recognize >>> my selected works from 3 years anymore. >>> That had happened not for the first time, but the last one could be the >>> most >>> critical for me. >>> >>> Is it possible to hook keybord actions for the images in the lighttable >>> mode >>> only when the cursor is within the lighttable area? >> Which dt version? >> >>> With respect, >>> Alexander Rabtchevich >> Roman. >> >>> >>> >>> ___ >>> 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
Re: Re: Re: [darktable-dev] possible data loss scenario
On Mon, Oct 9, 2017 at 2:53 PM, Alexander Rabtchevich wrote: > Pull from yesterday. Sounds scary. Can you please show the output of $ cat darktable/build/src/version_gen.c ? > With respect, > Alexander Rabtchevich > > Gesendet: Montag, 09. Oktober 2017 um 13:51 Uhr > Von: "Roman Lebedev" > An: "Alexander Rabtchevich" > Cc: darktable > Betreff: Re: Re: [darktable-dev] possible data loss scenario > On Mon, Oct 9, 2017 at 1:49 PM, Alexander Rabtchevich > wrote: >> git master > Uhm, that is confusing. Which commit, specifically? > > I have expected that it was fixed by > 5f87ee20f6589cb8ff995fd4dcce4506471dd5ec, > which was first in 2.2.2 > >> With respect, >> Alexander Rabtchevich > Roman. > >> Gesendet: Montag, 09. Oktober 2017 um 13:42 Uhr >> Von: "Roman Lebedev" >> An: "Alexander Rabtchevich" >> Cc: darktable >> Betreff: Re: [darktable-dev] possible data loss scenario >> On Mon, Oct 9, 2017 at 9:50 AM, Alexander Rabtchevich >> wrote: >>> Hello >>> >>> Yesterday I almost lost a three-years work. I selected 4-stars images >>> since >>> 2015 in lighttable and started to type image resolution in export >>> settings. >>> Cursor shifted a little from the control window due to mouse movement and >>> dt >>> recognized typed digit as a rating number. For my luck it was zero, not >>> 1, >>> so dt assigned 0 stars to the images and later I found them all. If the >>> mouse had shifted when I had been typing 1, I would not be able to >>> recognize >>> my selected works from 3 years anymore. >>> That had happened not for the first time, but the last one could be the >>> most >>> critical for me. >>> >>> Is it possible to hook keybord actions for the images in the lighttable >>> mode >>> only when the cursor is within the lighttable area? >> Which dt version? >> >>> With respect, >>> Alexander Rabtchevich >> Roman. >> >>> >>> >>> ___ >>> 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
Aw: Re: Re: [darktable-dev] possible data loss scenario
Pull from yesterday. With respect, Alexander Rabtchevich Gesendet: Montag, 09. Oktober 2017 um 13:51 Uhr Von: "Roman Lebedev" An: "Alexander Rabtchevich" Cc: darktable Betreff: Re: Re: [darktable-dev] possible data loss scenario On Mon, Oct 9, 2017 at 1:49 PM, Alexander Rabtchevich wrote: > git master Uhm, that is confusing. Which commit, specifically? I have expected that it was fixed by 5f87ee20f6589cb8ff995fd4dcce4506471dd5ec, which was first in 2.2.2 > With respect, > Alexander Rabtchevich Roman. > Gesendet: Montag, 09. Oktober 2017 um 13:42 Uhr > Von: "Roman Lebedev" > An: "Alexander Rabtchevich" > Cc: darktable > Betreff: Re: [darktable-dev] possible data loss scenario > On Mon, Oct 9, 2017 at 9:50 AM, Alexander Rabtchevich > wrote: >> Hello >> >> Yesterday I almost lost a three-years work. I selected 4-stars images >> since >> 2015 in lighttable and started to type image resolution in export >> settings. >> Cursor shifted a little from the control window due to mouse movement and >> dt >> recognized typed digit as a rating number. For my luck it was zero, not 1, >> so dt assigned 0 stars to the images and later I found them all. If the >> mouse had shifted when I had been typing 1, I would not be able to >> recognize >> my selected works from 3 years anymore. >> That had happened not for the first time, but the last one could be the >> most >> critical for me. >> >> Is it possible to hook keybord actions for the images in the lighttable >> mode >> only when the cursor is within the lighttable area? > Which dt version? > >> With respect, >> Alexander Rabtchevich > Roman. > >> >> ___ >> 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
Re: Re: [darktable-dev] possible data loss scenario
On Mon, Oct 9, 2017 at 1:49 PM, Alexander Rabtchevich wrote: > git master Uhm, that is confusing. Which commit, specifically? I have expected that it was fixed by 5f87ee20f6589cb8ff995fd4dcce4506471dd5ec, which was first in 2.2.2 > With respect, > Alexander Rabtchevich Roman. > Gesendet: Montag, 09. Oktober 2017 um 13:42 Uhr > Von: "Roman Lebedev" > An: "Alexander Rabtchevich" > Cc: darktable > Betreff: Re: [darktable-dev] possible data loss scenario > On Mon, Oct 9, 2017 at 9:50 AM, Alexander Rabtchevich > wrote: >> Hello >> >> Yesterday I almost lost a three-years work. I selected 4-stars images >> since >> 2015 in lighttable and started to type image resolution in export >> settings. >> Cursor shifted a little from the control window due to mouse movement and >> dt >> recognized typed digit as a rating number. For my luck it was zero, not 1, >> so dt assigned 0 stars to the images and later I found them all. If the >> mouse had shifted when I had been typing 1, I would not be able to >> recognize >> my selected works from 3 years anymore. >> That had happened not for the first time, but the last one could be the >> most >> critical for me. >> >> Is it possible to hook keybord actions for the images in the lighttable >> mode >> only when the cursor is within the lighttable area? > Which dt version? > >> With respect, >> Alexander Rabtchevich > Roman. > >> >> ___ >> 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
Aw: Re: [darktable-dev] possible data loss scenario
git master With respect, Alexander Rabtchevich Gesendet: Montag, 09. Oktober 2017 um 13:42 Uhr Von: "Roman Lebedev" An: "Alexander Rabtchevich" Cc: darktable Betreff: Re: [darktable-dev] possible data loss scenario On Mon, Oct 9, 2017 at 9:50 AM, Alexander Rabtchevich wrote: > Hello > > Yesterday I almost lost a three-years work. I selected 4-stars images since > 2015 in lighttable and started to type image resolution in export settings. > Cursor shifted a little from the control window due to mouse movement and dt > recognized typed digit as a rating number. For my luck it was zero, not 1, > so dt assigned 0 stars to the images and later I found them all. If the > mouse had shifted when I had been typing 1, I would not be able to recognize > my selected works from 3 years anymore. > That had happened not for the first time, but the last one could be the most > critical for me. > > Is it possible to hook keybord actions for the images in the lighttable mode > only when the cursor is within the lighttable area? Which dt version? > With respect, > Alexander Rabtchevich Roman. > ___ > 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
Aw: Re: [darktable-dev] possible data loss scenario
OK, I have a backup of the database, but it is at least a mounth old. With respect, Alexander Rabtchevich Gesendet: Montag, 09. Oktober 2017 um 13:24 Uhr Von: "Moritz Moeller" An: "Alexander Rabtchevich" , darktable-dev@lists.darktable.org Betreff: Re: [darktable-dev] possible data loss scenario On 09.10.17 08:50, Alexander Rabtchevich wrote: > Yesterday I almost lost a three-years work. [...] > If the mouse had shifted when I had been typing 1, I > would not be able to recognize my selected works from 3 years anymore. So you are saying you do not have a backup? .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
On Mon, Oct 9, 2017 at 9:50 AM, Alexander Rabtchevich wrote: > Hello > > Yesterday I almost lost a three-years work. I selected 4-stars images since > 2015 in lighttable and started to type image resolution in export settings. > Cursor shifted a little from the control window due to mouse movement and dt > recognized typed digit as a rating number. For my luck it was zero, not 1, > so dt assigned 0 stars to the images and later I found them all. If the > mouse had shifted when I had been typing 1, I would not be able to recognize > my selected works from 3 years anymore. > That had happened not for the first time, but the last one could be the most > critical for me. > > Is it possible to hook keybord actions for the images in the lighttable mode > only when the cursor is within the lighttable area? Which dt version? > With respect, > Alexander Rabtchevich Roman. > ___ > 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
Re: [darktable-dev] possible data loss scenario
On 09.10.17 08:50, Alexander Rabtchevich wrote: Yesterday I almost lost a three-years work. [...] > If the mouse had shifted when I had been typing 1, I would not be able to recognize my selected works from 3 years anymore. So you are saying you do not have a backup? .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] possible data loss scenario
Hello Yesterday I almost lost a three-years work. I selected 4-stars images since 2015 in lighttable and started to type image resolution in export settings. Cursor shifted a little from the control window due to mouse movement and dt recognized typed digit as a rating number. For my luck it was zero, not 1, so dt assigned 0 stars to the images and later I found them all. If the mouse had shifted when I had been typing 1, I would not be able to recognize my selected works from 3 years anymore. That had happened not for the first time, but the last one could be the most critical for me. Is it possible to hook keybord actions for the images in the lighttable mode only when the cursor is within the lighttable area? With respect, Alexander Rabtchevich ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
