Consider merging with or into other projects.

[abalter]

There are a number of FOSS projects creating docking layout UIs. Some of these use a similar approach to golden layout in that you drag the tab and get a visual preview of where it will land. Mainly, phosphorjs which is the backbone of the Jupyter Notebook UI. Most others use the same type of interface as the not FOSS jqwidgets docking UI [^1]. In fact, the demos for them look very similar, and might be clones:

• https://github.com/caplin/FlexLayout/
• https://github.com/mathuo/dockview (homepage having a crashing problem right now).

Golden layout's overall experience is definitely superior. However, some of those other libraries include more features such as a distinction between panels and tabs, both of which can dock.

Meanwhile, there are some really nice FOSS UI libraries geared toward dashboards or more general apps. These have rich features sets and vanilla JS dependency. However, none of these have dockable layouts. I see this as a huge shortcoming:

• https://preview.tabler.io/
• https://w2ui.com/web/

I would love to see golden layout be incorporated into one of the UI libraries, or some other cooperation that could guarantee it becomes more widely used and supported.

[^1]: They do have a free noncommercial use license

@nealatcaplin @nealus @mathuo @codecalm @SyntaxJoker @tabler @vitmalina

[codecalm]

Hi @abalter, I'm creator of tabler.io. If you need some extra features, which isn't included in Tabler give me know :)

[abalter]

@codecalm --- how about a docking layout system :)

[codecalm]

I think that it's possible witch Tabler and drag and drop library. I can try to do some sample of this.

[PerBothner]

However, some of those other libraries include more features such as a distinction between panels and tabs, both of which can dock.

What do you mean by this and how is it different from GoldenLayout?

[abalter]

@PerBothner --- those other UI kits are very full featured. They have rich systems for tabs, panels, accordions, navigation bars, data tables, menus, forms, etc. They are geared towards building apps and dashboards. However neither tabler nor w2ui (both FOSS) have docking panels or tabs.

I think those UI kits would really benefit from having docking elements. Golden layout is one of the best. Although, @mathuo has recently made some improvements to dockview, including nested tabs, tab groups, and dockable panels that can also contain tabs. Golden Layout is still smoother and does not depend on react.

All I'm saying is that everyone I tagged in the initial issue is working towards the same goal---a rich, capable, dependency-free UI kit. I would love to see the features of all of these united.

Ultimately, this is what I would like to see possible.

[PerBothner]

Obviously, we don't want to depend on React, and I doubt any one of us has time to learn React or work on integration with a React-based library. However, we're happy if someone makes use of GoldenLayout, or writes (for example) a React wrapper over GL. We're also open to API changes/additions that would make integration with React or other libraries easier.

This is some existing document using Frameworks, but note we're considering making changes to how components are bound - and these might be incompatible.

See this discussion.

[abalter]

Oops, that went the wrong way.

Dockview depends on react which I see as a shortcoming. But it does have better features than Golden Layout.

I think it would be great if either

1) Golden Layout offered more UI widgets or 2) The people who make w2ui and tabler would work with you to have docking layouts that can use their widgets.

@codecalm @vitmalina

[abalter]

@codecalm --- any luck?

[PerBothner]

GoldenLayout isn't a general UI or widget librray, and I don't think it should be. It's already fairly large, and we probably don't want to add anything that isn't directly used by the layout-manager. On the other hand, it might make sense for GoldenLayout to be built on a librarry of lower-level widgets - but I can't think of much that is both generally useful and non-trivial that it would be worth abstracting out.

I'm happy to "work with" people doing other libraries - but I do have other projects keeping me very busy, of course.

[abalter]

Right now, jqwidgets is the only UI library with a docking layout that can be used for free (non-commercial license, $$$ commercial license). I'm just hoping that there will be others soon.

[vitmalina]

Hi, @abalter, I am the author of w2ui. Well, though, w2ui does include a basic layout, there is no restriction to use any other layout library. Is there any problems with using GL and w2ui together?

[abalter]

@vitmalina --- I can see how I could include w2ui elements in GL tabs. But I don't see how I could use GL to dock w2ui elements such as w2ui tabs, grids, toolbars, etc.

@PerBothner It looks to me like there are three key components here: 1) how the tab objects are defined and stored, 2) how groups of tabs are defined and stored, and 3) how the drag and dock algorithm works to reshape the other tabs/panels. Is that true?

If these three components could be modularized or encapsulated sufficiently, then perhaps they could be agnostic to the other components. For example, given a native w2ui layout, could the drag and dock algorithm easily accommodate the w2ui elements? Could the drag and dock algorithm be easily ported to the elements in this example? https://w2ui.com/web/demos/#/layout/9

Alternatively, could the w2ui tabs here https://w2ui.com/web/demos/#/tabs/1 simply be GL tabs?

[PerBothner]

GL is fairly simple conceptually. A GL manager manages a rectangular area, which can be sub-divised horizontall and vertually into tiles. A tile is called a "stack" in GL. Each stack can contain multiple components (tabs) along with a header (normally above). Each component can be "virtual" - GL manages the prosition of a component but not its contents, place in the DOM, or its rendering.

The GL managed area does not need to be the full page, and it is probably possible (though little tested) to nest GL managers. It should be possible (though again little tested) to have multiple GL managed areas on on the same page, and to drag between them. It is definitely possible to drag components between top-level windows, when using my fork (which uses native drag-and-drop).

[abalter]

NOTE: After writing the below, I went back to the demos because I had a vague memory of seeing some things in the integration demos. So, it looks like these things are possible!

Since each component can be "virtual," would it be fair to say that a dockable tile could be anything? Say, a panel with toolbar? A grid with a toolbar? Text editor? Tree-grid file browser? Charts?

If so, how would the binding work?

[PerBothner]

Anything can be a component as long as it is rectangular and you have an API to position it. (Focusing and z-ordering changes may also be need to be supported.)

It doesn't even have to be DOM. The Qt frontend of DomTerm has an outer QWebEngine that run GoldenLayout and optionally menus. Each component is current a nested QWebEngine, but it could be some other QWidget.

Having text editor components (probably either CodeMirror or Monaco) is actually on the DomTerm roadmap.

Binding works (in my fork) by GL calling a notifyResize handler, which is responsible for positioning the widget.

[PerBothner]

An update: I've been working on merging a large number of commits from (mostly) 2022 into my fork. Some got accidentally dropped from my fork by one of my commits; for others it just wasn't a priority keeping things in sync. So I've rather tediously cherry-picked a large number of commits, resolved conflicts, and tested that things built.

I'm finished the merge into my fork. If you notice a commit that I missed, and you believe it is still valuable, let me know.

I'm currently working on polishing the "hook" used to create virtual bindings. (It will be called createComponentElement, to be called before registerComponent if you need to control bindings.) Once that is working (at least for DomTerm) I'll start on updating the documentation.

Once things are a little bit more stable, I'll merge by fork into the dev branch here. At that point I expect to do future development in the branch, and drop my fork.