Optional snap-to dimensions for screenlets
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Screenlets |
New
|
Wishlist
|
Unassigned |
Bug Description
Many modern operating systems are using these sort of widgets that you can kind of move around on a grid. I'm thinking Android first of all, and what I have seen in screenshots of the new Windows OS.
Screenlets is the obvious choice to match this functionality. It's already there, except for a grid to snap to. I also like the freeform method..so maybe having the option to switch the grid on and off would be nice, or maybe per widget - you could snap the widget to the grid or off. :)
I imagine dropping a widget like dayNight onto the grid and maybe even having the option to rezise it by dragging and dropping a corner.
A recommendation could be made to screenlet developers to initally set their screenlet width to a multiple of 128x128 for maximum compatibility.
Changed in screenlets: | |
importance: | Undecided → Wishlist |
Good idea but it will take a quite time to implement that. I have started implementing long-click start-move and drag-drop corner for resize. That is not a big problem, problem is a grid and its compatibility with those 128x128 grid places. It can be done but every screenlet would need implementation of some kind on_resize event. Without it, we could still force screenlets to snap to the grid but it could resize only linear (128x128, 256x256, 384x384...) and not (128x256, 256x128, 128x384 ...). Without touching screenlets sources, resizing would be just like now - zooming. And idea behind Android widget resizing is to show more features if widget is bigger or less if it's smaller.