search

WebCabin / wcDocker

wcDocker (Web Cabin Docker) is a powerful window layout system with a responsive and completely interactive design. Move, remove, create, and duplicate panel windows at any time! Organize how you wish! View the demo here:
http://docker.webcabin.org
146 stars 53 forks source link

Ability to redock panel to original location #89

Closed arpanmukherjee1 closed 8 years ago

arpanmukherjee1 commented 8 years ago

@Lochemage When a collapsed panel is undocked it looses its original position (from where it was collapsed). Is there a way to make it appear at the same location if rest of the panels are unchanged?

Lochemage commented 8 years ago

@arpanmukherjee1

It's possible to implement a feature like this, but I wonder how useful it would be if it only worked when no other changes were made.

A simple implementation could be to use the built in layout save/restore feature. Save layout right before the user docks the panel from it's original location, then you could restore the entire layout whenever you want (eg by adding a panel button on the docked panel or something). This, of course, will also reset any panel resizing done by the user after the dock happened, if that is important.

The alternative would be a bit harder to implement.

arpanmukherjee1 commented 8 years ago

@Lochemage

By no other changes, I meant that the location of the panel must remain same as long as the surrounding panels exist when the panel is redocked, even when the layout is resized. If any of the surrounding panels change(added/closed) the current behavior works fine.

Yes, I thought about implementing the save/restore method but the floating panels are recreated (non-persistent) when the layout is restored.

Accepted that an alternative is non-trivial to implement, still can you suggest an algorithm that can produce the desired result?

Lochemage commented 8 years ago

@arpanmukherjee1

Alright, I have an idea that may get you started. Docker's layout is rather simplistic, any filled in area can either be a panel, or a splitter. A splitter can only split an area into two halves, either horizontally or vertically, and can contain either a panel or another splitter in each side. Whenever the user moves a panel, it will essentially cause it's parent splitter to be destroyed (un-splitting the area), leaving that panel detached. If they move the panel to another docked location, a new splitter is then created to split up the area it was dropped into.

That being said, if you were to stop the first splitter from being destroyed, and instead hide it's presence, it will remain attached where it is as if the area is still being shared. You will then be free to move the panel to a side docking position or as a floater, and at any time you would be able to return back to that previously hidden splitter. Furthermore, it would not matter if the user moves a few more panels around, as the splitter would just auto-move accordingly, the same way it would have moved if it were housing two panels.

Of course, there are a number of inherent issues that come along with this idea: 1: What happens when the panel being moved did not have a parent splitter (meaning it was the only panel existing on the interface)? 2: You will have to take special consideration for splitters that are holding static (non-moving) panels, as they are special and can not be moved. For example, if you have a static title bar panel like in my demo page. 3: It might bring confusion to a user, if they have moved around all their panels, then decided to re-dock their floating window, the splitter that it had reserved may have moved to a not so obvious location. 4: There are a number of places in the code that expect a splitter to have a panel or another splitter in both sides, and may crash if they do not handle this new case (such as save/restore layout, or resizing a panel). You can either account for this logic, or fill the empty splitter half with a hidden view object.

I would take a look at wcDocker._placeholderPanel, a special internal panel type that fills the docker space when no panels exist to do so. Since the way docker works, it requires at least one panel no matter what, this placeholder is inserted when it is necessary and therefore has special logic throughout docker. I do not recommend making more placeholder panels, but perhaps a new hidden panel type that behaves in a similar way.

This won't be an easy task, but if you choose to tackle it, I will try and help out in any way I can. Good luck!

arpanmukherjee1 commented 8 years ago

@Lochemage

You are correct that in some cases the behavior will be non-intuitive. Considering your view, I may not implementing this feature now. But will look out for some way that makes the UX better.

Will try to implement your solution.

Closing this for now. Will re-open when I come up with something.

Thanks.