Project

General

Profile

Bug #8749

Metadata disappears if cursor is moved over another image before applying.

Added by F M about 8 years ago. Updated almost 7 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Lighttable
Target version:
Start date:
06/04/2012
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

When entering title, description, creator etcetera: if the cursor is moved to be over different image on the "light table" whatever has written is immediately and permanently deleted and replaced by the metadata for the image that is under the cursor.

It might be better if the metadata entered was auto-saved or else stayed until it was applied or another image was selected.

Associated revisions

Revision 71fa1aa9 (diff)
Added by Tobias Ellinghaus almost 7 years ago

Fix #8749 Apply metadata when mouse moves

This however breaks single image mode slightly. Whatever.

History

#1 Updated by Simon Spannagel about 8 years ago

  • Target version set to Candidate for next patch release
  • Status changed from New to Confirmed

I can confirm this.

Maybe we should change that module not to be sensitive to mouse-hover but only to selection of images?

#2 Updated by Simon Spannagel about 7 years ago

  • System set to all
  • Affected Version changed from 1.0 to 1.2
  • % Done changed from 0 to 20
  • Target version changed from Candidate for next patch release to Future
  • Status changed from Confirmed to Triaged

probably needs some more thorough discussion.

#3 Updated by Torsten Bronger almost 7 years ago

Proposal:

The metadata module should get a "modified" flag. It is "false" by default. It becomes "true" when the user enters data. If it is "true", the "delete" button is a "discard" button instead, and the module doesn't adopt anymore data from selected images. Clicking on "discard" or "apply" performs the respective action, and sets "modified" to "false" again.

The "tags" module has a similar problem, albeit much less serious.

#4 Updated by F M almost 7 years ago

I would suggest that if possible the metadata be updated in real time as it is entered with an undo option using <ctrl> Z instead of the added step of applying or discarding metadata edits.

#5 Updated by Tobias Ellinghaus almost 7 years ago

  • Tracker changed from Bug to Feature

All of this might be an addition that's useful, but it requires 1) someone to write the code and 2) someone to convince the core developers to accept something like that. And 2) is at least as important as 1).

#6 Updated by Torsten Bronger almost 7 years ago

Right, but how do we settle on the desired behaviour?

#7 Updated by Tobias Ellinghaus almost 7 years ago

The current one is the desired behaviour. If anyone wants something else we need really good arguments.

#8 Updated by Torsten Bronger almost 7 years ago

It is possible to lose data just be moving the mouse (without clicking). The evaluation of this fact is personal, however. I personally find this behaviour

  • surprising
  • irritating
  • without benefits

But this aren't arguments, just my milage. I assume, however, F M has the same opinion. So AFAICS, the devs must evaluate this request from here.

#9 Updated by Richard Wonka almost 7 years ago

Torsten Bronger wrote:

It is possible to lose data just be moving the mouse (without clicking). The evaluation of this fact is personal, however. I personally find this behaviour

  • surprising
  • irritating
  • without benefits

That is my assessment, too. In all other applications, the content of a text field is applied when keyboard focus leaves the text field. As far as I can remember, I have only seen darktable behave differently.

All of these are a direct violation of the design principles the devs (claim to) apply in dt as described in the wiki. Going away from commonly known and applied functionality is surprising and as such tends to grow frustration in users and makes learning to use dt harder than necessary.

But this aren't arguments, just my milage. I assume, however, F M has the same opinion. So AFAICS, the devs must evaluate this request from here.

Problem for someone who is not a coder is that they don't have to and tend to accept and recognise bugs as such only when they like to. This is their right and prerogative, as well. It adds a certain charm and a certain randomness to the project, as users opinions don't seem to be so highly valued. In the end, the devs write darktable with a very high priority for their own use and workflow.

There seem to be differences in the understanding of what dt is within the developers, which does not make it easier, either. e.g. dt is supposed to be a RAW developer only, yet it has collection management features; it will also never have file management features, but moving pictures between film rolls has been implemented. The key seems to be to call a feature by a name the devs like, then it will be acceptable. :-)

#10 Updated by Tobias Ellinghaus almost 7 years ago

  • System set to all
  • Affected Version set to git development version
  • Tracker changed from Feature to Bug

First of all, you don't lose data. Just type and hit enter and you are GTG.

If it really annoys you so much that you shouldn't move your mouse around while typing (I can't even imagine how you manage to do that in the first place) then for fuck's sake we will accept this as a bug.

#11 Updated by Tobias Ellinghaus almost 7 years ago

  • % Done changed from 20 to 100
  • Status changed from Triaged to Fixed

Applied in changeset darktable|commit:71fa1aa985bfb8598fcdfac430c417ab7b1e04a9.

#12 Updated by Richard Wonka almost 7 years ago

May I suggest the solution of instantly applying any changes? It seems the simplest solution with the least amount of surprise.

EDIT: Hadn't read the update. Thank you for this.

Also available in: Atom PDF

Go to top