Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

virtually rendered panels #841

Open
PerBothner opened this issue Jan 27, 2025 · 2 comments
Open

virtually rendered panels #841

PerBothner opened this issue Jan 27, 2025 · 2 comments

Comments

@PerBothner
Copy link

Is there a recommended and documented way to render a Panel using an element outside the dockview element hierarchy? Specifically using elements that do not get re-parented when components are moved, perhaps using an element (the "content element") that is a direct child of the <body> element. When a component is moved, dockview would call an application-provided callback "hook" or event handler which would update the position, size, and visibility of the content element.

This ability would fix the problem of iframes being reloaded, though it may be overkill for that problem.

Part of this can be done using a ResizeObserver but I think it would be better to have a documented API or at least an example.

I do suggest that if a Panel has renderer set to always then perhaps it should be default be virtual and its parent element be one that never moves. Perhaps a sibling or an immediate child of the dockview element.

A more complicated use-case is when you use an embedded browser (like Electron, Qt WebEngine, or Tauri). In that case if can be useful to embed a toolkit widget or a separate WebView (like an iframe - but top-level) as a panel. Using "virtual" panels and callback functions these nested widgets can be coordinated.

Context: I have been using GoldenLayout for DomTerm, and I contributed the dev branch to GoldenLayout. Currently, nobody (including me) has time to work on GoldenLayout. An actively maintained alternative would be welcome - assuming it has the needed functionality. GoldenLayout has long supported "virtual" layouts.

(I have not tried to use dockview, except for the demo, and it will be a while before I have the time. However, before I dig deeper, I thought I'd ask for clarification on this use-case.)
@mathuo
Copy link
Owner

mathuo commented Jan 27, 2025 •
edited
Loading

Dockview does has an always rendering mode which does something similar to what I think you are describing, it is not the default behaviour though - you need to explicitly tell the dockview library you want an always rendered panel on creation, else the panel is remove from the DOM entirely when not in use (for example, hidden).

https://dockview.dev/docs/core/panels/rendering

When the panel is rendered as always however the content is rendered into a fixed container at the root of the dockview DOM tree. The contents DOM position is never moved and the positioning is all controlled via absolute top / left values relative to the contents group location.

As a quick example here, dv-branch-node is the layout structure and in this example I am rendering two panels as always rendered and you can see they are positioned at the root of the dockview DOM tree rather than directly within the layout structure.

Image

As you mentioned this is exactly the approach you would need to take for something like iframes where re-positioning the element within the DOM causes the iframe to reload; using always rendering mode prevents this being a problem here.

Within the demo if you enable the debug-like mode you are able to switch between the renderers on the fly and see in realtime how this works by inspecting the DOM too.

Image

Hopefully this answers your questions, but let me know otherwise and I can explain in more depth.

@PerBothner
Copy link
Author

Thanks. I wondered if might be the case, but I didn't find a clear answer. This page implies the behavior. Perhaps after "they are never removed from the DOM" you could add "or moved within the DOM". You might also mention either here and/or here that if renderer=='always' then "the content is rendered into a fixed container at the root of the dockview DOM tree" and perhaps the following sentence from your reply.

So a common use-case for "virtual rendering" is handled. What about the more general case, such as the example I mention following "A more complicated use-case"? This shouldn't be difficult to implement. Perhaps add a renderer: 'virtual' option. This would supress creating the dv-render-overlay element. Instead, the application would be responsible for creating and positioning the element (or even a separate window). I.e. instead of dockview updating left etc, it would call an application-provided function with those parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mathuo @PerBothner