A maybe hard to code, but extremely powerful new suggestion I think nobody suggest this…maybe I’m wrong.
Right now we have two main modes: free mode, and layout mode…why? They are almost the same!
My suggestion is to blend both to have a unique and powerful mode.
Why?
For the free-mode fans: you like the power of free placement, but I’m sure you ever wanted to place only one or more icons in a ‘layout’ grid.
For the layout fans: you like having the items in order, but I’m sure you ever wanted to place only one or more icons ‘just a bit out’.
How?
Adding a new function to free mode to have a secondary layout (pierre, you can try with this and then, if it works well, remove the layout mode)
This way, items will have a check box; if it’s unchecked it will act like a normal item in free mode. If it’s checked, it will be attached to the layout. (Or the opposite)
Rotation will have a problem, because we need to define the center, I suggest the center of the item.
I don’t know how difficult is to do this on the programmer-side, but if an item has that checkbox checked, and a position of 3,4 you can calculate “layout.width()*3+item.width()/2” , “layout.height ()*4+item.height()/2” to get the position of the center of the icon, where layout.width() are the size of a slot of the layout (screen.width() / columns)
And, if possible, it would be also useful to have a different layout per icon.
I don’t know how android works (I would like to) so sorry if this is completely impossible. I just want to give ideas, sometimes impossible ideas become possible in other ways, or even give new ideas.
]]>
D5 Creation
< ![CDATA[
I would love to see something similar to this. I prefer using the grid mode for keeping any zooperwidgets the exact size I want them, but I also use the free mode for moving stop points slightly off screen which is a bit of a pain switching between them.
]]>
< ![CDATA[
This is not needed if you want both, grid and free mode, the easy way is to place the icons/widgets you want in grid, than switch the mode to free and place rest as you want without touching the grid-placed. No need to reprogram the launcher.
]]>
< ![CDATA[
Maybe creating new option beside grid and free?
😀
Or break these options to smaller “sub-options”
]]>
< ![CDATA[
Yes indeed, this would be great.
In fact this has been requested since a long time but I think it has become (a bit) less useful over time due to some additions in the editor, or maybe people were just tired to request it 😉 The fact is I had less requests for this feature these last months and I didn’t take the time to really study it. This is a good thing that you suggest it again, so that I don’t forget about it…
Basically, this is quite a heavy work, though not impossible.
I will never remove the grid layout mode because too many people expect to start with some sort of 4×4 grid (IMHO). The solution would be rather some sort of menu item “position / detach from grid” (or re-attach to grid), and then the item could be transformed freely. There could be some intermediate mode where the item could be rotated and scaled freely, but would be translated according to the grid cell corner. I don’t know if this last mode would be useful.
Technically items in free mode are managed through a transformation matrix. Rotation is done around the center of the item bounding box. This has nothing to do with the grid and in the code there is two branches: one for grid, one for free. This does not mean that these two branches can’t be merged somehow, but some computations such as desktop limits (bounding box) would be more complex.
Maybe the most difficult thing is to keep the compatibility with existing setup: removing the grid/free option has a few impacts. For instance newly added items need to be added in a mode which may not be the preferred one. If your old mode was free, a new item will be added attached to the grid and you need to detach it manually. This is not a big issue, but this is just an example, and for some it is enough to kill the app (yes, believe me).
What do you mean by “different layout per icon” ?
]]>
< ![CDATA[
Pierre Hébert, with “different layout per icon” I mean the ability to have custom layouts for each icon. For example, you can have some icons that can be placed in a 4×4 layout and other icons in a 5×5 layout. I suggested this because I sometimes have this problem, and the only solution now is to have the layout with the least common multiple. Not very important.
So, this was suggested before…interesting. When this community were created?
]]>
< ![CDATA[
Not a long time ago, something like about two months ago maybe !
]]>
< ![CDATA[
Pierre Hébert: about you comment:
“Maybe the most difficult thing is to keep the compatibility with existing setup: removing the grid/free option has a few impacts. For instance newly added items need to be added in a mode which may not be the preferred one. If your old mode was free, a new item will be added attached to the grid and you need to detach it manually. This is not a big issue, but this is just an example, and for some it is enough to kill the app (yes, believe me).”
Sorry, but I don’t thing so. If the property attached/detached is set in each icon, the default property will be set in the default icon, just like all properties. If you want a free mode, go to settings-actual desktop-items and set detached. All new items will be detached. The same with the opposite.
Also, the layout that is shown while editing will be the free or the grid, depending the property of the selected item (like pinned/un-pinned items). And, if no item is selected, show the one of the default.
The possibility to set default settings, and change them locally is one of the best features of LL.
I know there are a lot of other issues, but you can ask here, I’m sure we will be happy to help :)
]]>
< ![CDATA[
+Pierre Hébert Could you take the code which snaps to center/edge in Free Mode and make it snap to the fixed-mode grid points? It could be a per-item setting with options (maybe in the position tab?) including snap position and snap size, perhaps with x/y constriction as well.
]]>
< ![CDATA[
TrianguloY yes of course you are right !!! For this point I just need to migrate this to a property, that will perfectly work, thanks !
]]>
< ![CDATA[
Kaleb McKinnis that might be possible to do.
This is different from a full grid alignment though : because when the grid size changes (for instance upon rotation), items in free mode aligned this way won’t follow the grid, they will stay on their old position.
]]>