Change the home page of a desktop (not the home desktop)
From a previous post, and improving my script with Lukas Morawietz vertical idea.
This is a script that move all the items in a container so the home page change.
Instructions:
– Copy paste this script as a new one, and check ‘appear in lightning menu’
– long click the background of the container you want to change, scripts, run this script.
– input the position of the new home desktop, this can be a bit confusing, I hope the pop-up helps you. You can also scroll to the desired home desktop, it will be detected and shown as default in the inputs.
If the number of cells don’t fit the screen (for example if the cells have a fixed size) you will be warned to exit.
Horizontal pinned items are not moved horizontally. The same with verticals and both.
I didn’t have so much time to test, if you can and you discover a bug please comment here. Thanks.
——————————————
var cont = LL.getEvent().getContainer();
var items=cont.getItems();
var distX=cont.getWidth();
var distY=cont.getHeight();
var cellsFloatX=distX/cont.getCellWidth();
var cellsFloatY=distY/cont.getCellHeight();
var cellsX=Math.round(cellsFloatX);
var cellsY=Math.round(cellsFloatY);
if(Math.abs(cellsFloatX-cellsX)>0.00001)if(!confirm(“Warning, the cells don’t fill the screen as an exact horizontal number.\nDo you want to continue?”))return;
if(Math.abs(cellsFloatY-cellsY)>0.00001)if(!confirm(“Warning, the cells don’t fill the screen as an exact vertical number.\nDo you want to continue?”))return;
var moveX = parseInt(prompt(“Which page do you want to be the home one? (horizontal)(left ones are negative)”,Math.round(cont.getPositionX()/distX))) || 0;
var moveY = parseInt(prompt(“Which page do you want to be the home one? (vertical)(top ones are negative)”,Math.round(cont.getPositionY()/distY))) || 0;
if(moveX==0&&moveY==0)return;
for(var i=items.getLength() – 1;i>=0; — i){
var item=items.getAt(i);
var prop=item.getProperties()
var xx=1;
var yy=1;
var pinmode = prop.getString(“i.pinMode”);
if(pinmode==”X”)xx=0;
else if(pinmode==”Y”)yy=0;
else if(pinmode==”XY”)xx=yy=0;
if(prop.getBoolean(“i.onGrid”)){
var cell=item.getCell();
item.setCell(cell.getLeft() – cellsX * moveX * xx,cell.getTop() – cellsY * moveY * yy,cell.getRight() – cellsX * moveX * xx ,cell.getBottom() – cellsY * moveY * yy);
}else{
item.setPosition(item.getPositionX() – distX * moveX * xx,item.getPositionY() – distY * moveY * yy);
}
}
cont.setPosition(cont.getPositionX() – moveX * distX,cont.getPositionY() – moveY * distY,cont.getPositionScale(),false);
]]>
D5 Creation
< ![CDATA[
Good job.
But why the hell are you moving through the item Array from topindex to bottom? I know it doesn’t matter, because the items are not sorted by anything useful, but normally you start an iteration at the bottom…
]]>
< ![CDATA[
Lukas Morawietz hehe, good question but in fact I almost always do that. And what about ++i instead of i++ ?
The reason is just efficiency. I learned this trick and I just do it.
When a list can be passed from left to right and viceversa there are two ways of doing it.
for(var i=0;i
for(var i=list.length-1;i>=0;i–)
In the first the program need to calculate the length every iteration (maybe useful if it change, but not in general) so it can be really slow if there are a lot. Yes, you can save the length in a var and use it, but you will need a new var.
The second is exactly the same. But it is far more efficient. Ok, maybe here in LL scripts doesn’t matter, but this trick works in all programming languages, and can help you with really long fors.
Oh, and the ++i vs i++ is also the same, the first one is slightly more efficient. You can search in Google why.
]]>
< ![CDATA[
Oh I noticed that ++i some time ago and accepted it as your style…
]]>
< ![CDATA[
Great tipp for “for”, thanks.
Regarding ++i and i++… If I remember correctly it makes a difference when assigning. j=i++ results in j=i, then i is incremented, whereas j=++i first increments before it’s assigned. Or vice versa.
]]>
< ![CDATA[
If the compiler is bad, i++ will generate a copy of i, then increment i and then throw the copy away. A good compiler notices, that the copy isn’t needed and doesn’t create one.
I don’t know which case is in here…
]]>
< ![CDATA[
Lutz Linke exactly. That’s the difference so internally i++ needs to store the value in a different var, then add 1 to i, and then return the saved one. ++i just add 1 and then return the value.
If it is not assigned…I don’t know if there is a difference, but I’m just used to write it :P
]]>
< ![CDATA[
http://jsperf.com/i-vs-i/2
]]>
< ![CDATA[
Perhaps we should ask Pierre Hébert, the master of efficiency 😉
]]>
< ![CDATA[
TrianguloY We’re getting way OT, but intersting, With Chrome BTW there’s only minor difference between i++ and ++i and i+=1:
Testing in Chrome 34.0.1847.116
100000 iterations of ++i: 6,418 Ops/sec, ±0.66%, fastest
100000 iterations of i++: 6,442 Ops/sec, ±0.43%, fastest
100000 iterations of i+=1: 6,420 Ops/sec, ±0.36%, 0.27% slower
]]>
< ![CDATA[
My two cents: don’t forget that optimization starts with heavy operations. Countdown loops are important when writing machine code, or possibly a tight C loop because they can to spare a register instead of swapping data to/from external RAM, but beyond that it won’t make a difference because small operations like incrementation will be far below heavy instructions such as a single byte memory allocation. Efficient software is sometimes like saving fuel for your car: in order to save energy, the best is not to drive gently but to leave the car parked. Same with code, the best is to avoid making heavy calls instead of improving these calls. When possible of course.
In the case of LL there are so many layers between the CPU and JavaScript that this is not really important to bother about the code structure itself, and that’s the great thing. JavaScript is interpreted in Dalvik, which is itself a virtual machine and some code areas may be translated to native code. The weight of all this stuff is crazy, I am still amazed to see how fast it runs on our pocket super computers.
Chrome is a different story as its V8 JS engine is not interpreted at all (translated into machine code) but still memory remains the biggest thing to keep an eye on it.
]]>