What I was refering about is this...

https://www.youtube.com/watch?v=19IIEveUbNI

There is no builtin API for this, that's why Jonas mentioned the extension mechanism, which you can use to implement this feature yourself. See also #14577 for the respective issue for this task.

Theia already stores and loads layouts. Theia uses this to restore the layout the user had when they closed Theia. The entry point for restoring is here, the ShellLayoutRestorer implementation can be found here and the layout is applied within the shell widget.

This can serve as the inspiration / base to implement perspective support in Theia. As you can see, we use the same restoreLayout of the DockPanel as in the linked jupyterlab example.

I went through the code you shared and here are my questions and few observations.

In the main shell you have set some initial UI components like the left toolbar, bottom status bar, etc...

My first question is: Since we have at the root of theia the plugin foundation why aren't we using the dogfooding principle to transform those UI components as UI plugins and load them at startup? This makes more sense IMHO because first it will modularize the whole main ui and also help the new comers to understand that everything is fractalian (Bundlerized OSGi style)

If we transform all UI components as Theia plugins we can move each piece to arrange different perspectives and layouts.

An application can have many perspectives and why not a single Theia having the possibility to host many applications?

How about this UI model beneath of Theai plugin system for UI components?

https://edvin.gitbooks.io/tornadofx-guide/content/part1/3_Components.html

Well, but Theia is designed not to be Eclipse IDE. If you want Eclipse IDE, why don't you use Eclipse IDE? :)

This lecture seems to prove the opposite from the architecture perspective

https://www.youtube.com/watch?v=5tKLePLfWbc&t=880

This lecture seems to prove the opposite from the architecture perspective

I don't really see it that way. It literally just says: There are similarities, or at least analogies between features of Theia and RCP. And then continues to show them. Of course there are - they are both IDE frameworks after all.

Since I am following this thread in the beginning things were foggy, but now I started to connect the dot because I am coming from the Java background and a lot of the things as-salam mentioned might seem overboard because you are coming from another background (maybe)?

