-
-
Notifications
You must be signed in to change notification settings - Fork 130
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.
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
DockPanel inside a DockPanel #43
Comments
I think this is tricky because the mimetypes from the inner dockpanel match the accepted drops for the outer dockpanel. Perhaps there is a way to override those mimetypes for one or the other to make the inner and outer dockpanels incompatible with each other. |
Yeah, this is the mimetype it is setting and accepting. If you customized that to be different for the inner and outer dockpanels, things might work: lumino/packages/widgets/src/dockpanel.ts Line 489 in 1beb8b3
lumino/packages/widgets/src/dockpanel.ts Line 963 in 1beb8b3
|
Perhaps that string should be a class parameter that can be changed for these sorts of issues? It probably ought to be at least a variable so it can be referenced instead of typed out exactly three different places. |
Yes that's a good point. It should be possible to try a quick and dirty solution, for example by appending the DockPanel
Or by adding the lumino/packages/widgets/src/dockpanel.ts Lines 969 to 973 in 1beb8b3
And checking for the source here: lumino/packages/widgets/src/dockpanel.ts Line 489 in 1beb8b3
|
As I recall this used to be possible before the dock panel refactor that
laid out everything by calculation and left the children as sibling nodes
in the DOM. The explicit design constraint was that a dock panel should not
reside in another dock panel. The suggestions in this thread may work, but
I would suggest revisiting the user experience of an embedded dock panel,
when we were re-designing this component we came to the conclusion that
it's a use case that might lead to convoluted UX.
…On Thu, 30 Jan 2020 at 10:46 Jeremy Tuloup ***@***.***> wrote:
Yes that's a good point.
It should be possible to try a quick and dirty solution, for example by
appending the DockPanel id to the mime data, which would prevent drops to
a widget with a different id.
Perhaps that string should be a class parameter that can be changed for
these sorts of issues? It probably ought to be at least a variable so it
can be referenced instead of typed out exactly three different places.
Or by adding the source to the Drag object here:
https://github.com/jupyterlab/lumino/blob/1beb8b36878dc0b1c4a75ab627b3938808eef0ca/packages/widgets/src/dockpanel.ts#L969-L973
And checking for the source here:
https://github.com/jupyterlab/lumino/blob/1beb8b36878dc0b1c4a75ab627b3938808eef0ca/packages/widgets/src/dockpanel.ts#L489
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#43?email_source=notifications&email_token=AABG6KJ4MKQ5XXURXMCQTU3RAKV2HA5CNFSM4KKLYELKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKKRJAI#issuecomment-580195457>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABG6KNGP2HHJU5ZSE55YP3RAKV2HANCNFSM4KKLYELA>
.
|
Thanks @afshin for the extra context. Maybe such behavior could still be enabled using an opt-in flag, to let users do something like this if they really want to. I'll experiment with this and report back, at least to get a feeling of what it looks like in terms of UX. |
This functionality might be useful for e.g. variable viewers for the debugger (though I'm not sure that is an actual improvement over just adding them to the main DockPanel) |
Reusing the example from above, and implementing the idea from #43 (comment) and using the |
Given the following layout (adapted from the DockPanel example), where
dock2
is a secondDockPanel
added to the first one with:Is is possible to have control on where the widgets of an inner DockPanel can be docked? For example to disallow dropping them outside of "Dock 2":
The text was updated successfully, but these errors were encountered: