What determines whether or not the label of an item gets cut off with the “…” at the end? This seems very buggy.. I’ll attach the bit of script as a comment
]]>
I was having that … thing, but it was in the main settings. I would have something like this.
G…ral
Cur…t des…p
If i went out of the settings then back in, it might be OK or it would be the same. It’s been fine since the 10.6.4 update, but it was … really annoying.
Could you confirm that the background displayed on your screenshot is the “content” area, without border nor margin ? The text should fill the same area than this content area. I am wondering also whether text alignment changes something in this unwanted text truncation ?
Another thing maybe: could it be that the length of the truncated text is the same as the previous text ? Maybe there is a bug where the text wouldn’t be correctly “resized” after a value change, although that seems unlikely (at first sight).
Thanks, I can reproduce the issue. In my case Calculator is ok, but “Lightning Launcher” is not. And sometimes the bug propagates to other screens after a while, weird.
Amazing setup by the way. A whole app inside the app, that’s an incredible work.
Well, I spent too many hours to understand and fix the problem, and now that I finally found the issue (which was a tricky one believe me), I discovered that fixing the bug would break a few existing scripts 🙁
Fortunately I have a workaround but it may induce a small performance penalty. I will probably go for a round of beta testing for this fix.
On Android views positions and sizes are computed in two steps. First measure views (that is: how big a view would like to be), then, based on these sizes and the container rules, set their exact location and size.
Inside the Android frameworks there are a couple of flags to manage the process and execute measurement and layout steps. Both steps are tightly linked and there are several ways to initiate a layout of the view hierarchy when something changes. In the end, if the measurement is done, the layout need to be done too otherwise bad things may happen.
In Lightning, changing the text value requires a layout, for instance because the text can grow. But at some point the layout request is not processed anymore (the bug) and as a consequence the text view size is not updated to take into account the new value (and you see … because the value does not fit in the box).
In some situation a position changed event is issued between the measurement step and the layout step. Through this event, a script is executed to change the label, which itself requests a layout. This has the border effect to alter some of the Android flags mentioned above in an unwanted way. (Sometimes only because this stuff is mostly asynchronous). The consequence is that layout is sometimes not done, but Android “thinks” it dit it already, and for this reason skip it. The text view keeps its old size, which might be too small for the new label.
Well, I am not sure this explanation is very clear 🙁
D5 Creation
< ![CDATA[
var cards=[
[“c1″,””, 0,0×25,0x9b,0x24],
[“c4″,”Games”, 255,0×25,0x9b,0x24],
[“c2″,”Music”, 255,0xfb,0x8c,0x00],
[“c3″,”Calculator”,255,0×00,0xbc,0xd4],
[“c5″,”Art”, 255, 0, 0, 0]
//,[“c6”,12,34,56,78]
];
if(x>=0){
$(0x8d0009).setLabel(cards[Math.round(x/w)][1]);
}
]]>
< ![CDATA[
I set the background so you can see how wide it is.. I’ll try giving it more lines
]]>
< ![CDATA[
Margin 4 on all sides so you can see the background.. Padding 0
]]>
< ![CDATA[
The weirdest thing is that it’s not always cut off.. It doesn’t happen every time and its not always the same amount of letters that are cut off
]]>
< ![CDATA[
Try typical troubleshooting… Restart, rebuild,…
Does it happen also for other texts, items, devices?
]]>
< ![CDATA[
Restarted SEVERAL times.. I’ve tried deleting the item and adding it again.. Haven’t tried copying to a new device yet but I will later today
]]>
< ![CDATA[
I was having that … thing, but it was in the main settings. I would have something like this.
G…ral
Cur…t des…p
If i went out of the settings then back in, it might be OK or it would be the same. It’s been fine since the 10.6.4 update, but it was … really annoying.
]]>
< ![CDATA[
That sounds really strange.. I’m on 10.6.4 though
]]>
< ![CDATA[
Ren Shore Just out of interest, are you using a Galaxy S4 ? I’ve got the same on S2 and i don’t get the …
]]>
< ![CDATA[
Could you confirm that the background displayed on your screenshot is the “content” area, without border nor margin ? The text should fill the same area than this content area. I am wondering also whether text alignment changes something in this unwanted text truncation ?
Another thing maybe: could it be that the length of the truncated text is the same as the previous text ? Maybe there is a bug where the text wouldn’t be correctly “resized” after a value change, although that seems unlikely (at first sight).
]]>
< ![CDATA[
Yes, the white background is the item that I’m changing the label..
Yes it still truncates if its center aligned.
I do think it’s related to the width of the previous text..
If you want I can send you a backup?
]]>
< ![CDATA[
Yes please, a backup can help a lot.
]]>
< ![CDATA[
Pierre Hébert I sent you that backup.. Let me know if you find anything
]]>
< ![CDATA[
Thanks, I can reproduce the issue. In my case Calculator is ok, but “Lightning Launcher” is not. And sometimes the bug propagates to other screens after a while, weird.
Amazing setup by the way. A whole app inside the app, that’s an incredible work.
]]>
< ![CDATA[
Yeah, it will be fine for a few swipes back and forth but eventually it will only print one letter..
Also, thanks! I really appreciate that!
]]>
< ![CDATA[
Well, I spent too many hours to understand and fix the problem, and now that I finally found the issue (which was a tricky one believe me), I discovered that fixing the bug would break a few existing scripts 🙁
Fortunately I have a workaround but it may induce a small performance penalty. I will probably go for a round of beta testing for this fix.
]]>
< ![CDATA[
What exactly was causing the issue? (If its not too difficult to explain)
]]>
< ![CDATA[
It’s hardcore. I will sum up.
On Android views positions and sizes are computed in two steps. First measure views (that is: how big a view would like to be), then, based on these sizes and the container rules, set their exact location and size.
Inside the Android frameworks there are a couple of flags to manage the process and execute measurement and layout steps. Both steps are tightly linked and there are several ways to initiate a layout of the view hierarchy when something changes. In the end, if the measurement is done, the layout need to be done too otherwise bad things may happen.
In Lightning, changing the text value requires a layout, for instance because the text can grow. But at some point the layout request is not processed anymore (the bug) and as a consequence the text view size is not updated to take into account the new value (and you see … because the value does not fit in the box).
In some situation a position changed event is issued between the measurement step and the layout step. Through this event, a script is executed to change the label, which itself requests a layout. This has the border effect to alter some of the Android flags mentioned above in an unwanted way. (Sometimes only because this stuff is mostly asynchronous). The consequence is that layout is sometimes not done, but Android “thinks” it dit it already, and for this reason skip it. The text view keeps its old size, which might be too small for the new label.
Well, I am not sure this explanation is very clear 🙁
]]>
< ![CDATA[
I’d say the explanation was quite clear. I’m looking forward to new betas
]]>