Panel API - Panel Collision Management #4102
Replies: 8 comments
-
Comment from @james-rae, originally here: #3288 (comment) I'm not a UI guy, but I might be worried that in Would making it something like 60% transparent work? I guess that is problematic as the user could still interact with it. Arnold "I'll be back" gif? |
Beta Was this translation helpful? Give feedback.
-
Comment from @ShrutiVellanki, originally here: #3288 (comment) On Underlay Rules:I like the three types of "underlay rules" but I'm just worried something like this could happen:
Panel 4 is trying to open on top of all three of them.
You close Panel 4.
Maybe this scenario is unlikely but it seems like somewhat of a weird possible experience. Possible combined solution: Stubborn Panels + Accommodating Panels.Stubborn PanelsA similar approach to what @james-rae said would work for panels like the side menu and "Link to Share": They "grey out" + "freeze" ALL OTHER panels when open, and make it impossible for anyone to interact with them/open them until they are closed. If panels like these are on top, any other panel trying to open through the API fails until they are closed, period. Accommodating PanelsAn example of this panel would be Note that this use case would only make sense for panels that save their state on close...( |
Beta Was this translation helpful? Give feedback.
-
Lots of great points above, but feels like it needs to be distilled into answering overarching questions before defining the modes we want to define. So questions:
|
Beta Was this translation helpful? Give feedback.
-
Would this cause issues with the @ShrutiVellanki According to the panel docs, the side menu and link to share are not exactly the same types of panels and none of the panels listed in the doc would want to prevent the rest of the map from being interacted with. |
Beta Was this translation helpful? Give feedback.
-
Distilled this from a chat with Alex.. suggestion: -Panel can be opened with three default behaviors: when a panel is protected, other panels cannot open over top of it. to avoid cases where a panel just randomly fails to open, we do either of the following: |
Beta Was this translation helpful? Give feedback.
-
An alternate idea for the pile:
In the image above if Panel 3 opens last it would hide the "Some text" bodies of both Panel 1 & 2. Toggling the body of either Panel 1 or 2 (via a button in the respective header) would close Panel 3 since its header is being partially covered. All panels would behave in the same way. No special rules. Likely half the complexity to implement. We can always hard code an area or two as "no fly zones" for panels if we need a viewer control to be always visible (such as the main bar). |
Beta Was this translation helpful? Give feedback.
-
its an interesting solution and would simplify things for a developer, but is adding a special button to the header going to be intuitive for the user? is there a middle ground that avoids complicated logic but has little learning curve?? |
Beta Was this translation helpful? Give feedback.
-
Based on RAMP meeting on 2019/2/21
|
Beta Was this translation helpful? Give feedback.
-
This is a repost from #3288 (comment) originally written by @milesap
General Outline
The following is a general outline of how the new panel system will manage panel "collisions". A collision is when a panel (lets call it the overlaying panel) attempts to open either partically or fully over one or more other panels (which we'll call the underlay panels).
Goal
To provide a simple mechanism for panels to co-exist on a 2D plane without the need for individual panels to monitor and react to external changes in regards to new panels being created, moved, or opened/closed.
Panel underlay rules
A panel can prescribe to one of three underlay rules during its creation, depending on its needs and which are enforced by the RAMP panel API once the panel has successfully opened. The rule governs what happens to the panel when another panel is trying to open over it.
default
: this panel will be hidden from view - likely with the css propertyvisibility:hidden
. An observable namedhiding
will emit with the overlaying panel instance. This panels visibility will be restored once the overlay panel has closed.close
: this panel will be closed using the panel API methodclose
. It is not restored automatically.persistent
: this panel refuses to hide or close. The call toopen
on the overlaying panel will fail and it will need to locate another spot or fail gracefully.General comments
The
open
method will be altered toopen(): {status: boolean | panels: Panel[]
which now returns a boolean status indicating if the operation was successful and an array of panels that occupied its space.A panel cannot change its underlay rule.
A panel should not change its relative position, or have its computed width/height altered once opened. Doing so triggers an underlay rule check which if failed causes the panel to be closed. Monitoring panels can be done with a
MutationObserver
scanning for changes to thestyles
property and changes to the viewport size.When the viewport size changes the underlay rules are verified in the order the panels were opened.
Beta Was this translation helpful? Give feedback.
All reactions