You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Predefine the size of dragable elements in sidebbar of Two Grids Demo #933
I can't figure out how to predefine the size of the items in the sidebar of Two Grids Demo
So as long they're in the sidebar, i'm fine with the items begin a fixed size like 150x150px. But when I drag them into a grid, I want them to be a predefined size. Like 2x2 or 1x1.
At this moment it seems they're always 2x2.
It this possible? Using data-gs-width="1" data-gs-height="1" doesn't seem to work.
Definitely in for this. Haven't had any success getting it to work. Even if I specify the data-gs-width and data-gs-height attributes (as you said) they seem to get ignored and the element always becomes a 2x2.
I found a hacky workaround after reviewing the library's source. The library is trying to be smart when you drag outside widgets into the grid (using acceptWidgets). It determines the width and height of the grid, and then calculates what the width of each column/cell in that grid should be (note this changes on the two grid demo depending on how wide the viewport is). Then it looks at the width (and height) of the widget you are bringing into the grid and determines how many columns/rows it should occupy. Unfortunately, the data attributes are not considered in any of this. Here is the relevant function:
You can see it checks if there is any existing data for the widget, and falls back to the calculations if there isn't. Ideally the code would check for the attributes before resorting to calculations. Assuming we can't change the library, what we can do is add this data it is looking for, specifying the width and height we want. Then you can drag an html element of any dimension into the grid and have it occupy the width/height of your choosing. Eg, add to end of two-grid demo:
@ermcgrat although the sizing for the items works, in some situations the placeholder width/height doesn't correspondent with the width of the placed items. It seems that after 1 drag and drop the data-gs-width and data-gs-height changes back to some default values (1 and 2)
This does work in most cases. Although there are some cases the placeholder doesn't size properly. But I'm not sure what causes that. I was not able to determine when that exactly happens.
Just found out that if you have an item with a `min-width', and you resize it smaller than the min-width, the placeholder is able to resize smaller than the given min-width but the item itself is not.
So redragging the item gets you a item with the right size, but with a smaller placeholder.
This is probably a separate issue
Activity
ermcgrat commentedon Aug 10, 2018
Definitely in for this. Haven't had any success getting it to work. Even if I specify the data-gs-width and data-gs-height attributes (as you said) they seem to get ignored and the element always becomes a 2x2.
ermcgrat commentedon Aug 13, 2018
It's not looking real promising for us Hedva, as this seems to be a pretty common thing with no solution as of yet:
How to change the default width and height for new widgets using acceptWidgets? #922
How to set a predefined height or width for “grid-stack-item” with acceptWidgets #918
How to change the default width and height of grid stack placeholder? #914
ermcgrat commentedon Aug 15, 2018
I found a hacky workaround after reviewing the library's source. The library is trying to be smart when you drag outside widgets into the grid (using acceptWidgets). It determines the width and height of the grid, and then calculates what the width of each column/cell in that grid should be (note this changes on the two grid demo depending on how wide the viewport is). Then it looks at the width (and height) of the widget you are bringing into the grid and determines how many columns/rows it should occupy. Unfortunately, the data attributes are not considered in any of this. Here is the relevant function:
gridstack.js/dist/gridstack.js
Line 898 in 7d9ac26
You can see it checks if there is any existing data for the widget, and falls back to the calculations if there isn't. Ideally the code would check for the attributes before resorting to calculations. Assuming we can't change the library, what we can do is add this data it is looking for, specifying the width and height we want. Then you can drag an html element of any dimension into the grid and have it occupy the width/height of your choosing. Eg, add to end of two-grid demo:
Hedva commentedon Aug 29, 2018
Great solution! Thanks for sharing, really appreciate it!
Hedva commentedon Aug 30, 2018
@ermcgrat although the sizing for the items works, in some situations the placeholder width/height doesn't correspondent with the width of the placed items. It seems that after 1 drag and drop the
data-gs-widthanddata-gs-heightchanges back to some default values (1 and 2)First drag/drop from sidebar:
Second drag/drop from sidebar:
To prevent this; put the @ermcgrat code inside
$('.sidebar').on.('dragstart', function(event, ui){}.Example:
This does work in most cases. Although there are some cases the placeholder doesn't size properly. But I'm not sure what causes that. I was not able to determine when that exactly happens.
Hedva commentedon Aug 30, 2018
Just found out that if you have an item with a `min-width', and you resize it smaller than the min-width, the placeholder is able to resize smaller than the given min-width but the item itself is not.
So redragging the item gets you a item with the right size, but with a smaller placeholder.
This is probably a separate issue
Hedva commentedon Aug 30, 2018
Also found a partial fix for this. It doesn't work in all cases.
Add the following lines in the library's source at
onStartMoving:gridstack.js/dist/gridstack.js
Lines 1215 to 1240 in 7d9ac26
So it looks like this:
As said earlier, this doesn't fix all cases(new drag/drop gets old placeholder sizes), but it does fix it for resizing.
adumesny commentedon Dec 21, 2019
thanks for looking so deeply and referencing other issues - make our job easier!
hopefully I can take a look and fix it in the lib soon...
see #413
adumesny commentedon Dec 23, 2019
real fix in #1107 - sorry it took so long and thank you @ermcgrat