Add the possibility to edit keys from dictionaries

[ajreckof]

Supersedes #90258

This started as a salvage of this previous PR as I was reminded of it but in the end I went way farther and improve quite a bit how it looks.
I've made it so that when editing the key the editor property is reversed which means label is on the right, main editor is on the left and bottom editor is on top.

As in some cases having some bottom editor on top made it somewhat unreadable I added a border through th esame system of border as for object,array and dict.

I would really like to have feedback from a usability standpoint if it makes sense, if anyone would have ideas to improve or find anything that doesn't work well with my solution.

For now this is marked as draft as I haven't made the change to the classic theme and will wait for usability feedback before applying the changes.

Here are a few screenshots of how it looks like in modern theme :

[AdriaandeJongh]

I missed all the previous versions and I'm coming in fresh, and I totally don't get why we don't just make the keys editable like values.

My main issues with this design are having an edit icon behind the value, because it doesn't imply you can click it to edit the key. Also, after choosing the 'edit key' option, it's very strange you have to toggle back to editing value. It's a sort of opaque state and makes the entire list of properties look strange.

And so I circle back to: why not just make both the key and the value editable like they're two values side by side?

[ajreckof]

Okay I'll try to explain to the best of what I remember of when this was tested and what I learned from making it and tweaking this part of the editor.
There is I think two part to the question:

1. Why don't we make it possible to edit keys all the time
2. Why do we make the value not editable when the key is being edited

1 :

• You don't edit key very often, hence it doesn't bring that much for it to be always shown
• It would make it easier to reach strange cases of key duplication for example this kind of key change{A:1,B:2}->{B:1,B:2}->{B:1,A:2} would be a huge pain to deal with.
• it would need for both editors to be shown at the same time leading to the second part of the question

2 :

• having both at the same time create something even less readable
• you need a button each for changing type
• you need more horizontal space which we try to not abuse as some people have small screens
• you lose any capacity to copy paste if you edit both at the same time

here is an early try to have both editable at the same time all the time by a plugin creator :

All in all I'm clearly against making key always editable but Could be convinced for editing key to make both editable at the same time if someone came up with a good way to show both at the same time that would be readable without needing double the horizontal space.

[ajreckof]

My main issues with this design are having an edit icon behind the value, because it doesn't imply you can click it to edit the key.

I've just discovered that we have added the inspector context menu to the list of available context menu slot, would placing the edit key there be better. I feel like it would be less discoverable then a button or inside the change type but make more sense. I could also add a copy/paste key when editing value and copy/paste value when editing key but addition of copy/past could wait for another PR.

[AdriaandeJongh]

Sorry, I haven't had much time to dive deeper into this, but perhaps we should differentiate the editor between typed and untyped dictionaries. In a typed dictionary without the type dropdown, it may very well be totally fine to show the two input fields side by side? And in untyped, maybe we simply show the key and value in two rows so each input can take up the whole width, and we 'fix' differentiating the items graphically?

[Synzorasize]

Would you like to rebase this? I want to test it out to see if it fixes #120486 satisfactorily. If so, you should edit the description to say it does.

[ajreckof]

Would you like to rebase this? I want to test it out to see if it fixes #120486 satisfactorily. If so, you should edit the description to say it does.

I've rebased it. Feel free to test it. If you feel it is not satisfactory feel free to suggest changes to help fix the issue.

[Synzorasize]

The fix works for untyped dictionaries, but I found a strange bug with typed:

2026-07-03.15-46-08.mov

Also, that paper clip next to the BoxShape3D shouldn't be there. And it's strange that the Color is somehow being assigned to the key even though it's still the value, and the BoxShape3D is uneditable. Not sure if it worked before for dictionaries which have resources as key types, but I read in your previous proposals that you didn't implement it fully for typed dictionaries since it wasn't merged at the time of the first proposal.

Anyway, this bug should be ironed out before it can be retested. (Also that is the longest branch name I've ever seen lol)

[ajreckof]

Yeah sorry I rebased a bit too quick I think it might have broke something. I will try to iron this bug out so that you can test it again.