Switch Ctrl+Click and Click Behavior for Opening Panels?
Closed, ResolvedPublic

Description

Switch Ctrl+Click and Click Behavior for Opening Panels?

Motivation

People often have to spend lots of time to organize the opened/closed panels, as their screens quickly end up being unnecessary unorganized and messy otherwise. As a way to avoid this, the option to hold Ctrl while clicking on the panel header to ensure only the clicked panel is open, was added. While this already helps, some users find it annoying having to press Ctrl continuously to keep things organized (and because of that, many people don't use it at all).
Furthermore, this is hidden functionality.

Proposal

Add an UserPref option to switch the click and Ctrl+click behavior.
It might also be better to use Shift instead of Ctrl, as this is the consistent way of expanding selections in Blender.

Conclusion

Using this proposal, we give it to the users hands to decide which behavior to use, the main question is just if this is worth adding an option to the UserPrefs.

Details

Type
Design

This seems like a really tight corner-case to add a new user option for. I can understand the motivation but if we added an option for all of these little annoyances we'd have an unusable set of user preferences, simply due to the sheer volume.

I feel time would be better spent improving the organization first, such that users don't have to spend as much time switching and opening/closing panels.

-1

A big set of User Preferences does not become unusable IMO, mainly because they all sit in a window that is usually closed. It's like a questionnaire that you fill once, to set the program to your liking, and then forget about it. The more questions there are, the more "to your liking" the program will become after filling it. "Auto Perspective? <reads description> Uuh, I'll have some of that. Python tooltips? Nah, I won't really need that."

Buttons in your day-to-day GUI should be as scarce as possible. Options in the Preferences don't have to.

A real world example - μTorrent has 17 sections in the Preferences, with around 15 toggles on each (that's around 255 toggles). I might count it better if I have time. Is it a problem? Nope. μTorrent is one of the more popular torrent clients.

Panels are not going away - I'll say it's safe to put this option in, however the GUI is going to change in the future.

+1 to that.

Good points @Paweł Łyczkowski (plyczkowski). However, we should still only added new options when we can't find a better solution to a significant problem.

If there's ample evidence that this is in fact a problem for a lot of users (I've never personally experienced it being an issue) and we cannot find a better solution then sure, an option is a good fallback. Let's just not fallback to yet another option as the first solution.

@Julian Eisel (Severin), who are these "some users" that you mention? I'm just curious to see the reports of problems.

@Jonathan Williamson (carter2422), I remember being asked about this in person a couple of times (can't recall who exactly), then there is a BA thread about this and most recently @Paweł Łyczkowski (plyczkowski) asked for it (which is the reason why I created this now).

For me, this would be a I'm-fine-with-it-but-I-don't-really-mind change.
If this is really something people desire, it's totally fine with adding an UserPref option IMHO.

We say on one side that the user interface has made with consistent behavior in mind but in the other side make all sorts of exceptions everywhere. For example i just found this:

  • In 3D view (edit) SHIFT RMB adds to current selection while RMB alone replaces current selection
  • In the tool shelf: CTRL LMB replaces open Panel while LMB opens another Panel and keeps the rest open

When we wanted to be super consistent then we probably would need to do this:

  • In 3D view (edit) SHIFT RMB adds to current selection while RMB alone replaces current selection
  • In the tool shelf: SHIFT RMB opens another panel and keep others open, while RMB opens panel and closes all others

And then make this behavior consistent with the LMB/RMB settings

However i believe the common expected behavior (and the one i'd rather prefer) would be more like:

  • In the tool shelf: SHIFT LMB opens another panel and keep others open, while LMB opens panel and closes all others

just my half cent here :)

With this coming up in the mailing list again, thoughts adding this as a user prefer after all @Julian Eisel (Severin)?

Wouldn't this also change how the properties editor works as well? While I wouldn't necessarily be opposed to a change in the tools and properties regions, I wouldn't be comfortable changing the properties editor to conform.

For example, the rig property categories are often toggled one at a time because there are settings that no longer need to be accessed, so the artist will collapse it. I would argue this happens more often than simply needing one panel expanded. It is the same in the render settings.

@Jeffrey Hoover (italic_) Please notice this is about adding a toggle that can change the behavior, and not changing the default behavior.

I'm not arguing the UP toggle; I'm fine with having a toggle. However, is the plan to make it consistent across the entire UI or only the tools and properties region in the 3D View? or other editors? What is the scope of the change? I want it defined as part of the design, not a byproduct of one use-case.

I would just add a toggle that switches the behavior for now (yes, affecting all panels @Jeffrey Hoover (italic_) , who said only tools and properties?)

Changes affecting things that people are used to are best introduced in big bundles IMO, so "oh, this suddenly does not work" becomes "oh, there has been a UI-consistency improving release, I'll better get ready for the changes".

Julian directed me to this task after a brief exchange about the tools region on the interface list, so I wanted to make sure this is exactly what you intended, rather than just the viewport regions. I absolutely agree with consistency and I'm fine with big changes.

This seems a quite obscure option: "Special option for group of users who like (by default) to only have one panel open".

While am not so much against having options for small groups of users who really want them, this seems to be getting real specific (we could have easily 10-20 options for how other parts of Blender's UI can be interacted with too).

These kinds of changes are more *workarounds* than solutions. Ok, but more of a last resort when we cant extend the UI to accommodate for it.

Also not really convinced that users spend so much time layout out their panels, from what I've seen users will make a few changes to the layout, then only make minor changes as they work.
though on a small screen I suppose its more of an issue.

Rather avoid this, mainly because changes here expose other annoyances.
Where users will be using panels quite differently, and may want other parts of panels usage to change - for eg.

  • Request that buttons be grouped on one panel because they don't like having to switch all the time.
  • A way to make material Preview-Panel an exception and have it stay open even though all other panels close... Maybe thats ok... then add-on's authors want to make _their_ panels exceptions too.

So -1 even as an option.

This seems a quite obscure option: "Special option for group of users who like (by default) to only have one panel open".
While am not so much against having options for small groups of users who really want them, this seems to be getting real specific

IMO this is not a obscure option - it's the default for a whole other program for instance (ZBrush). But I agree it's not a perfect solution for panelitis, since it means switching panels all the time - panel hiding may be a better solution?

I would actually use something like this. While I agree it's not the cure for panelitis, it's a good palliative.

Maybe instead of adding a specific option, it would be better to expose the key-bindings to the input editor? At least, Ctrl+LMB, LMB and a (toggles the panel).

@Diego Gangl (januz), agree, would be better to expose key-bindings for the UI.

Did anyone look into this? - Panel key-bindings would be a good place to start since theirs only a handful.

Julian Eisel (Severin) closed this task as Resolved.Feb 27 2016, 2:24 AM
Julian Eisel (Severin) claimed this task.

Talked briefly with Campbell on IRC about this, the way to go here is making panel interaction shortcuts configurable. We both added it to our fun-weekend-projects list, so it won't be forgotten. Closing the task since I think more discussion isn't needed.