Recently. we have read many posts about IDEs for Haiku. We would like to tell you that myself, Andrea Anzani (aka @xeD) and a few others from the Italian community are actively working on a project called Genio. Hopefully, we’ll get Stefano Ceccherini (aka @jackburton) on board soon.
Genio is a fork of Ideam, a native IDE for Haiku by Alessandro Mosca (aka AmosCaster).
Why a fork?
AmosCaster has put the project on hold, he does not think to be able to coordinate the project or contribute significantly in the near future.
We have decided to fork Ideam in agreement with AmosCaster also because of the changes we would like to make to the IDE that diverge a bit from the original vision. Why Genio?
Genio is the Italian for Genius, a latin noun derived from the verb geno (“to generate,” “to create”), hence “natural producing force,” means that special natural aptitude apt to produce works of important artistic, scientific, ethical or social significance. In Roman religion the Genius is a spirit or, more correctly, a tutelary deity, regarded as the benevolent guardian of the fortunes of families but also of individuals. Why a serpent?
According to the traditional latin iconography, a Genius was often represented as or along with a serpent. The majestic @zuMi has created this icon representing a cute friendly snake.
We have a number of goals for the evolution of Genio in the near future, these include:
Workspace Manager and Project folders
Language Server Protocol via clangd: autocompletion, jump to definition, and more
Bring the editor up-to-date and on par with other Haiku editors (Koder, Pe)
Plug-in architecture
Compiler error parser
Genio is hosted here and is made of three branches:
main - is functionally equivalent to the latest version of Ideam (v.0.7.9) at the time we forked it, except it is fully rebranded
workspace - this is the branch where the development on the workspace manager and project folders happens
experimental/lsp-client - this is the branch where the development of the Language Server Protocol and related features happens (e.g. autocompletion)
At the moment, we are not ready for prime time. We are working on a first subset of features like project folders and LSP.
We currently do not accept PRs as we are working on these two features but if you want to help and contribute, please reach out (bug fixes and small improvements, maybe?)
Ideam legacy and the current team make Genio a project 100% made in Italy which we are extremely proud of!
That’s a great announcement,can’t wait to see where the project goes.
I’m a big fan of Ideam and use it for all my projects on Haiku,because it’s so simple and lightweight but still powerful.
I didn’t know that there are other people who know of Ideam and like it,as the project on Github always looked rather small and quiet (not many stars or issues).
I even did one or two small bugfixes to Ideam (I think font selection or something like that) but can’t remember if it got upstreamed.
Currently I don’t plan to contribute,as I have too many other projects to do,but I’ll follow your progress and see how it improves my workflow further.
Nice! I hope the fact that you’re working on this IDE as a team, will help succeed where Ideam and Paladin got stuck.
Is it really necessary to have another editor from scratch though? Seeing as Pe, and more so, Koder are open source and you could try to collaborate to integrate it into the IDE. Haiku’s messaging system should help with the interfacing.
Not really, we embraced the idea of a fully integrated environment. We also share the vision that so many windows scattered around the screen make the developer less productive.
Genio is based on Scintilla and we already have the experimental branch using a much more advanced version of Scintilla than any other existing editor.
we have made the announcement to let the community know that there is an ongoing effort and it would not be beneficial to disperse energy and time creating new projects from scratch.
We truly hope we will succeed as a community!
Interesting! Although I fear the single window thing may miss the “Haiku way” kinda. I’d rather see the windowing features used more and not less… also from personal preference I’d rather not give up using Koder
I appreciate the way Koder manages windows is different and aligned with the Stack and Tile (only Stack, actually).
However, we are used to the “integrated” way and it fits better with our vision of IDE (like VS Code or Nova) which was the foundation of Ideam.
Genio supports Italian end English only atm. The catkeys are already present in the source code and all the strings use B_TRANSLATE throughout the code. We’ll take care of using Polyglot later
Yes I see that, It’s just that Haiku tries to be pluggable in the way of gui apps much more. Drag and drop between everything. Message apps to do stuff etc. A fully integrated IDE is morr the antithesis to this
There are things that you can’t do outside of the walled garden of an IDE like autocompletion using LSP (namely clangd).
Or very difficult to do, at least.
An editor like Koder does not have knowledge of the project a file belongs to, unless you integrate IDE functionalities into it making it… well, an IDE
Well, it’s not that hard to do really.
Paladin is going in that direction, it would only need minimal support from Koder to register some menu items or shortcuts that call back to Paladin and knowledge of which language server to connect to. Adam Fowler was working on that but he didn’t have any time for that recently. But I think it is totally doable
Paladin is not an IDE in the sense that is not integrated, neither Koder is (it’s an editor).
Paladin+Koder try to mimick an IDE by exchanging messages back and forth.
If you want to implement an LSP and do autocompletion, jump to definition/instances, refactoring and code analysis you propbably could, with a huge degree of complexity.
The reason is that Koder does not have knowledge of the project the file belongs to, Paladin has.
The way LSP works makes the editor (Koder) and the project management system (Paladin) tightly coupled.
You will not be able to switch to another editor unless it conforms to Paladin’s protocol on top of the Language Server Protocol.
It sounds flexible in theory but extremely complex and hard to maintain, IMHO.
What’s the difference with having an IDE where everything is seamingly synced and just works?
This is just my opinion and I don’t want to start flames, by any means. Just exchanging ideas and points of view.
This is a great initiative! Thanks to everyone involved!
I agree with @nephele’s sentiment, but there is no need to drastically change the project direction to achieve that I suppose. Please provide an option for a modular mode, in which every section of the application is a separate window, so that we (myself) spatial organising guys can have all things at a place on screen they desire. You can take this as a feature request if you will :).
From a technical perspective it seems doable but the windows will still be part of the same application.
But until we have a fully funtional API for both stacking and tiling, it will not reach its full potential I suppose.
Paladin+Koder combo is still mostly an unverified concept, and maybe it cannot achieve the usability of a fully integrated dev environment, so I think it’s great that there is an initiative to create “classic” native IDE.
My hope is that Koder and Genio can share most of the editor code. Scintilla is fairly low-level and some “basic” features need a lot of non-trivial code.
Please have a look at: Koder/src/editor/FindReplaceHandler.cpp at master · KapiX/Koder · GitHub. I’ve tried to make that Handler as independent from the rest of the program as possible; maybe you can use that code with some tweaks, to save yourselves some work. It also has unit tests: Koder/test/TestFindReplace.cpp at master · KapiX/Koder · GitHub to make it easier to modify and more robust.
If Genio developed similar modules, both projects could benefit, and achieve feature-parity for the editor part without too much effort.
The thing is, all the things you mentioned that LSP does, are done inside of an editor. So, it’s best to implement LSP support in the editor.
When I was investigating how I could integrate LSP into Koder, my impression was that all the knowledge is inside the LSP server. If you input project root and perhaps some include directories, LSP is going to do most of the work for you. When jump to definition is requested, LSP returns full path to the file that should be opened, and then the editor does that.
Unless I completely misread how LSP works, it’s not that much complexity. Paladin would just need to pass these paths to the editor.
