[IGN-7179] Perspective: Allow multiple docks for each dock

The docks config is a bit deceptive as there's an Add button, but there's no actual support for showing multiple docks at the same time which you (or at least I) assume this is for.

It would be great if this was supported, and multiple docks can be open at once for a given border.

image

PS. I presume that you can use the dock ids to open one at a time?

3 Likes

This would be nice, say you had an alert dock that you wanted to show above your regular header. However I’d also be happy with the ability to dynamically change the dock height, because then we could at least accomplish something similar to this

2 Likes

You can have multiple docks attached to a given side, but you can only have one open at a time. You would open/close/toggle docks on a given side using the Dock ID. You can also use this to “override” a shared Docked View.

From your screenshot, if you did not want “Header” displayed for a given Page Configuration you would create a second Docked View with the same path, and then specify for the second (local) configuration of the docked view to be onDemand and hide its handle.

I think there’s an “idea” post about having multiple docks at a given time, but implementing that could be a bit of a nightmare because we’d have to track the order they were opened, or maintain a registry which would dictate in which position a docked view would open with regard to the others.

Here’s the closest thing I’ve found, ironically I posted it and I don’t even remember Ability to modify Docked view properties via scripting | Voters | Inductive Automation

I didn’t look at the back-end for this, but assuming this is all stored in json like 99% of perspective, couldn’t this just be a “priority” key or something equivalent that stores if it’s higher or lower in a potential stack of docked views? Worst case scenario they are the same and it’s more or less random, but at that point it’s a configuration issue

That is, assuming the docked view/page config is stored in json, which I did not verify before posting this

1 Like

I think definitely it would be better to maintain a set order which was defined, similarly to how Vision does it at the moment. For my use-case I would like to have the heading always there but have a different subheading for each page. I can get around it by including it in my heading for now though

3 Likes

Which would imply yet another configuration value to determine whether a docked view should collapse when others are expanded.

Hi.
In the case of 2 dock. Is it possible to have an option to reopen the first dock after closing the 2nd via the handle.
Or a solution via a script event. I couldn’t find a “window closed” event in the view scripts. The “System events\onShutdown” script does not start in this case.
Thank you.

Not necessarily. The way I see it, only 2 (maybe 3/4) more properties are needed per docked view, although I don't know all the backend.

  1. Layer
  2. Position (Priority)
  3. Cover/Push (unless it could be covered by the current cover/push property)

I also ran into a case where I would like this functionality. I want a small bar with small icons across the top of all pages for notifications, but I also want an onDemand docked view along the same edge that would cover the permanent dock. That way I can save space by drawing attention to the docked view without having it always visible.

To do so, I would imagine it would be pretty simple to have a position/priority property that stacks views on the same layer, where 0 is the edge of the screen and other views stack towards the center of the screen.
Also, a layer order, where 0 is the "base" layer and higher numbers layer on top. Really only used if the docked view is set to cover content (other views).
Might also need to implement a corner priority for each layer, but not necessarily.

I'm surprised this idea hasn't gained any traction.