As a former Java developer I can rather confidently say: Java frameworks are almost always overengineered and overcomplicated. As someone who has also done a lot of TypeScript framework work in the recent years: You usually get the best results when engineering for the simple case and allowing escape hatches for the more complicated use cases. Theia enables you to do that, for essentially everything. By default, we obviously use VS Code as a reference (with it's horde of UX designers), because it works. It's the most popular IDE/code editor for a good reason. If adopters want to change the UI they can do that, but they'll need to put in the work - which is usually well accepted.

Again not saying that we shouldn't make it easier for adopters to customize the UI. I'm just saying there needs to be a balance between the work the framework contributors are willing to put in to allow for easier customization compared to the work of adopters to customize the existing UI code. Given that no one has implemented such a feature in the past 8 years of the frameworks existence, I would even argue that the demand for this is rather low.

Well, but Theia is designed not to be Eclipse IDE. If you want Eclipse IDE, why don't you use Eclipse IDE? :)

@msujew I have found this article in which the author and few other collaborators think about Theia: https://thenewstack.io/eclipse-theia-the-deepseek-of-ai-tooling/

It looks like some people are thinking differently 😄

Theia is Eclipse with only the AI missing part if we agree to simplify the conversation.

I don't really see it that way. It literally just says: There are similarities, or at least analogies b
Again not saying that we shouldn't make it easier for adopters to customize the UI. I'm just saying there needs to be a balance between the work the framework contributors are willing to put in to allow for easier customization compared to the work of adopters to customize the existing UI code. Given that no one has implemented such a feature in the past 8 years of the frameworks existence, I would even argue that the demand for this is rather low.

That last statement sounds a little bit oppinionated. If you don't offer another way to the contributors who have no other knowledge about IOC UI automation then you are implicitly forcing them to be the developer and the plumber. Coming from Mario & Luigi era they had to take lots of pipes to save the Princess and beat Bowser.

Automating the UI with Inversify should have been tought about from the beginning since Inversify had decorators right from the beginning. As a Framework provider from the scale of Theia project someone had to realize hey why am I the plumber while we can delegate that to automation. When you offer a Framework, you are supposed to engineer with automation and sometime over engineer to think about future technical debts and ease for refactoring possibilities.

That's not even a complicated task and it seems you are afraid that things will break. I saw quickly that many parts of Theia are really old.

Otherwise I would have not waved those flags from the beginning.

Let's say that it is already moving in the positive direction because the guys at Pandino answered quickly to my red flags.

Either you jump in the band wagon or you're left behind.

We'd rather smoke the peace pipe and relax while we delegate the plumbing to Mario & Luigi.

Do you want users to install perspectives at runtime? I am not sure if I understand the use case you are aiming at, maybe you could add more details on what you want to achieve?

Do you want users to install perspectives at runtime? I am not sure if I understand the use case you are aiming at, maybe you could add more details on what you want to achieve?

See this full thread and let me know what you think.

#12669

Also have a look at this blogpost

http://puces-blog.blogspot.com/2012/12/drombler-fx-building-modular-javafx.html?m=1

It compare itself to SWING/RCP

Kind Regards

@JonasHelming Any thoughts?

Do you want users to install perspectives at runtime? I am not sure if I understand the use case you are aiming at, maybe you could add more details on what you want to achieve?

Yes that's correct! I have looked at the source code and much of Eclipse's original concepts and architectural foundations are in like the shell, extensions ... the only thing missing is the OSGi dynamic under the hood which is offered by Pandito.

I thought hooking the OSGi runtime underneath and put the shell on top and then wire the UI plumbing & wiring with Inversify annotations by borrowing the missing features from DromblerFX and give Theia the ease of component based UI development.

I have to admit the amount of informations I have gathered is quite a mouth full but you can follow our thought process here:

#16001 (comment)

If you are one of the core architect of Theia you can't just pull out of a conversation suggesting best practice and more advanced solutions. Sooner or later you will have to take part into the discussion for changes.

As a Theia project lead, I can do what I want. I believe I made my stance on this clear. Respectfully, please don't continue pinging me on this issue :)

If you are one of the core architect of Theia you can't just pull out of a conversation suggesting best practice and more advanced solutions. Sooner or later you will have to take part into the discussion for changes.

As a Theia project lead, I can do what I want. I believe I made my stance on this clear. Respectfully, please don't continue pinging me on this issue :)

You are free to do as you want, but getting out of a discussion about improving Theia in the long run might cost you your position once the proposal prototype is implemented and proves to be more efficient as the old decisions you made for the architecture.

Always keep that in the background of your mind.

With respect sorry If I had made you feel uncomfortable with the way I expressed myself.

Kindly

Note that inversiland is not pulling in inversify as a dependency, but is forking it - which technically makes sense, but it means that it no longer builds on top of inversify. Additionally, since that's an unvetted inversify version with arbitrary changes (and likely without any recent updates), I'd be a bit more hesitant to use it at all.

Like I said, there are also a lot more reasons, like the fact that we make very good use of the imperative API of Inversify to enable features such as connection scoped containers or even more simple stuff like dynamically named loggers. Without going deeper into it, I have a hard time imagining how those could be replicated using a declarative API.

For dynamically named logger without really knowing deeply was probably resolved in OSGi.

Maybe those might help for that part:

https://dev.dotcms.com/docs/osgi-dynamic-plugin-logging

http://liquid-reality.de/2018/08/07/logging-osgi.html

Back in the days I was using ops4j pax which work pretty well.

https://github.com/ops4j/org.ops4j.pax.logging

Like I said, there are also a lot more reasons, like the fact that we make very good use of the imperative API of Inversify to enable features such as connection scoped containers or even more simple stuff like dynamically named loggers. Without going deeper into it, I have a hard time imagining how those could be replicated using a declarative API.

Maybe we should ask the people at Pandino how they will resolve those worries in a declarative context environment.

Note that inversiland is not pulling in inversify as a dependency, but is forking it - which technically makes sense, but it means that it no longer builds on top of inversify. Additionally, since that's an unvetted inversify version with arbitrary changes (and likely without any recent updates), I'd be a bit more hesitant to use it at all.

Inversiland's author was already notified to fix that design flaw : inversiland/inversiland#16

No, my change predates it, and it also does not feature a bundler.

How about trying both and compare the speed?

IMO I would do that as a separate change. Otherwise it becomes to complicated to figure out which tool is responsible for possible regressions. But that will surely come.

However it would be worth exploring if this can literally obliterate that 1 minutes+ compile time.

We still believe that our method will obliterate that compile time to sub ms.

I found this Rust solution it might be better than Golang implementation.

https://github.com/rolldown/rolldown