Public Request for beta-testing of the new docking library.

[evonox]

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.

[jogibear9988]

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

[evonox]

Dear @jogibear9988 , thanks for your comments and suggestions. I will address your requirements as follows:

1. I understand the need for zero-dependencies. However we need the lodash functions for performance reasons as well as velocity-animate for fast JS animations. However I can address this issues as I will extract those few Lodash functions to my own helper class and remove the dependency. As for the velocity-animate, it is sad this good library is not maintained, I will replace it with my own JS animation framework. I do not write simple JS animation library for the first time. The other benefit for removing the dependencies is that we will decrease the JS bundle size. It is I think around 200kb without CSS which is quite a lot. My dream is to get with JS and CSS to around 50kb gzipped size.
2. I have a question. As you have noticed, I do not download WheelItem images, but inline them inside CSS. Is that ok for you? It has two reason. We reduce the number of HTTP requests the server needs to do and the second, we will have only two files for deployment.....CSS and JS file.
3. I apologize for the red flickering. It is not bug. I just noticed I have deployed the debug version of the library. I use red backgrounds exactly to find out, where the docking library is slow and needs optimizations.
4. I understand the DOM issues. It is one of major tasks that is still awaiting addressing. I will review this issue completely, not only adding DOM nodes but also implementing some diffing algorithms as you have in your DockSpawnTS in SplitterPanels and TabHost.
5. ESM will be created. This demo is just for presentation purposes. The library is not meant as production-ready now. It will take some time.
6. jQuery issue is quite funny. The reason it is there is the originally velocity-animate library was developed to replace slow animations inside jQuery. So this library is detecting if jQuery is downloaded to substitute its original implementation for animations. The sad thing is this library is no longer maintained so we have to remove it. The other argument for removing it is also the bundle size as I have written. I will implement its simplified version and substitute it. We will save a few KBs hopefully.

[jogibear9988]

1.) With brotly it will get much smaller

[evonox]

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.

[jogibear9988]

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?

[evonox]

@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.

[jogibear9988]

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).

[jogibear9988]

I've a few more questions:

• Is there a option for every button in the Panels/Dialog? Like IsCloseable, IsMinimizable, .... I think if I use it I will need this to be configurable
• What will the close button do? Remove the content also from DOM or only hide it? Should this be configurable? For example I've tool windows, wich I only create once. You could close the in docksspawn via "x" but I also could show them again.

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

[jogibear9988]

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.

[jogibear9988]

I used it the webcomponent for example here: https://node-projects.github.io/web-component-designer-demo/index.html

[evonox]

1. As for the undock / dock feature to new window I will make it one of the priority issues for extension. I want to support anything that is requested and make the library better.
2. Of course, it will be possible to specify if window can be minimized or closed, etc. It will be possible for each panel separately. I am in the process of writing the documentation. I propose we can then discuss the APIs if they are OK for you. By the way, you will have APIs giving you the full controls over the header buttons. You could even add your own custom header buttons. The same is true for the context menus where you will be able to define your own menu items.
3. As for the close button, it will by default remove the panel from the DOM. There will be however an option for Ghost Panels, that will exactly do what you request. They will be hidden by display: none and when you invoke to create such panel, it will just show again. So you could use default behavior or ghost panels upon the scenario you need.
4. The icons you have are fully OK for me. The next week I will have a videocall with my friend who is a graphics designer to discuss default coloring theme, animations, and possibly the icons. I will ask him for his opinion and we will see. The thing I need to mention is that theme of the new library will be fully configured by CSS custom properties, so possible to change in runtime.
5. For the web components, or what I understand as the need for declarative definition of layouts I would propose to take a different approach. I will explain possibly in a PDF document I will include in this discussion thread. Briefly said, the docking library is designed to support micro-frontend applications where one panel could be in React, the second using WebComponents, third VanillaJS or using Vue technology. This does not mean, it is not possible to create declarative definition of layouts. We can use

[jogibear9988]

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

[evonox]

@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?

[jogibear9988]

No, i used no framework. Will do the proposal

[evonox]

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?

[evonox]

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.

[evonox]

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?

[jogibear9988]

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?

[jogibear9988]

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

[jogibear9988]

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

[evonox]

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.

[evonox]

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

I have written a task to complete adopting CSS stylesheets with the dock / undock operations.

[evonox]

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.

[evonox]

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.

[jogibear9988]

I really like it. I'll look implement it into my designer, so I could see if my scenarios still work.

[jogibear9988]

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

[jogibear9988]

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.

[jogibear9988]

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

[jogibear9988]

the header should be scrollable via mousewheel not only via buttons

[jogibear9988]

https://dockview.dev/demo/?theme=dockview-theme-abyss has nice themes, and i like the feature to drag windows into the tabbar directly