Hello all you script-maniacs, here’s a demo and description of some issues I am still stumbling upon.
I don’t know wether these are bugs or intended (though unexpected) behaviours — if so, how to do it right?
Problems:
(1) Collapsing panels to 0px height
(2) Changing properties of items inside a panel not persistent
Collapsing to 0px – Intro
I want to collapse a panel to 0px height by script.
This requires
– panel dettached from grid — obviously
– rows set to NUM, not ROWS
– FitDesktopToItems = false
Collapsing to 0px – Issue 1
If FitDesktopToItems is “true” (what’s the preferable setting), instead of shrinking to 0px the panel is sized to a height which is, well, fit to the height of all items included.
Collapsing to 0px – Issue 2
If FitDesktopToItems is “false”, the panel is shrunk… but only if there aren’t any paddings, margins or borders at top or bottom! Otherwise instead of 0px the panel’s height is the sum of all top plus bottom paddings, margins and borders.
My current very ugly workaround is setting to 1px (which works good, with only a few border’s pixels remaining left and right) and changing Visibility to false.
Changing item properties
If I change properties of items inside a panel via script (like transparency, color, bold/italic/normal), it seems to work… but only until properties of the panel are changed. Or better: even edit()/commit() without changing anything is executed. Doing so causes the item’s properties to revert to their previous values; not default (think: inheritance). They seem to be “persisted” however after a while, a restart of LL, … I don’t know…
I tried starting “edit()” of the panel item and/or container before changing the item’s properties and commit() afterwards, but this did not help. IIRC it immediately causes reverting.
Am I doing something wrong or is this a bug?
DEMO Template
Here’s a template with the demo screen and scripts.
https://app.box.com/LL20140617Demo
Functions:
– “Mark items” (_script1): toggles transparency of the items inside the panel
– “Edit panel” (_script2):
– Answering “Change panel properties” with “Cancel” only does edit().commit() for container (this commit reverts the item changes) and item (this does not)
– “OK” allows to change some properties: RowMode, FitDesktopToItems, Dettach, Borders/Margins/Padding through series of confirm-dialogs
– “Toggle panel”: allows to collapse/expand the panel height to 2 rows, 0px or 1px through series of confirm-dialogs.
D5 Creation
< ![CDATA[
First I want to commit: these bugs are there, it was easy to reproduce them.
But why you want a panels size to be 0? Just changing visibility to false should be enough.
]]>
< ![CDATA[
Lukas Morawietz Nice try 😜
But seriously: I’m working on a generic Accordion script. Aaand… when collapsed, the content panels do have a height of 0px. Triggers are shortcuts outside the panel.
Seems for now I have to live with setting the panel to 1px and invisible as workaround.
Thanks for your investigation.
]]>
< ![CDATA[
Pierre Hébert
]]>
< ![CDATA[
Lutz Linke did you have a look at http://www.pierrox.net/android/applications/lightning_launcher/wiki/doku.php?id=templates ?
I made a accordion-template available some weeks ago.
(… ofcourse this bug stays)
]]>
< ![CDATA[
Jappie Toutenhoofd Nope, started working on mine also weeks ago. Wasn’t hard to do. Most time I spent on workarounds to 0px-bug. Even came to a point I stored all padding/margin/border sizes to panel’s tag and setting them to 0px. Will take a look at yours, thanks.
Property-edit/commit really is a pain some times. And sadly very slow. Tried to fade panels in/out in accordion when expanding/collapsing. Made accordion crraaawwwl 😣
]]>
< ![CDATA[
Because a size of 0 has no meaning (either width or height), it is used as a reserved value for “auto”. As Lukas guessed, you really need to toggle visibility instead.
Regarding properties, changing the panel settings has the effect to reload it and its content. Since persisting data cannot be made on each update (for obvious performance reasons), it is done on some checkpoints only. As a consequence if item properties are modified before the panel is modified these changes will be lost. A workaround would be to add some explicit LL.saveConfiguration method.
]]>
< ![CDATA[
Pierre Hébert When do these “checkpoints” occur? It seems like even after a few minutes items’ changed properties are still not persisted and lost. Something like “flush” would be greatly appreciated, preferably on container level, not just globally.
Thanks for the explanation. Maybe I can find a workaround for now.
]]>
< ![CDATA[
This is done when the app (activity) is paused. It can also be done in other cases, for instance when exiting the settings screen.
At this time containers are generally saved at once because there may be linked updates, but only modified ones are processed.
]]>