The binding $int_free returns the free internal space available, and it works ok when used directly. However, using animate and a device with (according to android) 10,69GB free space, the number seems to wrap around the wrong way, giving a negative number. It worked fine before on a device with less than 1GB free.

This binding on the label:

animate(“$int_free”)+” “+$int_free

gives the following output:

-1409683456 11475218432

A bit of information (useless I guess)

1409683456 + 11475218432 = 3 * ( 2 ^ 32 )

1)

Add a folder to the desktop, and inside it add another folder and set its id to the same as the main one (aka a ‘folder inside itself’).

1a)

Set the folder to auto close.

When you open the folder from the desktop, clicking the folder inside the opened one closes the folder and reopens it.

However, when opening the folder again, it is not closed and they stack.

1b)

In the hierarchy screen, now you can open as many folders as you want (maybe this is unavoidable, the same with stacked panels) but it is a good way to discover that if the padding is big enough, the text disappear and you can only see a blank item. Maybe force a minimum text width?

2)

Add two folders on the desktop with the same id (both opens the same one).

2a)

Clicking one folder and then the other opens two instances of the folder. Not sure if this behavior is the good one. Should the folder close? Should it close/open? More discussion required.

Comments:

It seems as if the ‘windows’ remember from where they were opened, and they only share the container inside. Maybe this is a bit absurd but what if the window folder properties were attached to the shortcut instead of the container? This will allow to have the same folder but with two backgrounds, different sizes…but I’m sure it will cause a lot of problems too. Just a comment anyway.

Previously the it.getView() returned the custom view created by the create script event, like the scriptdoc says. But now in the beta it returns a lightning view, and I found that it.getView().getChildAt(0).getChildAt(0).getChildAt(0) correctly returns the custom view.

Bug?