JQUERY Gridster Widgets Overlap Issue

[ankithvicky]

I am using Gridster v0.7.0, Recently I am facing one problem that while dragging the widgets the dragged widget gets overlapped on the widget that exists on that co-ordinates.

Below I have attached the GIF for better understanding.

Gridster Overlapping GIF :

https://i.imgur.com/QB31e2s.gif https://i.postimg.cc/KzT4m9Sh/grid.gif Adding the code for creating Gridster.

gridster = $("#GDashboard ul").gridster({
        namespace: '#GDashboard',
        widget_margins: [10, 10],
        widget_base_dimensions: [270, 126],
        max_cols: 4,
        extra_rows:15,
        avoid_overlapped_widgets: true,
        serialize_params: function ($w, wgd) {
            return {
                id: $w.attr('id'),
                col: wgd.col,
                row: wgd.row,
                size_x: wgd.size_x,
                size_y: wgd.size_y
            };
        }
    }).data('gridster');

[ChristianKarlsson86]

I don't know if it's the same issue, but I have had troubles with overlapping widgets as well. It seems like when a widget has moved automatically (due to another widget moving over it) one step horizontally (and only one step and only horizontally) it becomes "intangible". This only happens when the dragged widget is placed adjacent to the affected widget. Dropping other widgets on top of the affected widget makes them overlap and dragging other widgets over that widgets won't cause it to move anymore, allowing you to "stack" widgets.

[kbroderick]

We've been dealing with what I think is the same issue, but it's not limited to horizontal movement. Causing a widget to move horizontally by dragging another widget over it is one way to recreate the issue, but on the demo at http://dsmorse.github.io/gridster.js/, dragging the two-space horizontal rectangle up and over one square, so that its right half is over the bottom of the four-place square, shows similar behavior.

Has anyone successfully worked around this, perhaps by implementing custom collision code? I'd rather not go that route if possible—that's part of why we use gridster—but implementing collision code seems like it could be less painful, at least in the short run, versus removing gridster entirely.

[joepwijers]

Of course this an amazingly old issue and possibly nobody is using this anymore, and switched to newer implementations in all these newer JS platforms

But I had this problem and found a cause (on version 0.7 or 0.8)

The simplest reproduction steps for me were for a simple regular grid filled with items of size 1x1 cells: STEP1: move the top left widget at (1,1) to the 2nd column gridster will swap the 2 widgets which is fine STEP2: move the widget om the second row below (1,1) into (1,1) gridster will let the dragged widget land on top of the widget that was already in (1,1) So they overlap, which is not what we want.

Cause

As a cause I found that in STEP 1, in on_stop_drag there is code that will clear in the gridmap the cell(s) the dragged item left behind. This seems OK when it left behind an empty spot. But since in STEP 1 another widget was swapped into that spot, it is not OK now. Because then gridster no long knows that this spot is NOT empty And as a result in STEP 2, it will treat it as empty, and place the dragged widget on top of the other one.

Fix for my scenario

For my particular use case it was enough to add an extra condition before marking the spot as empty. The extra condition is to check that the spot that it is about to mark as empty is currently marked as occupied by the $player. Only then it will clean the spot. OLD:

if (grid.col !== this.placeholder_grid_data.col || grid.row !== this.placeholder_grid_data.row) {
    this.update_widget_position(grid, false);

NEW

if (this.$player[0] == this.gridmap[grid.col][grid.row] &&
   (grid.col !== this.placeholder_grid_data.col || grid.row !== this.placeholder_grid_data.row)) {
    this.update_widget_position(grid, false);

As I said it was good enough for my use case. This is because after dragging ends I anyway apply an additional algorithm, and I just needed to avoid the visually weird behavior of the overlap while dragging. When not applying my additional code. I did still see some other odd behaviors after that when I did not apply my additional algorithm. E.g. new dragged items would swap with widgets that were not really their neighboring widget And I do not know whether these are side effects of my "fix", or other issues.

Since my own problem is covered, I leave it at this. Maybe above analysis will help someone to really resolve it