Open evonox opened 2 months ago
1.) I'd love if you could remove the additional dependencies. We don't use lodash, and it only used for depbounce, throttle and deep, I'd love if it could be removed.
For velocity-animate, I don't know, if it is really needed, but seems not to be a good idea to use a lib wich has no updates since 4 years.
2.) red flicker when I undock: https://app.screencastify.com/v3/watch/w3PNa58cM0HlIxo6oVH0
3.) One major issue: What really will not work for our system, is that you remove elements from dom and add them to other nodes. I changed dock-spawn-ts completely so that the container wich has the user content is never removed or moved to another dom node. Cause if you have really huge pages, this is verry slow. I alwas position them absolutely and only move the dock nodes around
4.) The library should be published as an ESM module. Also the type in the package.json should be set to "module". We have a no build setup, so we include very lib directly as ESM via an importmap, and every javascript library today should be usable in this way
5.) why jquery in docker-ts.js ??
For me it really looks nice, and I'd love to use it, but I can only when the dome nodes will stay in DOM
Dear @jogibear9988 , thanks for your comments and suggestions. I will address your requirements as follows:
1.) With brotly it will get much smaller
I think, the next week I could have prepared the beta version that might be a candidate for production-ready version of the library. There is however plenty of things to fix.
Will you also support undock to new window? It would be nice if this could work, also with support of docking back...
Maybe you've seen the support in visual studio code?
@jogibear9988 Do you mean undock to a new browser window? I have it as one of the future features to implement. I want to support also collapsers like wcCabinDocker has and the support for perspectives like in Eclipse IDE. But first I want to publish the docking library quickly to NPM registry to start the public testing completely. By publishing the first version my work on this library is starting, not ending. By the way, we need to create the new library name. I asked in one FB Czech frontend group for opinions and there was critisism as DockerTS is not a good library name because it is similar to Docker technology which might be a trademark. Do you have any idea how to call it? Maybe I do not mind even if it might have the same name DockSpawnTS.
There are different ways to do it. If you look how I've done it in dock-spawn-ts or how vscode does it. I move the component to the new window. This is very fast. If you look how it works in golden-layout, very slow. For me it is essential that also web-components with attached stylesheets work, for this I build a hack (if you look at my code (https://github.com/node-projects/dock-spawn-ts/blob/master/src/BrowserDialogHelper.ts). And I've not yet implemented docking back to the origin window.
e could release it as a new version of dock-spawn-ts, I like it, it feels already much more professional. I only did small changes to dockspawn, never did a big rewrite (only the change to keep the nodes in dom).
I've a few more questions:
And you asked about the icons, they are not mine, I used the from the initial dock-spawn project. But there are also some in https://fonts.google.com/icons?icon.query=dock
I also had a webcomponent wraper for dockspawn, may something like this should also be added, maybe as an extra npm, but in dockspawn it added not much of size, see: https://github.com/node-projects/dock-spawn-ts/blob/master/src/webcomponent/DockSpawnTsWebcomponent.ts
and most of the code are only api duplications, wich for sure could be done nicer
the main idea was, you could define your docking ui, without any javascript.
I used it the webcomponent for example here: https://node-projects.github.io/web-component-designer-demo/index.html
I mean, I'd like a webcomponent version, so the user of the Component does not need to write any line of javascript to use the component. At last it is only a small wrapper for the normal API, but declartively usable. It has nothing to do with the other frameworks, like vue, react,... webcomponents are browser standard, so they work always, if you use a framework or not. But it can be included later. But don't compare it to angualr, react and vue, cause these are librarys and webcomponent are browser standard
@jogibear9988 Could you please give a proposal of the definition your web components you would like to have? I mean the properties, events, etc. Do you use Lit Framework?
No, i used no framework. Will do the proposal
Dear @jogibear9988 The second project I have hidden in GitHub private repo is my first attempt to create a pure WebComponent UI library. I use the Lit Framework which is provided by Google. https://lit.dev/docs/getting-started/ As for the WebComponent it saves quite a lot of work. I just send you a link if you want to give it a try. I have noticed somewhere you create a visual editor and you write you have a base widgets library in Web Components. This is I think our mutual interest and I would love to discuss with you creating a pure Web Component widgets UI library. What do you think?
Dear @jogibear9988 I have a rough implementation of undocking into a popup window and when the popup window is closed, the PanelContainer docks back to its previous position in the main browser window. Hopefully, I will be able to publish another preview with this behavior to test.
Dear @jogibear9988 , I need a help from you or anyone other. Now we have a rough implementation of docking to popup windows and today I have added the support of undocking to collapsers moving panels to the left, right and bottom sides. I need now to design an automatic algorithm to dock panel back from these two states. It must be intuitive for the user, that the undocked panel docks back to its previous position even if under the conditions that the docking layout had changed in the meantime. Do you have any idea how to address this issue?
I've no good idea how to dock it back, cause as you said, the docking layout could have changed. Maybe we allow only to "dock" back as a Dialog? And also, should we automaticaly dock back when the user closes? For sure, there could be a api to do so, but should it be the standard?
And for webcomponent (means content not the docking library as a webcomponent) support (for those ones wich use adoptedStyleSheets), you also need the parts backupCss and clone of the adopted of my code: https://github.com/node-projects/dock-spawn-ts/blob/606e2eb05f885df5d9faad5aded78f474b08b4c5/src/BrowserDialogHelper.ts#L50 Or the controls will have no styles (cause stylesheets are not usable between different browser windows).
And also if you want to support to dock back, the stylesheets need to be cloned again, or switched back to the old ones
if I play arround, I also sometime get this error: https://app.screencastify.com/v3/watch/E3NVxuBi8e3sz2EWwJL2 the drag position is not on the mouse pointer
if I play arround, I also sometime get this error: https://app.screencastify.com/v3/watch/E3NVxuBi8e3sz2EWwJL2 the drag position is not on the mouse pointer
Thank you very much for reporting. It is fixed now.
And for webcomponent (means content not the docking library as a webcomponent) support (for those ones wich use adoptedStyleSheets), you also need the parts backupCss and clone of the adopted of my code:
Or the controls will have no styles (cause stylesheets are not usable between different browser windows). And also if you want to support to dock back, the stylesheets need to be cloned again, or switched back to the old ones
I have written a task to complete adopting CSS stylesheets with the dock / undock operations.
I've no good idea how to dock it back, cause as you said, the docking layout could have changed. Maybe we allow only to "dock" back as a Dialog? And also, should we automaticaly dock back when the user closes? For sure, there could be a api to do so, but should it be the standard?
I have an idea, how to make it pseudo-intuitive, I will come with solution and we will see and discuss it.
I have released a promo / propagation preview version of the docking library at https://docker.robotkarel.cz/ Now the docking library has zero-dependencies which cut down its size decently. However it has still plenty of bugs to be fixed. Hopefully you like the promo version.
I really like it. I'll look implement it into my designer, so I could see if my scenarios still work.
I also think, the name "docker" is not really good (Cause of the same named container system)
suggestions from chatgpt: DockJS SnapDock.js FlexDock.js Dockify DockWizard Panelli.js DockMate.js DockMasterJS DockFlow.js Dockster.js
I think we should keep the current dock-spawn-ts, and give yours a new name. I'll then switch mine to "maintenance mode", and link to yours as a successor.
For example, what I also thought to do (but never did) was to implement some sort of Window Stack for popups, means if you open a popup from a popup, I never can be behind this one. But I never did... But what I have if you open a Dialog from another window, it could grayout the parent:
It's here: http://129.159.205.3:8082/webui/index.html
the header should be scrollable via mousewheel not only via buttons
https://dockview.dev/demo/?theme=dockview-theme-abyss has nice themes, and i like the feature to drag windows into the tabbar directly
Dear @jogibear9988, thanks very much for your ideas and review. I am now thinking. Should we support undocking to the popup window from other state than a "docked state"? Maybe it makes a sense to me from a floating state possibly, but not minimized, maximized states.
From Floating I think it should be possible, the others I don't think so
I need advice concerning the generated events by the docking library. It is not quite clear to me the meaning of some original DockSpawn events. I also introduce new events as well, because we have many new dockpanel states. The second difference is that my new docking library is generating global and local events. Global events are accessible using the DockManager API and local events for each panel if the change occurred within it. Every panel has its own local interface.
Event | Meaning | Global | Local |
---|---|---|---|
onSuspendLayout | ??? | No | No |
onResumeLayout | ??? | No | No |
onDock | Panel is docked | Yes | Yes |
onUndock | Panel is undocked | Yes | Yes |
onTabReorder | Does it make sense? | No | No |
onTabChange | Does it make sense? | No | No |
onClosePanel | Panel is closed | Yes | No. Local Panel API has onClose handler |
onCreateDialog | Does it make sense? | No | No |
onShowDialog | Does it make sense? | No | No |
onHideDialog | Does it make sense? | No | No |
onChangeDialogPosition | Does it make sense? | No | No |
onContainerResized | Does it make sense? | No | No |
onActivePanelChange | Panel change ocurred | Yes | No |
onActiveDocumentChange | Document change occurred | Yes | No |
onActivated | Panel is activated | No | Yes |
onDeactivated | Panel is deactivated | No | Yes |
onLayoutChanged | Any change to layout | Yes | No |
onPinned | Docked from collapser | Yes | Yes |
onUnpinned | Undocked to collapser | Yes | Yes |
onUndockToPopup | Undocked to Popup Window | Yes | Yes |
onDockFromPopup | Docked to Popup Window | Yes | Yes |
onMinimized | Panel was minimized | Yes | Yes |
onRestored | Panel was restored | Yes | Yes |
onMaximized | Panel as maximized | Yes | Yes |
onCollapsed | Panel was collapsed in floating state | Yes | Yes |
onExpanded | Panel was expanded in floating state | Yes | Yes |
May I ask you to review the generated events proposal and give me comments what you think?
For me this looks good.
I think onSuspendLayout and onResumeLayout are used when serializing the layout to json and restoring it from there.
As you may see in the IDE sample of dock-spawn-ts the layout is restored to the state how you configured it last time
@evonox @jogibear9988 Hey, thank you for your work, but could you please share why are you working on new solutions while golden-layout / dockview exist?
I guess I need to clarify why I'm asking this question. I'm looking for a docking layout lib for new desktop app we want to build and so far I've came to a conclusion that there are
Looking at all of this, it's crazy hard to make a sane decision about investing into one of them. It seems big companies like Microsoft have developed their own solutions within the product itself (e.g. vscode, even in codesandbox, is pretty good). I'd like to do the same but budgets are not giant for most companies.
So what are the motives behind evonox/docker? Do you have some requirements that are not possible to meet by contributing to other libs?
I use DockSpawn since years. When the initial author dropped support, I converted to typescript.
For me these 2 main features are relevant: Dialogs, keep content in dom
golden-layout did not support dialogs and does not to keep the content in DOM when moving a element. dockview as I see also does not do both.
And another feature: open in new browser window, is supported by golden-layout, but not via adoptNode, so the whol javascript needs to be loaded again.
If the new one of @evonox will support this I will switch, because it's smaller, cleaner, animates, ....
dock spawn als for example has touch support, don't know if the other two have.
And if you look here:
https://node-projects.github.io/web-component-designer-demo/index.html
you could use dock-spawn-ts complete declaratively (if you use the webcomponent)
For me these 2 main features are relevant: Dialogs, keep content in dom dockview as I see also does not do both.
@jogibear9988 Maybe I do not understand what "Dialogs" means exactly, but doesn't dockview demo cover resizable floating groups and opening them in new window? https://dockview.dev/demo
It's just not triggered by dnd like on https://node-projects.github.io/web-component-designer-demo/index.html, but there's a button / ad_group icon that triggers similar behaviour? UPD: actually, in dockview demo, un-docking to floating window with dnd works if you hold Shift mod while moving the panel out.
@timadevelop 1) I tried now DockView and for instance when the TabStripBar is smaller than available space for Tabs, "ugly" browser scrollbar appears. There are a lot of subtle, at fist glance invisible things, I do not want to have in my library. 2) By floating windows @jogibear9988 meant that I can drag the panel and it will be floating inside the browser, not a new browser window. 3) I included animations, because it gives users better UX experience of using your product. 4) I support more window states than DockSpawnTS like maximization, minimization, etc. These states are certainly possible to turn off. 5) Apart of wcCabinDocker library I do not know any, that supports minimizing to collapsers. 6) @jogibear9988: As for the adoptNode in opening the panel to a browser popup-window I will have to make an option. I ran into scenarios with some diagramming libraries for which I need to use the classical approach like Golden Layout, that is using cloning. It will be there for handling edge cases, when adoptNode will not work.
- By floating windows @jogibear9988 meant that I can drag the panel and it will be floating inside the browser, not a new browser window.
Exactly, floating groups triggered by Shift mod seem to work & cover this use case on dockview demo page.
- I tried now DockView and for instance when the TabStripBar is smaller than available space for Tabs, "ugly" browser scrollbar appears. There are a lot of subtle, at fist glance invisible things, I do not want to have in my library.
afaiu the scrollbar is customizable. Do you mean that in your case it'd be more favorable to have "squished" tabs like on https://node-projects.github.io/web-component-designer-demo/index.html?
@evonox do you intend to use the new lib in some production / commercial / paid apps or is it a personal side project atm?
@timadevelop is "not removeing elments from dom" possible in dockview? This is for me the biggest needed feature. It means in dockspawn, only then x&y position and the width and height of the embeded child is changed, never it's position in the dom (only when you undock to a new browser window). This really matters if you have big dom trees
The dev branch of GoldenLayout does not (by default) remove elements from the DOM when they are moved. In earlier versions the content element hierarchy matches the layout hierarchy; that is no longer the case.
Note the dev
branch by default uses the DOM drag-and-drag API, which allows you to move sub-windows between different top-level windows. Of course in that case content sub-windows have to be copied.
However, it is possible to use separate top-level "raw" windows for each sub-windows. In that case you don't need to copy any window content even when dragged into a different top-level window. Instead we just re-position each sub-window. This is not done directly by GoldenLayout, but it has the mechanisms to do so. DomTerm manages windows this way when using the Qt wrapper. (There is experiemental support for doing the same when using the Electon wrapper, and it looks like it should be possible when using the Tauri/Wry wrapper, though I have not looked into it.)
@timadevelop is "not removeing elments from dom" possible in dockview? This is for me the biggest needed feature. It means in dockspawn, only then x&y position and the width and height of the embeded child is changed, never it's position in the dom (only when you undock to a new browser window). This really matters if you have big dom trees
Since dockview got a mention here I will add some details around the questions above raised.
For those who are interested: https://github.com/mathuo/dockview
Also, kudos to anybody developing a package related to layout management, it's a suprisingly complex thing to design.
Dockview supports both removing the panels content from the DOM when it is no longer visible and also keeping that content in the DOM.
The default behaviour is to remove the contents from the DOM since that's the most optimal solution but keeping the DOM alive for hidden panels is popluar since you will retain state specifc to the DOM such as scroll postions natively (and additonally if you are rendering iframes you need to keep that content in the DOM otherwise you run into all kinds of problems).
The mode you are using to render the panel can be dynamically switched out per panel and is persisted as layout state too.
There is some documentation on it here.
Floating groups as mentioned are supported and triggered by holding shift
when moving a panel and panels can be "undocked" into new windows through the api. You can also maximize a particular group.
See Floating Groups See Popout Groups See Maximized Groups
The scrollbar "issue" (I would prefer to call it "meh UX") when the group is too narrow is a little annoying and there is an open issue on this to have something a little better although I would also imagine you could use something like OverlayScrollbars here to get a nice non-native scrollbar.
dockview
is and always will be zero dependency. The core package is written in plain TypeScript and can be used without any framework, although this still needs to be documented a little better. There are also packages for native support with both React and Vue, there is also demand for an Angular package which is planned. React is by far the most popular use-case currently.
The documentation on dockview is fairly well covered and actually consumes quite a lot of the dev time as the package as grown in complexity ensuring that everything is well documented with examples.
You can view the documentation website here.
Dockview supports both removing the panels content from the DOM when it is no longer visible and also keeping that content in the DOM.
The default behaviour is to remove the contents from the DOM since that's the most optimal solution but keeping the DOM alive for hidden panels is popluar since you will retain state specifc to the DOM such as scroll postions natively (and additonally if you are rendering iframes you need to keep that content in the DOM otherwise you run into all kinds of problems).
This is not the thing im talkin about here.
It's about if a elment when moved form one dock to another (or opened as dialog) is moved from one dom node or only repositioned. If you have huge DOM Trees (we have trees with 1000s of elments (visualization applications)) it only works, if the dom node stays in the same DOM elment and it is only repositioned
Floating groups as mentioned are supported and triggered by holding
shift
when moving a panel and panels can be "undocked" into new windows through the api. You can also maximize a particular group.
Do you also support to undock to a new Window via adoptNode, or do you load the script and content in the new window? Dockspawn-ts only does the first at the moment. (And I've added a hack so webcomponents adopted stylsheets are copied)
@timadevelop: Nope, I do not plan to use my library in my own commercial product. It will be free under MIT license and I will do maximum for commercial companies to trust this library and to use it in production-ready enviroments. But to reach the objective it will take some time.
@timadevelop As for the React/Vue/Angular Framework support I have a different perspective of the future for the Docker Library. It should be framework-agnostic library that should easily plug-in into micro-frontend frameworks like SingleSPA. Then each content of panel could be a different micro-frontend application with its own framework, VanillaJS or using WebComponents.
@timadevelop As for the React/Vue/Angular Framework support I have a different perspective of the future for the Docker Library. It should be framework-agnostic library that should easily plug-in into micro-frontend frameworks like SingleSPA. Then each content of panel could be a different micro-frontend application with its own framework, VanillaJS or using WebComponents.
I think this should be possible with each of the other dock libs already. If you open the content in an iframe
It's about if a elment when moved form one dock to another (or opened as dialog) is moved from one dom node or only repositioned. If you have huge DOM Trees (we have trees with 1000s of elments (visualization applications)) it only works, if the dom node stays in the same DOM elment and it is only repositioned
@jogibear9988 pardon for my ignorance, but do you achieve this by absolute positioning "container" DOM elements that hold the content, which just happens to be a web component in the webcomponent designer example you shared above? Doesn't this cause problems with a11y and responsive layouts that run both on desktop and mobile platforms?
@jogibear9988 do you believe this https://github.com/whatwg/dom/issues/1255 would discard the need for such shenanigans in your (and most) use cases?
@mathuo do you think this is possible and actually needed in dockview considering https://github.com/whatwg/dom/issues/1255 ?
@jogibear9988 pardon for my ignorance, but do you achieve this by absolute positioning "container" DOM elements that hold the content, which just happens to be a web component in the webcomponent designer example you shared above? Doesn't this cause problems with a11y and responsive layouts that run both on desktop and mobile platforms?
Don't know what sort of a11y issues you mean? DockSpawnTs Samples work on mobile and desktop. The children and also the container do not have to be webcomponents. Look at the DockSpawnTS IDE sample, there are no webcomponents. And yes, the content div's are absolutely positioned ones. I added this support later, when I ported dockspawn it also moved the content around
@jogibear9988 do you believe this whatwg/dom#1255 would discard the need for such shenanigans in your (and most) use cases?
maybe this would solve it, but it for sure will take months (maybe years) untill such an API arrives
@mathuo do you think this is possible and actually needed in dockview considering whatwg/dom#1255 ?
I am just before finishing the pre-alpha version of the new DockerTS library. Could I ask for the public testing? Pre-alpha demo version of the library you can find at: https://docker.robotkarel.cz/ . If you find any repeatable error scenario, please submit me issue at: https://github.com/evonox/docker . Thank you very much for any support, suggestions or opinions of how to make the new library better. It will be released using MIT license for the benefit of the whole community.