Not a big fan of jQuery UI myself, but just the dragging capabilities are built on top of jquery.draggable, the rest is jQuery and even DOM agnostic.
We build the lib into two components. There's the jQuery-dependent one that just powers the UI interaction and translates cols and rows into pixels for DOM elements. Then there's the main logic, which is an agnostic class that implements all the grid positioning and collision management logic. This makes it possible to calculate new grid positions on the server-side. Same with running unit tests.
This is possibly because the buttons aren't labeled. Depending on whether you see them as "zoom in/out" buttons or "add/remove columns" buttons, your expectation is going to be different.
You're right, the demo is far from user friendly. Thing is we completed 90+% of the current functionality last year and then kept working on integrating it internally and the rest of our milestone. At this point so much time had passed that the open source prospects almost disappeared, so I decided it was now or never to release it to the public, since we had 4 months to "prepare" it and nothing happened. To see it gather over 1000 stars on Github is mind boggling, I didn't expect 100 honestly. The demo page is what I put together when showing the grid around internally as work in progress.
I don't see why the items should dance around when "zooming out"/adding more rows, if the available space and constraints are the same. Is there a gravity component to it?
Well we're trying to 1. occupy as much empty space as possible and then 2. preserve as much as possible of the horizontal order of items when resizing the grid
Neat, but when building draggable things, I always end up needing to have tabs, each of which is a draggable list like this, that can accept an element from another list.
20 comments
[ 3.1 ms ] story [ 55.4 ms ] threadOr just build jQuery UI with only the draggable component.
We build the lib into two components. There's the jQuery-dependent one that just powers the UI interaction and translates cols and rows into pixels for DOM elements. Then there's the main logic, which is an agnostic class that implements all the grid positioning and collision management logic. This makes it possible to calculate new grid positions on the server-side. Same with running unit tests.
Either way it's just two API calls in the demo page, the buttons aren't part of the lib itself
http://cl.ly/image/1E0A0z2C0x0b -> http://cl.ly/image/102E232Z443j
PS. We have some docs for these methods https://github.com/uberVU/grid#resizegridrows
Take a look at the project README for more info: https://github.com/uberVU/grid/blob/master/README.md