The 'X' buttons on text fields
Closed, ResolvedPublic

Description

Today I just noticed that we now have the 'X' icons always shown on text-fields (but only some of them). While I understand why they were introduced, there are quite a few quirks that still need to be ironed out IMO. Compared to the bigger 2.8 projects we've got going, this is really minor/low priority... but, it's also a simple little piece of polish that shouldn't take too long to apply.

Problem 1: Increased Clutter and Confusion About the Meaning of the 'X'

Consider the following screenshot:

In these two examples, we have cases where there are two 'X's in close proximity to each other, using the same icon, but communicating two very different things. Critically, clicking one of these has a relatively large impact, while the other has a relatively minor impact.

  • The "X Button" deletes that whole entity
  • The "Embedded X" clears the text in the textbox and resets it to some kind of default (well, in this case, it only actually works for the Group one, the GP Palettes one does nothing)

Problem 2: Some text-fields have it, others do not

From a user-perspective, it is bizarre that only some of the textfields in Blender have it.

(EDIT: Correction, the Outliner Search and Keying Sets fields do show the 'X' if there is some text set already; this behaviour makes sense, and it is nice, great even, that this functionality is in place for those buttons, as it is really necessary there. The only ones that don't seem to be the ID-block names, which are done using the old non-RNA buttons)

Proposed Improvements

1) Use a different (smaller and more lightweight) icon for the "clear textbox" function
This would solve the ambiguity problems, and better communicate the different roles and degree of importance of the functions

2) Have a way to indicate that name fields should be exempt from having an 'X'
Bascially, this would just involve adding another flag/optional parameter to the layout.prop() function that will skip adding this button.

IMO, there's little or no practical need to having a "clear" button on name fields with the way that we've got things set up. This is because to be useful, the clear button must leave the textbox empty after the action has been performed, so that the user can just start typing without having to clear the existing contents first. However, AFAIK name fields cannot be left blank; if cleared, most will instantly be repopulated with a default name, thus beating the whole point!

Therefore, I think it's best that we just leave off the 'X's from the name boxes. Alternatively, if anyone does think it's still useful to have this functionality, we should instead make it so that on name boxes, clicking on the X clears the box AND focusses it, so that you can start typing immediately (before the autoname kicks in).

Hello, I am just getting started out in blender dev. I think this task would be a great starting point. Can anyone give a general idea as to how I should go about editing the code? Thank you all :)

Bastien Montagne (mont29) triaged this task as "Normal" priority.Jan 6 2017, 2:01 PM

@Julian Eisel (Severin) any chance to tackle that quickly or even revert the commit you made that introduced it? It's not only cluttering the ui but makes so many places worse. Even the modifier names have X'es that reset the name to the standard name - it's simply useless. As I'm making 1000s of images now for my upcoming book I find myself constantly in GIMP erasing X es that should not be there.

@Aakash (ak_dev) No, this is nothing for a starter, there is a page in the wiki that handle starter tasks and you should definitely come to #blendercoders on irc - ask there.

@Thomas Beck (plasmasolutions) sure. Will look around the wiki and also ask on the IRC channel. Thanks for the reply though

The purpose of the 'x' icon was to have a quick way to clear the content of search/filter buttons. It's a common feature in modern UIs. It was not intended to have it for name buttons and such.
I tried to avoid adding new flags to RNA or UILayout.prop, hence I've tried approaches without doing this first. I'm confident that my last commit will work fine for the time being.

Oh also, I agree that the icons could be improved, but I think the ideal solution for this would be a more generic sub-button system. I implemented a simple version of this in rBc5d4607792b. Planning to get back to this for a proper integration of tab buttons, mainly for the upcoming topbar.

Add Comment