Project

General

Profile

Feature #8644

switching plugins on and off expands/retracts plugins

Added by Richard Wonka about 6 years ago. Updated almost 6 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Affected Version:
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

When I do a cross-check to see the effect of a certain plugin, I often switch the plugin on and off.
The interface then starts to expand and retract the plugin whenever I switch. This is unexpected behaviour (see principle of least surprise) and destracting and makes the user experience somewhat less smooth.

I would expect the little switch icon to just switch on and off the effect and only clicking the plugin's name to expand or retract that plugin.

Associated revisions

Revision 294103ca
Added by Jérémy Rosen almost 6 years ago

remove the auto-expanding feature fixes Issue #8644

History

#1 Updated by Simon Spannagel about 6 years ago

  • Status changed from New to Fixed

Hi richard,

I see your point - but those on/off buttons are not meant for comparing image versions. Just use either the history stack (just take the next to last item) or use our snapshot tool to compare two versions of an image.

We collapse and axpand the plugins with on/off because it saves you some clicking. If you enable it you (most certainly) need the controls - so we expand it. If you disable it this will mean you're not interested in using the plugin for development - hide the controls.

Do the above mentioned functions fit your needs?

regards,
Simon

#2 Updated by Tobias Ellinghaus about 6 years ago

Actually I also used to use the on/off buttons for comparison (which worked until recently), too. Moving the mouse to the history stack takes too much time.

#3 Updated by Richard Wonka about 6 years ago

I think switching a plugin on/off to compare and see its effect is a very common use case.
Essentially, this is what we want to see every time we use a plugin - we want to get an effect out of it and see the result.

Going to the history stack for this is simply a lot of pointer-travel and it's much harder to keep your eyes on the image when switching between stacked items.

You might be able to accommodate both ways by changing the behaviour just slightly:

  • Clicking the on/off icon just switches the effect on and off, without expanding/collapsing
  • clicking a collapsed plugin expands the plugin and switches it on
  • clicking the header of an expanded plugin collapses the plugin, but leaves it switched on.

The reasoning being that this accommodate the use-case of compare-switching and if someone expands a plugin, then they probably want to use it, so it is reasonable to switch it on

Would it be possible (and still efficient) to include each level in the stack as a virtual automated snapshot? that way, we might get the comparison-slider to do the same work nicely. - e.g. having a setting that always shows the next-to-last item in the stack as a snapshot would make life easy. - We'd have instant comparison between the image before and after using this plugin.

#4 Updated by Richard Wonka almost 6 years ago

  • Status changed from Fixed to Incomplete

Coming back to this one. Sorry, but the current implementation is obstructing my workflow.

Switching a plugin on and off is a very quick and intuitive way of checking its effects. Using snapshots and the stack is good in other situations, but not as quick and easy.

In the current implementation, expanding and retracting plugins clutter the workspace, distract from the image, forcing me to look at the UI instead of the image, and cause more clicks than they save. This could be avoided by allowing the user to enable a plugin without automatically expanding it:

  • Clicking the on/off icon just switches the effect on and off, without expanding or collapsing
  • clicking a collapsed plugin expands the plugin and switches it on.
  • clicking the header of an expanded plugin collapses the plugin, but does not change the enabled/disabled state.

This behaviour allows for more click-efficiency while allowing different approaches/workflows as well as the current one.

It still allows for one-click activation (as is currently only possible by clicking the power button), and adds the option of enabling a plugin (with its default values) without expanding the interface. Since the default values are meant to be sensible, this approach allows for very efficient processing.

So my proposed behaviour does not take any functionality away, but makes the UI somewhat more intuitive while adding ease of access.

Implementing this should™ also be relatively easy.

This is in line with the first GUI principle taken from the Wiki (Serve, don't distract) by serving more potential users the way they want to use the software and staying in the background while doing so.

#5 Updated by Ivan Tarozzi almost 6 years ago

I have the same problem, reported also in user mailing list on 8 may 2012.

Actually I have create a my local branch and created a new option to enable/disable the auto expand bahavior. I found auto expand annoying, so I keep it disabled.

If developer team want to evaluate my patch I will be glade to share it. But it is really simple, so no added value :)

If you are compiling DT from source and you want simply disable the auto-expand behavior, comment the line 410 in src/develop/imageop.c file.

Ivan

#6 Updated by Richard Wonka almost 6 years ago

Thanks Ivan,

