The 'X' buttons on text fields #50336

New Issue

Joshua Leung · 2016-12-29T03:57:21+01:00

Joshua Leung commented

2016-12-29 03:57:21 +01:00

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).

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: ![20161229-x-wtf-01.png](https://archive.blender.org/developer/F424332/20161229-x-wtf-01.png) 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. ![20161229-x-missing.png](https://archive.blender.org/developer/F424335/20161229-x-missing.png) (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).

Julian Eisel was assigned by Joshua Leung

2016-12-29 03:57:21 +01:00

Joshua Leung commented

2016-12-29 03:57:21 +01:00

Changed status to: 'Open'

Joshua Leung commented

2016-12-29 03:57:21 +01:00

Added subscriber: @JoshuaLeung

Aaron Carlisle commented

2016-12-29 04:00:01 +01:00

Added subscriber: @Blendify

Aakash commented

2016-12-29 06:07:43 +01:00

Added subscriber: @aakashkt0

Aakash commented

2016-12-29 06:07:43 +01:00

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 :)

Thomas Beck commented

2017-01-10 18:16:19 +01:00

Added subscriber: @plasmasolutions

Thomas Beck commented

2017-01-10 18:16:19 +01:00

@JulianEisel 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.

@aakashkt0 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.

@JulianEisel 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. @aakashkt0 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.

Aakash commented

2017-01-10 18:59:45 +01:00

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

blender-admin commented

2017-01-11 22:11:13 +01:00

This issue was referenced by c4f60319d1

This issue was referenced by c4f60319d1709723d8076429c13965b0c94dc88b

Julian Eisel commented

2017-01-11 22:23:16 +01:00

Changed status from 'Open' to: 'Resolved'

Julian Eisel closed this issue

2017-01-11 22:23:16 +01:00

Julian Eisel commented

2017-01-11 22:24:04 +01:00

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.

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.

Julian Eisel commented

2017-01-11 22:46:52 +01:00

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 c5d4607792. Planning to get back to this for a proper integration of tab buttons, mainly for the upcoming topbar.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

The 'X' buttons on text fields #50336

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

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

Proposed Improvements