Multi-Object Properties Editing #54862
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
60 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#54862
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In Blender, we want to make it easier to set values for multiple objects, bones, strips, keys and other items at once.
Currently you can do this in limited circumstances, but you have to right-click on a value after you've changed it and pick Copy to Selected from the menu or hold Alt while editing values. This not only slow, but also very hidden, and the Alt-key conflicts with Emulate 3 Button Mouse. Lastly, it isn't clear at all to users which values work for multi-editing, and which values don't.
Here's how we would like to solve it:
Selection vs Active
The concept of active in Blender means that we only show properties and only affect the active object or item. However, if we want to better support multi-item editing, we must start by making it so the Properties reflects the selection rather than the active item, of which there can only be one. Going forward, by default the Properties will be set to reflect the selection instead. This could be controlled in the Properties like so:
{F8363009, size=full}
(The search box is added here to reflect how the Properties will be updated when that item is also added, but is a separate feature)
If set to Active, the Properties will continue to function as it does today, only showing properties for the active item.
When there are multiple selected items
When the user has selected multiple items, a few things change:
Instead of showing the name of the object at the top, Blender tells the user how many items are selected:
In the list of tabs, only properties sections are shown that are common among the selected items. For example, if you select a text and a mesh object, we don't show Modifier, Mesh or Curve Properties, since these properties only exist on a subset of the selected objects:
This rule also goes for individual panels. Here, both a Sun and Spot light are selected, and we only see properties that are shared between them. A note at the bottom clarifies that you are only seeing the shared subset:
{F8364914, size=full}
When values differ
When multiple items are selected, Blender will compare values to check if they are the same, or if they are different. If they differ, we change the way properties are displayed, like so:
{F8363037, size=full}
Manipulating values across multiple items
For simply setting a value to be the same. you would simply type a new value, hit Return, and that value is then propagated to the selection.
For manipulating numbers and sliders relatively, you can just drag on them (like Alt-dragging today), or type the character '=', so the user can type '= -3' to subtract 3 from the value on all selected items.
Added subscribers: @WilliamReynish, @ideasman42
#54987 was marked as duplicate of this issue
Changed status from 'Open' to: 'Resolved'
Added subscriber: @EvandroFerreiradaCosta
Hello. If I can make a suggestion... on top of the proposed ideas, which I think are great, would be to use the Alt+Edit current behavior, but inverted.
On 2.79, if you select multiple objects and press Alt before you change something (not everything is supported), this change propagates to everything selected.
Now, on the proposal of automatically changing everything and showing it through an outline/color is great, but it would also be handy to be able to to the opposite: without deselecting everything, changing only the last (current active) selection. And my proposal is to use the current Alt+click behavior. If the user simply hovers over a field or checkbox, it is outlined and everything selected can be changed. But if the user pressed Alt beforehand, the outline would disappear and then only the (current active) last selection is changed (without the need of deselecting everything).
@EvandroFerreiradaCosta: Yes, in fact we already did discuss exactly that. Updated the description to reflect this.
Added subscriber: @DuarteRamos
Added subscriber: @JacquesLucke
Added subscriber: @0o00o0oo
Added subscriber: @SteffenD
This task is marked "Closed, Resolved" but the functionality is not yet inside 2.80. So is this still on the agenda?
Added subscriber: @brecht
Resolved here means the design is approved. There is a separate task about implementing this: #54987 (Implement Multi-Object Properties Editing).
Oh I see. Thanks!
Added subscriber: @Zuorion-4
What about how object properties values are displaye·d?
I think if default behavior will be editing multiple values, so as displayed values should also be somewhat consistent with that. With "?"/"-" mark or averaged value.
Eg like that:
That is seemingly not possible technically. The issue is that then Blender has to compare many many values to determine if they are the same or not, which is actually a slow operation. The design described in the task gets around this limitation.
Added subscriber: @michaelknubben
Added subscriber: @Nodragem
Unity allows that, and it shows "--" when the values are different. It is quite handy to be honest.
An average does force you to go though all the values, but to test for the object being different may save some computation time?
When you say many many values, are we speaking of 100 or 1000 or more?
I just fired up my old and trusty Softimage 2015 because it had a very nice multi-select behaviour: If you select 2 or more objects with different attributes, it displayed an empty value for everything that wasn't set to the same value in all objects. If you now typed in a new value it set it to the same for all objects. BUT: if you entered something like "2+" it added 2 to all of the selected objects' property values. Very very nice. You could even enter expressions to e.g. randomize a value per object.
Softimage_Multiselect.0219-1541.mp4
Added subscriber: @kalmdown
New to Blender but designed VR IDEs and 3D MRA packages.
Would nix the Opt/Alt key option because it forces the user to think if they want to edit multiple objects. The likelihood is that if they have selected multiple objects they want to edit the selected objects.
The experience just needs to indicate that the value varies across the selection set. Keeping the value of one of the selected infers that value has some kind of precedence. If it doesn't then the field can either be blank or show something like to indicate that the field now spans multiple values.
Some choices are decoration in the field ( colors, ), or decoration on the field (border or badge).
The solution should take into account other indicators that may be needed in the future - ie It would be good to indicate if a value was being driven or had an equation, or was scripted.
Here are some variations showing how some choices, like using decoration for how value is derived means that option is out for indicating multiple selection.
ADA Section 508 sets standards for contrast and readability so the colors should be adjusted to meet that.
I appreciate how SoftImage ties the field colors to the axes. Reduces the cognitive load when trying to decide which field to change. Would like to see that implemented as a preference.
A few additional thoughts...
1st - When there are multiple selections many fields throughout the Number Panel and Properties will have differing values. Decorations per field is too visually noisy.
2nd - Use consistent visual affordances between places that indicate selection.
Maybe not a bright orange header, but that is the selection color.
3rd Make it apparent how value is being derived - like how keyframes show that a value is animated.
The current design, where animation colors fields makes it difficult to show other affordances since it uses several colors in tones that are hard to find complements for. so getting colors to go with the ones that fill fields for animation would need some work. If animation state could be switched to text color or a smaller decoration then giving equal weight to whether the filed is driven would be easier.
4th - Provide consistent interaction affordances across the app (not just the Number Panel)
@kalmdown Of course, that is obvious. The difficulty of that is one of performance. Blender then has to compare many values to see if they differ or not. But, many other apps seem to do this with no issues, so it must be technically possible for us to do.
@WilliamReynish Looking at the space from the user POV (vs performance) - Do users want to have animation, driven, keyframed control for every property? If so, then they need the ability to control every property. To have control they can interpret with minimal error they need to understand the state of controls. One of the states of properties is multi-select - thus they need an experience that lets them understand any property that can be driven/animated when there is a multi-selection.
Additionally, the user works fastest if they understand all of the factors that affect a property. To do this, knowing all of the things which affect a property is useful. What things do they need to know that can affect properties? Animation, Drivers, Nodes and Code. Assuming these can be additive or override each other, what experience helps the user understand what is affecting a node? Currently, the system displays different states of animation or whether a property is driven, but not both. Going forward it would be good to be able to drive and animate plus have a nodes and code affecting the property - and know if the result was through these in combination or via overrides.
@WilliamReynish hmm, in editmode, transform pannel is already being calculated in realtime for milions of vertices
And its calculating mean value and not only checking if they are equal.
If it is causing editmode performance issues then that should be dissabled, if not then making same for object-mode shouldn't be a performance problem cause in editmode we have way more entities than in object mode.
@Zuorion-4: Averaging is not the same as comparing. Anyway, this is more depending on implementation rather than a purely design issue.
Changed status from 'Resolved' to: 'Confirmed'
During the recent UI planning session, we decided that we would like to tackle multi-object editing a different way than earlier proposed. This new solution requires bigger changes and is more work, but ultimately this way is simply clearer and more useful.
Added subscriber: @JulienKaspar
AutoCAD alike also use a similar concept for its properties dock which works relatively well.
They additionally have a dropdown menu on the top, which allows filtering by selected object type.
If you have a mixed selection of different types objects you can use the dropdown to select a certain type, and show only properties respective of that type.
Added subscribers: @AbidMaqbool, @tintwotin, @nokipaike, @testure, @Josephbburg, @Yashar, @FrancoisGosselin, @OliverVillar, @Harley, @TakeshiFunahashi, @A.Lex_3D, @GeRo, @DanielPaul, @AndrewPrice, @00Ghz, @JulianEisel, @liquidape, @bliblubli, @mont29, @Januz, @Lapineige, @dairin0d, @BrendonMurphy, @zeauro, @billrey, @eugenio_jr, @Tene, @BartekMoniewski, @JonathanWilliamson, @koilz, @rulkens, @PawelLyczkowski-1, @JonathanLampel-4, @thornydre, @DanPool, @L0Lock, @Rusculleda, @Okavango, @Sergey
This does seem better, but some notes:
Filtering these properties based on “Selection” versus “Active” does seem nice, but might highlight that some areas are not based on either, like “Render” and “Output”. Is is worth considering moving those out of Properties?
With the previous plan it wasn’t “clear at all to users which values work for multi-editing, and which values don't” and that part does not seem addressed here. So with multiple items selected, how are properties shown that cannot be multi-edited? Hidden would be problematic. Disabled maybe?
Some of the proposed behavior when values differ seem unclear. I worry that toggle buttons and Enums will appear disabled.
You show “horizontal ellipsis” on a differing-value color field, but that would indicate a following menu. Although that happens with those inputs – a color picker popping up – it does not indicate that the values differ. Perhaps a way to indicate "not a single color" with a color range or rainbow perhaps?
I realize that using “dash” as you propose is not completely unusual, but I find it too evocative of negation. Might be worth considering using "not equal" : ≠
Removed subscriber: @tintwotin
I should have clarified that. This would not affect those Properties sections.
The only reasonable way I can seem is to only show properties that are available on all selected items. Take the example in the task, where a Point and Sun light are both selected. Point lights have a Radius property, but Sun lights have an Angle property. If we react to the selection instead of the active item, we could either show both or none of those properties. Showing one of them doesn't work - it only makes sense when you use the active option. Showing none of them is much clearer, because they you know that everything you see can be multi-edited, and otherwise our layouts might also break if we try to merge layouts to show all properties.
I used that because it is a standard indication of this kind of state.
I would much rather use an indicator that is standard across our supported OSs, rather than try and invent our own non-standard language that nobody would be familiar with.
Added subscriber: @hadrien
Hiding properties and property contexts that only exist for a subset of the objects doesn't sound reasonable to me : that would mean the user can't add a modifier to an object even though it is selected and active, when their selection also contains objects of a different type that don't support modifiers (or support a different list of modifiers). It also means the user can't modify -or even see- a property of the same object for the same reason, ie it is not shared with all other objects in selection. This seems very error prone to me, and rather constraining : in order to do the actions outlined above, the user has to change selection state - keep only the active object in selection to edit its (unique) properties, or keep everything and be restricted to what they have in common, which can be a very small subset of all properties (for a mesh object and a curve object, that would happen to be only object, constraint and material properties - which means that the user would lose access to data, physics and modifiers contexts).
I hope this makes a good point against the 'hiding' part, but I second all the other aspects of this proposal : I think the improvements suggested are good, and clarifying the selection state in the properties header is a great idea. Hiding just seems like a regression and not really necessary.
@hadrien If set to use the selection rather than active, there is no active object to determine what should be shown. That's the whole point - to reflect what is selected rather than what is active. And for this reason, there is no way to show all properties - we can only show properties that are common. This means that you can also easily add modifiers to multiple mesh objects, and so on.
There is no real hiding going on. That only makes sense if you think of properties as always showing you options for the active object, which would not be the case here. Instead, it is showing what is available on both selected objects.
Added subscriber: @TakingFire
Added subscriber: @LucianoMunoz
Added subscriber: @ckohl_art
Added subscriber: @moisessalvador
Any plans for multiproperties editing for every data type on the Sidebars of all the editors and modes? Nodes, video strips, track points, mask splines and points, Greasepencil layers, Fcurves and keyframes, NLA tracks and strips, plus the modifiers that some of them have, etc
Added subscriber: @RobertS
When this is implemented, please add a toggle to affect active/entire selection by default on the splash screen like you have with the left/right click and space bar options.
Added subscriber: @jc4d
@moisessalvador yes, once there is a system in place for handling this, it should also be used for other places like the Sequencer, F-Curves. NLA and so on.
Added subscriber: @LeoSch
Added subscriber: @lsscpp
Little thought: would it be more clear if a math "not equal" symbol (≠) is used in not-equal fields when more than one object are selected?
@lsscpp I don't think it would, because the dash is a standard glyph used for this purpose.
Added subscriber: @HooglyBoogly
Added subscriber: @ColeReed
Awesome to see this work! Copy to Selected has been a thorn in my side for all of time (I think i get the order wrong every dang time too).
Anyway, great work! One minor copy suggestion below.
This contextual info text felt a perhaps a little more complex than necessary (to me).
"Items that only exist on some of the selected items cannot be multi-edited"
Just some possible alternatives:
"Only properties shared between selected items displayed"
"Only shared object properties currently displayed"
"Currently displaying only shared object properties"
"Only shared item properties can be multi-edited"
Cheers!
Added subscriber: @Schiette
Added subscriber: @3di
This functionality already exists in blender. For example if you have one box with a x scale of 1 and another with an x scale of 0.5, if you select both objects (0.5 active) and change the value from 0.5 to 0.6, then pressing alt + enter changes the 0.5 to 0.6, and changes the 1 to 1.1 ( increasing both by the same value).
If you press alt when clicking into the box, then both boxes change to the same value after you press enter (without alt)
Removed subscriber: @TakingFire
Read the second paragraph.
Added subscriber: @Jasiek
Copy To selected doesn't work for UV Slots in 2.83, which is extremely annoying when I have to add UV's to multiple objects for editing their UV's in multi edit mode.
Added subscriber: @DirSurya
Added subscriber: @Oskar3d
Added subscriber: @Radivarig
Added subscriber: @Jaye.Antoni_Whyldz
Added subscriber: @giuseppebufalo
Added subscriber: @slowk1d
Added subscriber: @Aurontwist
Added subscriber: @YAFU
I have tried to copy "use camera cull" from active to multiple selected objects, and do it from right click on checkbox > Copy to selected, it doesn't work.
It would be great if this task could receive more attention.
Thank you.
Added subscriber: @RedMser
Added subscriber: @dinhdong
Multi editing should also work with custom properties, currently doesn't work.
Added subscriber: @APEC
Added subscriber: @Slowwkidd
Added subscriber: @Mentales
Added subscriber: @Even
Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe
Added subscriber: @Macilvoy
Added subscriber: @haohao
Added subscriber: @KevinCBurke
I believe this design best addresses one of the most confusing things about modern Blender.
I've spoken to @WilliamReynish and (in my opinion) it doesn't sound like there's been an appropriate amount of priority given to its implementation (read: zero).
Implementing a design in Blender to affect multiple objects at once would advance the application exponentially in usability and continue the UX progress made in 2.8. Where, if not a 3D application, do you need to easily edit objects simultaneously? Also, 2.8 was proof that making Blender more user-friendly will greatly affect its growth and future adoption.
Yes, I know about the key commands, but to new Blender users like myself, there should be contextual UI showing the user how to manipulate the objects they selected. The concepts of 'Active' and 'Selected' + needing to use Alt to change multiple objects in the UI is a siloed user experience to Blender: it won't be a solution a user will likely reach without being told. If functionality or an older paradigm is sacrificed in order to achieve a greater user experience for more people, I believe this is the best way to go: especially as Blender is the best option for the general public who cannot afford other 3D application licenses. The tool gets in the way less when it shares UX with other applications (or provides means to those expecting different behavior to achieve their goals). That's not to say Blender's unique features should be sacrificed: it's the user interaction that could be better.
Here are a few of the bugs & designs reported because of the confusion in the interface.
[#14429 ]], https:*developer.blender.org/T65219 , https:*developer.blender.org/T82359 , https:*developer.blender.org/T68647 , https:*developer.blender.org/T81922 , [ https:*developer.blender.org/T94174 | #94174
@brecht, @ideasman42 , @HooglyBoogly & @JulianEisel, could we please get your support and priority in this design? It is a Blender-wide change and needs your assistance to progress. If you see major flaws in this design, I will be happy to work with you to get it more to your liking. Thank you.
Added subscriber: @BClark
Agree with @KevinCBurke and adding a second to this
I think we all agree that we really want this, it would be a great usability improvement.
But yeah, it's not so easy (TM). The design is not ready, and there currently isn’t anybody to work on it, and neither is there anybody with the time to work on the implementation. This design task only covers the basic, simple cases not the more complex ones: Modifiers/constraints (editing multiple objects with different constraint/modifier stacks), materials (multiple objects with multiple different material slots), vertex groups & shape-keys, assets (e.g. selecting multiple assets in the Asset Browser and editing tags), nodes (at least simple setups like the default Principled BSDF may be expected to work) ... Another thing is that "active" will still be an important concept in Blender, just less prominent. In some ways that's good, but sooner or later every beginner will face it, and then it will be even more unfamiliar than it is already. Maybe that’s fine but it needs careful design and evaluation.
A technical challenge is implementing things so UI performance doesn't become an issue, comparing the properties of all selected items to see if they differ, so that can be signalled in the UI can be rather expensive, without careful technical design. Blender is just not designed around this.
Lastly, changing the default behavior like proposed here would be a major design change, that we can't easily do in non-major releases.
Even with multiple people, this will be a project with months of work. So while I'd love to see this happening sooner than later (I pushed for it long before 2.8 already), I don't see it happening before 4.0. Sorry for the negativity, but we just have to be realistic here.
Removed subscriber: @moisessalvador
Thanks for the reply and explanation, @JulianEisel . I'd be happy to contribute designs for this when the time comes.
Added subscriber: @lichtwerk
This should work (and it does on my side), if this is still not working, mind reporting this as a bug and subscribe me there?
This should also work now, I added support for this recently, see
d6902668e3If this is not working for you, mind reporting this as a bug and subscribe me there?
UI lists are one thing where this system is "weak" (in that it does not meet expectations),
Copy To Selectedonly copies the list/slot index, it does not handle creating/copying/filling missing slots, same for Materials.This would probably need a dedicacted operator (such as the ones for vertex groups or materials) instead.
Same as before, in lists, {key Alt} and {key RMB}
Copy to Selectedis a bit weak [only matches list index], but I think for these we should just go with dedicated operators in corresponding pulldown menus that handle getting whole lists over to other selected objects (such as the ones present for materials and vertex groups)Same as before, in lists, {key Alt} and {key RMB}
Copy to Selectedis a bit weak [only matches list index], but I think for these we should just go with dedicated operators in corresponding pulldown menus that handle getting whole lists over to other selected assets (such as the ones present for materials and vertex groups)Will check on this.
Generally, I think it does not do harm to make the current underlying system of
copy_to_selected_button/UI_context_copy_to_selected_list/ui_selectcontext_beginas robust as possible and extend it as many things as can be added without too much hassle, so whatever the UI will add on top in the future (or whatever comes out of the "active vs selected" design choice) can take this as a reference (or just build on top of).I welcome everyone to report where this is not working and subscribe me there, I'll happily check every case...
Currently nodes support this (but in a different way -- meaning multi-value editing is working within the same nodetree on multiple selected nodes), see
bbadc3aecdda1038c768It would certainly be doable to go over selected objects though, go through their material array, find node-based materials, and in their nodetree find a matching node (or nodesocket) to copy values.
It might not makes sense in all scenarios, but the default Principled BSDF would be possible for sure.
This just needs some thinking on whether/when we want to act on selected nodes, or on selected objects.
Just saying.
Added subscriber: @Nurb2Kea
Added subscriber: @Kuboa
Added subscriber: @Dangry
Added subscriber: @AndyCuccaro
Hi, is this something that's still being discussed and/or planned?
I'm guessing not after 5 years. So the best way is to hold alt when clicking on the properties text box, enter the value, and then press enter. It'll change all selected objects with the same property to the same value.
If you want each object's property to be changed relatively rather than to the same value, for example if one object's value is 10 and another 20, then you can click the textbox normally enter 5, and press alt when pressing enter. That results in one being 15 and the other 25.
The fundamental problem is that this does not work with all aspects of Blender, and it's not always clear to users when it will work, and when it will not.
@WilliamReynish I've been wondering what happened to this project, too. It's something I miss daily, and it feels like a longstanding ommision from the 2.5 project tackling common annoyances.
I don't believe the developers don't see the use anymore, but it does feel like it's fallen through the gaps of development because of what seem to me to be just a few questions that still need resolving. Is there anything the community can do to help in this regard?
I cannot answer on the status of this really, but in regards to the "poor-mans-workaround" I would like to at least have this as functional as possible.
Note since this task started
1318660b04added support pointers and43eb3fe21aadded support for strings in the "ALT" / "Copy to Selected" workaround.Do you have examples that are still not working (except for doing this in IDTemplates [e.g. Mesh datablock selector] -- this has a separate report already)?
I was holding my breath for this one back in the 2.8 days, but it got postponed indefinitely.
If I recall correctly the issues at that time were:
I was only referring to "ALT" / "Copy to Selected", dont want to respawn a discussion about the original task.
So, for this to make sense, I would suggest reporting everything non-working for "ALT" / "Copy to Selected" as a separate issue, feel free to ping/subscribe me there, i will have a look.
@DuarteRamos We actually did come up with solutions to those things:
By default it would only listen to the selection and ignore the active item.
There is - show the value when they are the same. Show a dash when they differ.
The issue is also that not all selected objects even have the same properties to begin with. The solution to that was to only show panels and properties that are in common.
Interesting, more was solved than I recall. Those sound like totally reasonable solutions in my eyes, too bad it was never implemented.
Certain well known CAD applications that also have a properties window solve this with a dropdown menu at the top that allows picking from a list which types of objects from among the selection to show properties for.
This would probably be non standard for Blender, but another way would be to show properties for items that match the active type.
Another option would be to show all that match selected types organized into respective tabs or panels.
I'd love to see something like the number of selected items like
(7)written in front of a property name or inside the property button indicating how many items would be affected by the value change.All of these solutions sound really reasonable (and also widely implemented, so: the user will be familiar with them!), what's the remaining roadblock, if any?
AFAIK the only blocker is a lack of resources and that the priority of this kind of thing doesn't currently trump any of the main development targets.
What William said. As long as there are no people to do it it won't go further. That's the case with any development. At least in Open Source you can see where things are at the moment.
As an individual who cannot help as a developer there's really not much to do other than
I've been waiting for this feature for ages, myself, and when the detailed design task finally was set up I got really excited but like everybody else I'm waiting on hold here. The proposed solutions all sound very reasonable to me.
Who or what module team would be the best to bring this up with?
@BClark : it is already assigned to the
User Interfacemodule (and I think this is still valid)I made a PR for this if you want to play with it. There are lots of user interaction and feedback issues that would have to be dealt with, but at least you can try it yourself. #111093