this is so distracting that I'm almost ready to compile from source just to turn it off.
J
ust so I don't have the modules moving around on me and end up having to look for the module I am working with.

Please, developers, could you implement this?

#7 Updated by Ivan Tarozzi almost 6 years ago

I implemented this as new global preference options:
https://github.com/itarozzi/darktable/tree/feature%238644

PS:
because I'm not in dev-team and I don't know if this will be accepted and if it works as required, when I submit this trivial patch I don't change status, %complete and "assigned to" fields. Is that correct?

#8 Updated by Richard Wonka almost 6 years ago

Ivan,

in order to apply for inclusion in current master, please issue a pull request in github. That will facilitate the inclusion in the code for the developers.

#9 Updated by Richard Wonka almost 6 years ago

Oh, and thank you soooo much! Please come over to Thailand and I'll take you out for dinner (if this works, that is. I am about to find out now.)

:-)

#10 Updated by Jérémy Rosen almost 6 years ago

not sure how to deal with the percents yet, I don't think it's reallu that usefull, same thing for the start and end date. It makes more sense for big commercial projects than for open source projects

as for assigning yourself, why not... if you plan working on that FR some more. The assignment is a lock. the message is "I am working on it, so don't work on it" as long as that's the case, feel free to assign yourself

#11 Updated by Ivan Tarozzi almost 6 years ago

Jérémy Rosen wrote:
[...]

as for assigning yourself, why not... if you plan working on that FR some more. The assignment is a lock. the message is "I am working on it, so don't work on it" as long as that's the case, feel free to assign yourself

May be you're right, but I was waiting final workflow as discussed by Simon on other topic.

About assigning myself... I can't :)
This field is not editable but I can only choose a list of developers - or "Developers Group".

The same with "Status" field; I have only 3 options: Incomplete (actual) - Patch attached - Fixed.

I think "fixed" should be assigned by main dev-team, after a check of the committed code.
We could use "Patch attached" (can be confusing?) to signal we have a solution (but is not really a patch but a github branch).

A new status "I'm working on" could be useful :)

#12 Updated by Jérémy Rosen almost 6 years ago

  • Status changed from Incomplete to Patch attached

ok, being a dev I have access to all options and wasn't sure exactly what you can do

the status "patch attached" actually means that there is code available somewhere, including but not limited to git pull requests, so that status makes sense here

i'll point simon to this discussion when I see him around

#13 Updated by Jérémy Rosen almost 6 years ago

Ok, I've tested both ways of working and I tend to agree with the idea of this patch, however here are a couple of things I don't like about it

  • This shouldn't be an option, I think the UI is wrong
  • We need an easy way to "fold all but this plugin" ths could be shift-click or middle click or something like that. Not sure what other UI do in that case
  • This was specifically added by Hanatos, so i'll wait on him before addding it.

this whole folding/activating/history UI needs to be cleaned up, but we need a consistant view to do that, and we need to rely on least surprise as much as possible

#14 Updated by Ivan Tarozzi almost 6 years ago

Jérémy Rosen wrote:

Ok, I've tested both ways of working and I tend to agree with the idea of this patch, however here are a couple of things I don't like about it
  • This shouldn't be an option, I think the UI is wrong

I implemented this as option (and UI global preference) because I had heard not all people like this new behavior.
I think for these trivial changes (1 line of code!) we can use an option, to meet all needs without accept or reject a feature not 100% well-liked. But is just my opinion :)
May be for minor options could be useful a new panel (let say "advanced options"?) to leave clear main panels. I don't like file editing only because with your xml management is really simple to add a new option and non technical users could found annoying open an editor to change an option (and prevent errors too).

  • We need an easy way to "fold all but this plugin" ths could be shift-click or middle click or something like that. Not sure what other UI do in that case

I'm confused: actually already works shift-click...

  • This was specifically added by Hanatos, so i'll wait on him before addding it.

I agree. I found this feature very useful, and other users too, so I implemented here without wait confirmation because was really simple. But before merge in main is correct wait Hanatos comments!

#15 Updated by Richard Wonka almost 6 years ago

Actually, exclusive expansion sounds like it would be worth an option in the settings. So it acts as if it's always a [shift]-click. I'd go for this, but I'm sure not everybody will like it.

#16 Updated by Jérémy Rosen almost 6 years ago

  • Status changed from Patch attached to Fixed

Also available in: Atom PDF