Researching Potential Theia Project

[nturley-copia]

Hi, I've been researching a potential work project to use the Theia framework for a desktop application. I've spent a few days learning about Theia and I'm really impressed. This is a really cool project. :)

For some background, our company, Copia Automation, currently has a domain specific git client desktop application that has some specialized handling for the file formats used in the PLC industry. Many are binary, many are graphical diagrams, some are very large and require LFS to work well with git, etc. So our desktop app has features like file diff rendering, default repo LFS configuration, and other features to make it easier for users to use git. So my research project has been to investigate whether it makes more sense to base our application on Theia instead of maintaining our entire application ourselves.

I spent some time playing with Theia and I've got a few questions. I know this is a lot but I'd appreciate any insights anybody has on any of these.

• I've been playing with how SCM and repositories work. It appears that while VSCode and the VS Code git extension support multiple repositories simultaneously, it appears that Theia SCM doesn't handle it very well.
  • Is this a known limitation with a tracking issue? If not, should I create one for any discrepancies I find between VS Code SCM and Theia SCM?
  • Is it a project goal to reach parity with VSCode SCM? Frankly I'm not sure I care about multi-repository, but I'm nervous about users stumbling into it partially working and running into broken behavior.
• Suppose I want to customize the SCM view, by adding/removing buttons and other UI-level changes. Is it better to create a new one and hide the old one or to extend and replace the SCM view with our own?
• Theia has soooo many more features than our existing application. It might be less jarring to our users to hide as many of these new features as possible, however if I want to support VSCode git (and I think that I do because @theia/git appears to be deprecated?) then it appears it brings in a whole bunch of theia extensions as transitive dependencies that are not really applicable for our users like debugging. I tried hiding each feature individually like unregistering menus and so on, but there are so many and it's easy to miss them.
  • Is there a better way to hide extension functionality more thoroughly? Extend the contribution, replace the implementation with a version that overrides methods with no-ops? Contribution filters?
  • What happens if a VS Code extension or something tries to access this functionality that I've disabled? Am I going to make the application more unstable or is it likely to fail silently?
• Our current application has certain functions that execute before or after certain git operations. The git operations are presumably run by the VS Code git plugin and seem to be triggered by Commands. Is there a way to register some kind of listener for commands that other extensions have registered? Maybe unregister their command and register mine with the same ID, add my special action and then forward it to the original command?
• What determines the contribution ordering? If I want to unregister a menu, do I need to ensure that my extension runs after the extension that registered it?

I appreciate all of your help. My project is still in the research phase, so it's possible that nothing will come of it, but supposing that we do go ahead with this, do you have any recommendations of the best ways to become part of the Theia community? For example are there communication channels that are important to watch and participate in?

[JonasHelming]

Hi, I've been researching a potential work project to use the Theia framework for a desktop application. I've spent a few days learning about Theia and I'm really impressed. This is a really cool project. :)

Hi,
great to have you here!

For some background, our company, Copia Automation, currently has a domain specific git client desktop application that has some specialized handling for the file formats used in the PLC industry. Many are binary, many are graphical diagrams, some are very large and require LFS to work well with git, etc. So our desktop app has features like file diff rendering, default repo LFS configuration, and other features to make it easier for users to use git. So my research project has been to investigate whether it makes more sense to base our application on Theia instead of maintaining our entire application ourselves.

Thank you for providing some background, that helps in answering questions for sure!

I spent some time playing with Theia and I've got a few questions. I know this is a lot but I'd appreciate any insights anybody has on any of these.

• I've been playing with how SCM and repositories work. It appears that while VSCode and the VS Code git extension support multiple repositories simultaneously, it appears that Theia SCM doesn't handle it very well.

  • Is this a known limitation with a tracking issue? If not, should I create one for any discrepancies I find between VS Code SCM and Theia SCM?

I am not aware of this, so reporting your findings makes sense!

• Is it a project goal to reach parity with VSCode SCM? Frankly I'm not sure I care about multi-repository, but I'm nervous about users stumbling into it partially working and running into broken behavior.

As we use the VS Code Git extensions, the answer is yes!

• Suppose I want to customize the SCM view, by adding/removing buttons and other UI-level changes. Is it better to create a new one and hide the old one or to extend and replace the SCM view with our own?

This is a little hard to answer without knowing the full details. I would probably start customizing the existing one, until it gets cumbersome. If it gets cumbersome, you can either create your own or you can still make the existing one more configurable. The second option would avoid you forking the existing view. The project is open source, contributions are welcome. Best is to open an issue describing a suggested change as a first step to allow the community to provide feedback on an idea. You can also join the weekly dev call to pitchs ideas like this. Which approach makes sense really depends on the details here.

• Theia has soooo many more features than our existing application. It might be less jarring to our users to hide as many of these new features as possible, however if I want to support VSCode git (and I think that I do because @theia/git appears to be deprecated?) then it appears it brings in a whole bunch of theia extensions as transitive dependencies that are not really applicable for our users like debugging. I tried hiding each feature individually like unregistering menus and so on, but there are so many and it's easy to miss them.

  • Is there a better way to hide extension functionality more thoroughly? Extend the contribution, replace the implementation with a version that overrides methods with no-ops? Contribution filters?

I would say probably contributions filters. We would love to be more modular in some areas. However, we also suffer a bit from the parts we reuse, most prominently Monaco.

• What happens if a VS Code extension or something tries to access this functionality that I've disabled? Am I going to make the application more unstable or is it likely to fail silently?

If you use contributions filters, you usually just remove the UI elements, so this should not introduce any instability (as long as no components relies on the UI element. They should not, but there is nothing that was not tried in VS Code extension yet :-))

• Our current application has certain functions that execute before or after certain git operations. The git operations are presumably run by the VS Code git plugin and seem to be triggered by Commands. Is there a way to register some kind of listener for commands that other extensions have registered? Maybe unregister their command and register mine with the same ID, add my special action and then forward it to the original command?

Either that or maybe use native Git hooks? They would have the advantage that it also works if a user triggers Git on the command line?

• What determines the contribution ordering? If I want to unregister a menu, do I need to ensure that my extension runs after the extension that registered it?

AFAIK, they are ordered by dependency. As the unregistration code depends on the registered items, it should work.

I appreciate all of your help. My project is still in the research phase, so it's possible that nothing will come of it, but supposing that we do go ahead with this, do you have any recommendations of the best ways to become part of the Theia community? For example are there communication channels that are important to watch and participate in?

Weekly dev call
Mailing List
Twitter
LinkedIn

And some more information in here:
https://eclipsesource.com/blogs/2023/11/22/how-to-become-visible-theia-adopter/

Please let us know if you have more questions!

Best regards,
Jonas

[nturley-copia]

Thank you very much. Very helpful.