rwoody
commented
11 years ago Big thanks for the introduction. I'm planning on digging through the existing issues and catching myself up on the code base through those. Several of the issues that have been officially unresolved for months have and/or will inevitably surface in my production environment and must be adressed. I can't accept overlapping widgets or NaN row/column widgets saving to a database :wink:
As far as my use cases are concerned:
- I will need static widget functionality too. Gridster can definitely be utilized to generate layouts, as you suggested, for print media which is of great interest to me as well. Mastheads and footers are some examples of things that will be static in my environment (although it could be debated whether to include these things in the grid to begin with). There could be some conflicting design principles between having a grid system that works for both print and screen medias. For example, in print it might make since to have overlapping widgets (e.g. for watermarks), but that's almost never the case with screen media.
- A responsive grid is going to be a must. If Gridster doesn't do it, someone else will. There are probably even use cases for this in print media.
Gridster needs to be more stable before more complexity can be added. Open issues need to be prioritized and tackled in such a way that will enable us to enhance it with the features the community requires. From my initial passes through the code, inline code documentation needs to improve to keep the code more approachable and testing must be implemented (admittedly not my strong suite - but complexity like this entices me to try :smile:).
dustmoo
@rwoody,
Thanks for your help and contributions. The purpose of this issue is to get you up to speed on what I have/haven't done. A few issues on the forefront of my mind, and hopefully to bring you up to speed with things that I had to discover on my own. I will update this more as time allows. Please forgive the wall of text and read at your leisure.
The fork.
I primarily built this fork so that I could use gridster in a backend print production system that I built, that does page layouts by a grid. I needed gridster to be able to swap tiles rather than just push them down. I also had a need for static widgets, so those are primarily the features that I focused on in this fork. Other features requested by gridster users, like resizable widgets and other uses were not not my radar and have not yet been prioritized.
What I discovered through this process was that the original authors did not imagine a scope outside the original library and the script needs more work in the flexibility arena.
The main issue is the gridster does not keep track of widgets in the way you would expect. It only keeps track of the top-left grid location of a widget. After a widget was moved or placed, it would only concern itself with that top-left spot and then determine the width and height and push other widgets down.
The default situation in this script was to push widgets down in almost all circumstances, this made it hard to make the above changes.
Anyway, I pretty much completely rewrote the set_player method to first detect the size of the player, then the size of the widgets in the area you were moving it too. If the widgets where you are going are smaller than or of equal size to the widget you are dragging, it queues and then swaps the widgets to available slots to where you are moving from.
There is basic checking to make sure all the widgets will fit before a swap is initiated. In the case of larger widgets, if you disable moving large widgets down then no swap or movement occurs. If a widget is static, it is also ignored.
I added methods for better detection of whether or not we could move a widget to a specific location before it was moved.
I, however, only integrated these methods with the new swap behavior and much of the script has no knowledge that these exist. Generally, better handling needs to happen before widgets are moved up or down.
For example, static widgets do not work when other widgets can move down, because the script can't tell whether or not there are any static widgets below that should prevent the behavior of moving down. If you use the built-in method for finding the widgets "under" or "below" on the page, the script only transverses down the columns representing the width of your starting widget. If it encounters a widget that is wide enough to jut out into the next column, the method does not expand to take into account what is below that widget etc.
Other than essentially refactoring all the movement behavior, there are other upgrades and fixes that need to be done.
There are cased (many documented in the other gridster) where widgets will overlap. This is because in many places in the script widgets are moved up or down without any validation as to whether they can move up or down.
All movements should really be handled by the same queue so movement can be validated and managed in one place.
Of course, there are the 100+ issues in the original repo that need to be addressed. :-/
Anyway if you have any questions, ask away. I'll try to add items here as I think of them.
Thanks,
Dustin