Can't resize or move widgets in "responsive" mode

[importnil]

I don't know if this is a bug or a feature, but inability to resize/move widgets in responsive mode is quite frustrating.

Also, how can I target the element that was repositioned/resized, I could parse items, but need to target only the element which was modified.

[troolee]

Hi,

What do you mean in "responsive mode"? When the grid is collapsed into one column?

Element that was repositioned/resized since what? You can subscribe on change event and receive all changes.

[importnil]

Yes, the same behavior can be seen on the official demo page.

[troolee]

Yes, moving and resizing are disabled in one-column mode by design because x coordinate is lost when grid is collapsed.

Probably I can enable resizing in one-column mode, but I don't know how should dragging work. For instance we have a grid:

[1][2][..3.]
   [4][5][6]

in one-column mode it will be like:

[1]
[2]
[3]
[4]
[5]
[6]

If you move [1] down to be below of [2] where should it go in normal mode? Even resizing can cause unexpectable results when you leave one-column mode.

[importnil]

Yep, I understand.
What do you think about an idea to divide grid and items position and size properties for "responsive" and "desktop" modes?

[troolee]

Hi,

I think this behaviour will be unclear. But I can add an ability to override the default behaviour. Right now I use a function which sorts DOM nodes and I will add it as an option.

// sorry for late response. Crazy holidays time.

[crashnick16]

What about setting some sort of rule such as transposing the 1 column mode to rows so if you have the 1 column like:

1
2
3
4
5
6

It would go to
1 2 3
4 5 6

This will be dependent on the widget size, each row should fill the grid...

If such rules are set then this should work to some extent...

[aliabuthahir]

Hi Troole,

I was pondering over the problem statement you gave on Dec 30, 2014.

On analysis, we can find that the 'x' coordinates are getting translated into 'y' coordinates in the single column mode. So when we drag and drop .If you move [1] down to be below of [2], the 'y' coordinate of [1] should be translated to 'x' coordinate of [1].

Because, gridstack arranges the grid items on 'row basis', when resizing from normal mode to responsive mode, the same rules should work on the inverse side of the layout.

Regards,
Ali

[KrishnaPG]

With support from widget swapping / switching (ref: "#88" ) this should become easy. For example, once in vertical 1-column mode, two widgets can only "swap" their positions (and sizes), and hence when the grid goes back to normal state everything goes back to normal except the swapped widgets which go to their new swapped positions (and resized as per their target positions).

[pySilver]

It actually somehow relates to #174
Thats would be nice to have an event called when breakpoint is reached. Also I'm wondering about height in one column mode. Widgets became too high (whats probably could be solved using custom css)

[misino]

How about not using 2 coordinates, but just one. It would be easier to change number of columns.

[radiolips]

I'm not confident that the swap answer is a good one. I don't think it's intuitive that the x-coordinates of two widgets will be swapped simply because these two were swapped in one column mode. I also don't think that it would be intuitive to drag widgets in single column mode, anyway. However, I could understand how a developer may want to programmatically create a way for another user to swap widgets. We shouldn't get in the way of this, but I don't think that gridstack should attempt to solve this problem.

[radiolips]

Apologies, but I'm moving this to v0.3.0 and would not be surprised if we need to wait until v1 to implement it. I absolutely understand (and share!) the frustration, but we'll definitely need to be careful about how we do it. I think we can come up with something intuitive, but I don't want to rush to get something done just to have it done.

[radiolips]

Note to my future self: We will add an option to allow for moving and resizing widgets in one column mode, but these changes will not persist into multi-columns. We'll maintain separate sets of information for single-column mode.

[JohnArcher]

#713

[JohnArcher]

What I don't get why it is possible to resize in one-column-mode in this example: http://gridstackjs.com/demo/responsive.html

Is it because it is 0.2.7-dev? So this would mean that this feature was (accidently) removed from 0.4.0 (I am just talking about resizing, not resort)!?

[adumesny]

Hi all - so you know I've commited a re-write of setColumn() so we keep track of each layout so going from 12 -> 1 or any other # (which is automatically generated from the larger) and back to 12 will remember the original layout
There is full editing in any of those column modes and I try to carry those changes to the other layouts. in 1 column, if you start re-ordering/resizing everything (as opposed to adding/resizing at the end which does a better job incrementally) it may change the 12 column to look the same at some point. Multiple columns in between size editing does as better job as you expect.

We could probably tweak this more.

I have NOT looked at the oneColumnMode yet (I forgot about it when I was busy with the setColumn() re-write... see #1098

[adumesny]

fixed with #1120 in v0.6.1 - full editing now in oneColumnMode (see https://gridstackjs.com/demo/responsive.html and https://gridstackjs.com/demo/column.html) as it now just uses setColumn(1) code.