When deleting a component from the designer, it scrolls all the way up on the view instead of not staying where you just were. It also happens when editing text, after editing the text it scrolls all the way up and you have to scroll back down to your original position.
Steps to reproduce the issue
Create a app in the designer that can scroll Edit or delete text or a component See it scroll up now?
Expected Behaviour
When deleting a component or editing text the phone view isn’t supposed to scroll all the way up, instead continuing from the previous position if possible.
Actual Behaviour
Please remove this section in the template, the behaviour is explained in the description of the issue.
Show your Blocks
There are none, it’s not on the device, it’s in the designer view.
That is the way it works because removing a component simply leaves the pointer empty. The list as it appears has a hierarchy that goes through a hash table; that is why you can actually drag an existing component around and move it from one existing arrangement to another one, which may be in a completely different hierarchy.
Each component therefore has an index that refers to where it should be (the parent component), and that value can be changed, while the rest of the component attribute remain the same. The list you have then is a hierarchy that is resolved by following a recursive process that locates all the children of a component, then all the children of each children, and so on.
Now, if you remove one component, what is the system to do? Find the next children of the parent? What if what you removed was the last, should it pick up the previous? Or should it always pick up the parent instead? If the parent has a lot of sub-components, that would also likely imply scrolling.
So, you see, adding a logic to determine which component should get the focus after one is deleted is not a trivial task; that is probably why the simpler solution, to return the focus to the base component at level 1, was the one retained.
If you deleted component on a grand scale and in a routine basis (why?); perhaps your best approach would be to keep components organized in a hierarchy that limits the number of daughter component to a half dozen or so, and to keep those that are not your current work focus collapsed.
No, because the system does not know that this new component is a replacement. It is just ANOTHER component, with no special value or attribute that marks it as such.
All it has to do is consider it below a component or above a component. Then whichever one moves up or down first, goto it. They can even mark the components by number, 1 through however many components you have that are root components.
That requires adding a complet additional hierarchy, going beyond parent/daughter; but siblings. And that is a set of conditions that will have to be kept updated whenever you merely shift the order of components (right now, I presume the order is kept as attributes of the parent, now it would have to be added to each children).
I am not saying it cannot be done; I am not even saying it is not annoying (it is, there was a time where I had to remove several components because I was changing the type of component used; so I did suffer through this a lot), what I am saying is that this is likely a pretty large change to implement.
And it is not a bug as such, not matter how bugging that is.
It’s not our choice if we have a lot of components though. I don’t think it would even need anything additional, just some code to decide what position to go to and that’s it, it wouldn’t be checking where a sibling is since it would only have to go to the top of where the root component starts.
I don’t know… Have you ever looked into the JSON file “Screen1.scm” in one of your app AIA archive?
It is a sequential nested hierarchy of components (that is one of the result of the compilation). Finding a component using the Uuid or component name is evidently something that can be done, as would be finding its delimiters “{” and “}”, but finding its PARENT delimiter, that seems to be a bit more demanding.
It certainly is possible to do this, but as @CBVG said, it’ll take a refactor of how we handle component hierarchies.
I’m not sure if this should take priority as of now, for there are far more pressing bugs we are currently handling — bugs that prevent one from making apps altogether.
I’ll add this to our to-dos, but I can’t guarantee if it’ll be taken up anytime soon
Ok let me raise you a very VERY valid scenario, you’re mouse scroll wheel and the buttons doesn’t work, then what do you do? You can’t make your app, maybe you can’t afford a new $5 mouse for some reason.
And don’t ask, well howd you get to Kodular in the first place then? Well, thanks for asking! You used tab to enter your password to login to your computer and Kodular was already loaded from last night when your mouse broke.
Valid, yes. Large-scale? No.
We have to look into bugs that affect a large chunk of our userbase first. I’m afraid my hands are full to look into this now. But the bug has been added to our internal tracker and will be investigated when others above its priority are addressed.
