Is it dead?

[Moon422]

I have following this project for sometime now. However, I have not seen much updates lately. Thus, I am wondering whether the project still alive or abandoned?

[lytico]

it depends if there is someone continuing it.
i personaly see no future in it.

why?

the code base is rotten. there was a good architecture, but it was buried under hunting of deadlines without having a strategic view.
XWT - the gui base of it - is dead.
the whole build - project - workflow is outdated.

my advice:

complete restart on an architecture based on:

omnidevelop as base of the build - project - workflow
and, as the core, an code-editor based on language server,
maybe based on maui as gui

[Dadoum]

We could also create set of patch for VS for Mac. We need to find all the #if MACOS code in binary (should not be too hard), add all #if LINUX code (maybe a bit harder) and fix the Linux editor (I think we sholuld use the VS one with Skia, so this is the hardest part) to fix it. Then, when VS For Mac 2021 will release this will surely be much more work since this will switch to full native UI, but yet that's possible. (I already made some binary patchers using Mono.Cecil and to me it seems feasible, at least for the #if parts)

[lextm]

@Dadoum VS for Mac is no longer open sourced (since 2020.01) and keep changing, so any attempt like "patch for VS for Mac" is not sustainable (unless you enjoy reverse engineering). Meanwhile, that's also not legal as Microsoft holds the copyright and enforces the integrity of its products.

Like @lytico explained, the current code base has too many limitations so to move it forward can be quite hard, while there isn't a strong community around it any more.

[lytico]

@gluckez dotdevelop/dotdevelop#72 (comment)

there's a lot of good stuff in there

to your opinion, what is the good stuff:

• in the build - project - workflow, what's not in omnisharp?
• in the editor, what's not in a code-editor based on language server?

[vanackerglenn]

@lytico my comment was more about the reusability of the different components.
I haven't gone in depth in the code itself, but more into the architecture.
If we can untangle this monolythic structure first and work towards a more evolutionary architecture,
it would be a lot easier to upgrade different components and introduce new features.

What I was thinking is that we can start by seperating some of the projects that have no dependencies on others into nuget packages, upgrade those and maintain seperately. We could immediately rename those projects as well.
This way, we move away from a giant monolith and it'll be easier for other developers to onboard.

[lytico]

architecture/api links:
https://www.monodevelop.com/developers/articles/architecture-overview/
https://www.monodevelop.com/developers/articles/api-overview/
https://www.monodevelop.com/developers/articles/the-project-model/
https://www.monodevelop.com/developers/articles/extension-tree-reference/

others:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#languageServerProtocol
https://github.com/OmniSharp/omnisharp-roslyn/tree/master/src/OmniSharp.Abstractions
https://github.com/OmniSharp/omnisharp-vscode/wiki/.NET-Core-debugging-feature-list
https://github.com/Microsoft/MIEngine/wiki/Architecture-of-the-MIEngine

https://github.com/roslynpad/roslynpad

[vanackerglenn]

I suggest we don't stick to that architecture. there are several things that pop out to me that I would do differently. for example the addins. To me, addins are a feature of the IDE and don't belong in the core of the project. I took some time today to extract the addins from the core projects into a standalone solution that could be distributed in a nuget package.
When you build a modular evolutionary architecture, you could really allow for certain parts of the app to be enabled or disabled through feature flags or configurations. So you could roll out a new version with improvements when you want and enable or disable features on the fly.

I just had some issues with the gtk stuff, because there's a project that relies on gtk2. If I understand correctly, your goal was to use maui? I'm all for that, but it would also be easier to do if the UI wasn't a part of the monolith.

Edit: I also want to note that the projects I seperated from core are pretty much copy pasted files into new projects that target netstandard2.0. there's still some stuff I need to look at, but long term I think that would be better.

Edit2: When I look at the language server protocol specs, the first thing I see is that it defines a set of json rpc requests, responses and messages. And when I was going through the addin code, I also added a note to replace the older remoting services with gRPC. so it might be interesting looking into writing an abstraction over that in a seperate utilities or core solution.