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?

About the lag with panels and zooming.

I’ve been searching for an explanation of the lag that some panels have when you zoom out. I couldn’t never replicate it consistently, but probably because I was trying with complicated setups.

The steps are so simple!

Empty desktop, add panel, edit panel, zoom out.

That’s all. I think the issue is with the drawing of the layout lines. The more you zoom out the more laggy it becomes until a specific point, when it returns to normal. That point seems to be when the ‘inners lines’ are not drawn. When they disappear the lag disappears too. Until of course you keep zooming out and the ‘main lines’ increase and the lag returns.

I couldn’t replicate this on a folder, no lines are drawn. And strangely I couldn’t in a desktop too. No matter how much I zoom out and no matter how many lines are drawn (side note: if you zoom out a lot the lines disappear).

I’m in the beta, but I’m almost sure it works in the stable release. Can someone test it?

Bug #1

If you run this script from a shortcut (not a folder) it makes no error, but the item visibility is not changed.

var p=i.getProperties().edit();

p.setBoolean(“s.iconVisibility”,false)

p.setBoolean(“f.titleVisibility”,false)

p.commit();

Bug #2

If you run this script from a shortcut (not a folder) this error is shown, instead of ‘not valid property’ or other: “java.lang.NullPointerException: Attempt to read from field ‘java.lang.Object android.util.Pair.first’ on a null object reference”.

var p=i.getProperties().edit();

p.getBox(“f.box”)

p.commit();