ScratchAddons
ScratchAddons copied to clipboard
ScratchAddons
Improvements to "re-orderable custom inputs" addon
My suggestion
Have been using the addon from #7020 myself a bit and I think the improvements that were previously mentioned could indeed improve the user experience alot:
- Inputs added after the selected instead of at the end
- Disable label merging behaviour
I think these could be options that can be enabled.
The label merging is indeed particularly infuriating, and makes it horrible to use when you have labels. The code that handles the merging is technically updateDeclarationProcCode_, but the merging occurs because if in the procCode two strings are next to each other, even separated by a space, they'll be merged as one input. So really what you'd need is a delimeter in the proc code which is made invisible everywhere else, but is used to display the function as separate label parts when updateDisplay's CreateAllInputs_ is called. It could cause problems later on though.
Making the inputs insert after the selected requires replacing addLabelExternal, addBooleanExternal and addStringNumberExternal
(I thought I'd make this issue before anyone else complains about it)
Was thinking a bit about how to prevent them merging and it's close to impossible. The best I could come up with is that we have a "%" symbol which gets slotted between the two labels in the proccode, and then we modify the display function to treat this % as a delimeter, and to render two labels instead if this is seen. Then when you close the editor the % is removed, the display function is set back to the original, and any labels next to each other are merged.
The best I could come up with is that we have a "%" symbol which gets slotted between the two labels in the proccode, and then we modify the display function to treat this % as a delimeter, and to render two labels instead if this is seen. Then when you close the editor the % is removed, the display function is set back to the original, and any labels next to each other are merged.
I would opt for something more user-friendly, IMO.
Drag-and-drop would also be nice but may be incredibly difficult for us to add on. Maybe we could also make a way to swap two inputs, instead of having to transport them to where they should be one step at a time.
The best I could come up with is that we have a "%" symbol which gets slotted between the two labels in the proccode, and then we modify the display function to treat this % as a delimeter, and to render two labels instead if this is seen. Then when you close the editor the % is removed, the display function is set back to the original, and any labels next to each other are merged.
I would opt for something more user-friendly, IMO.
Drag-and-drop would also be nice but may be incredibly difficult for us to add on. Maybe we could also make a way to swap two inputs, instead of having to transport them to where they should be one step at a time.
Well my proposed thing doesn't really affect the user experience. It would just look like the labels aren't merging when next to each other.
The best I could come up with is that we have a "%" symbol which gets slotted between the two labels in the proccode, and then we modify the display function to treat this % as a delimeter, and to render two labels instead if this is seen. Then when you close the editor the % is removed, the display function is set back to the original, and any labels next to each other are merged.
I would opt for something more user-friendly, IMO.
Drag-and-drop would also be nice but may be incredibly difficult for us to add on. Maybe we could also make a way to swap two inputs, instead of having to transport them to where they should be one step at a time.
Well my proposed thing doesn't really affect the user experience. It would just look like the labels aren't merging when next to each other.
Oh wait, so the % symbol is there but just invisible?
Oh wait, so the % symbol is there but just invisible?
Yeh so like, it would be used only within the block's procCode string. But just like how %b and %s is used to render blocks, the % on it's own would be used to delimit spaces, between labels.This would be used ONLY within the procedures editor, as adding the percent normally would cause some major issues. But in this case we use it only so that when we updateDisplay the labels don't get merged. But as soon as we leave the procedures editor we remove the % symbol so everything doesn't break.
I'll try and see if I can come up with a solution.
Then when you close the editor the % is removed, the display function is set back to the original, and any labels next to each other are merged.
This seems like desirable UX to me! Labels should get merged, we just want them separated in the editor while the user is reordering things.
So my current plan is to
- insert %l at the start of each label text before calling
proc.onChangeFn()(this works because scratch doesn't escape %) - modify Blockly.ScratchBlocks.ProcedureUtils.createAllInputs_ so that it correctly splits on %l
- modify it further so that on line 215 it makes an exception for %l.
- Remove the %l from the start of each label text
Another question is should this behaviour to not merge labels in the proceduresEditor be the only behaviour or should it be optional? (meaning I need to keep the current code that updates focus to account for merging)
Personally, I don't see why the user would want to disable this. The labels will be merged automatically once the editor is closed.
My idea worked!
Personally, I don't see why the user would want to disable this. The labels will be merged automatically once the editor is closed.
I agree, I don't see any point making this an option. It's objectively a better user experience. Also your label merges as soon as you add a new input.
I almost have the "insert after selected" feature done. Currently trying to find a way to account for both merging of labels that can take place before you add a new input and after you add a new input. I thought I'd just check if the list lengths had decreased and if so subtract 1, but if the merging takes place after the new input, then you shouldn't subtract 1, so it's hard.
one idea is to just make it so nothing merges at all
Would it be possible for the %l to show up for someone who doesn't have this addon enabled?
Would it be possible for the
%lto show up for someone who doesn't have this addon enabled?
No
Would it be possible for the
%lto show up for someone who doesn't have this addon enabled?
It would be removed after saving the changes to the block, I believe, so it shouldn't.
I have decided to just make it so labels don't merge when adding new inputs or shifting inputs. I think this is a natural behaviour. It also means means you can create all your labels at once then insert inputs between them if you really wanted to.
Should I also make it not merge on delete?
(Also this code is getting very messy)
Should I also make it not merge on delete?
If adding or shifting labels doesn't cause them to merge, I think deleting shouldn't either.
Also, it would be cool to have keyboard shortcuts. Ctrl+← and Ctrl+→ could be used to swap the selected field with the one to the left or the right, just like clicking the arrow buttons but without needing to take your hands off the keyboard.
Also, it would be cool to have keyboard shortcuts. Ctrl+← and Ctrl+→ could be used to swap the selected field with the one to the left or the right, just like clicking the arrow buttons but without needing to take your hands off the keyboard.
That could cause a bit of an issue with Firefox. Ctrl+← goes to the start of a word/string and Ctrl+→ goes to the end. I think it might be a better idea to try a different combo there...
Also, it would be cool to have keyboard shortcuts. Ctrl+← and Ctrl+→ could be used to swap the selected field with the one to the left or the right, just like clicking the arrow buttons but without needing to take your hands off the keyboard.
That could cause a bit of an issue with Firefox. Ctrl+← goes to the start of a word/string and Ctrl+→ goes to the end. I think it might be a better idea to try a different combo there...
It's a common text navigation keyboard shortcut - it does that in basically any app.
I'm not sure what to replace Ctrl+←/→ with, though.
I get why having one of those shortcuts overriden can be frustrating because sometimes I use the Home and End keys when typing into search/filter fields, which sometimes navigates the results instead.