(This seems like a bug, but it is a feature suggestion)
The ‘bounding box’ of a container is not recalculated when moving items from script.
If you move an item from script ‘outside’ of the available pages, you won’t be able to scroll to it until the launcher refresh (open another app, then go back to the launcher). This is more noticeable if you have the ‘fit desktop to items’ active.
This means that the ‘computation’ of the available screen is made from time to time, I guess when the container loads, when you exit edit mode… But not when moving items from script.
Will be possible to add a container.refresh() or similar to manually force this calculation? Is it too cheap to do it every time an item moves (I guess not)?
Or
Is it possible with something currently available?
I found that calling {LL.save();container.getProperties().edit().commit(); } works. But it takes almost a second to refresh the container. ( [!] Something to note: if you don’t call LL.save() before the commit() all the container returns to the previous state. I guess this is the reported and known issue of deleted items that appears again and related)
Second suggestion:
Could be possible to set ‘borders’ in the calculation of the bounding box when the ‘fit desktop to items’ is checked? I mean to add an offset so that you can always scroll a little more than the last item.
I’m suggesting this mainly because I have transparent nav bar, and the items scroll under it. But now the last item is always under the bar, so I can’t click it. I need to manually add an item at the bottom to force it to scroll a bit more.
I know I can automate this from an script, adding automatically an invisible item accordingly. But it seems like a ‘bad’ solution in my opinion. A built in feature will be better.
]]>
D5 Creation
< ![CDATA[
Somewhat related to your second suggestion…
Sometimes in the “Items” menu list, the last item listed is behind the (transparent) nav bar. I don’t know if there is way to solve this.
]]>
< ![CDATA[
Computing the bounding box is not too expensive, I think it could be done one each item move or geometry change.
Regarding the second suggestion, is it related to the overlap option ?
The bottom of the menu being under the nav bar is probably due to this same overlap option.
]]>
< ![CDATA[
Yes, it is. But more general.
If you disable the overlap, items are not drawer under the bar, so it only shows the background.
Letting the user specify custom offsets in all four directions will let you for example place a pinned item at the left so that when you scroll the items will never be placed under it.
(The bug chris mention is due to that, yes.)
]]>
< ![CDATA[
What about setting a custom bounding box? I mean, instead of adding margins, would it be useful to directly set the rectangle with arbitrary values? There could be a getComputedBoundingBox function to retrieve the theoretical box, while a setCustomBoundingBox would override it on the script side. A setting in the menu could allow this too in a more user friendly way.
]]>
< ![CDATA[
There is already a getBoundingBox function 😛
And yes, another to set it will be even better to what I want :)
Edit: wait, maybe you refer to another function that will always return the ‘real’ bounding box, whether the current one will return the custom one. Nice
]]>
< ![CDATA[
Yes, a function that returns the real box is needed so that a margin can be added to it for instance (or more generally modified based on the real value)
]]>