I do really wish the window management while using Paladin will feel more integrated though (for example, forcing the text editor to open inna stack at a specific part of the screen), but that might have to wait for the Stack&Tile API.
Yes, on the newer versions (which will appear in the Haiku Depot once I fix a build problem) all the paths are saved relative, and platform (32 bit, x64) independent. So you can absolutely copy the folder containing the PLD file and it’ll still work.
Yes, that is stack and tile dependent. We did talk about this at BeGeistert last year. Both myself and @KapiX (of Koder fame) are likely to support the API when ready. I’d love to add default developer preference settings, for example, to set up a consistent set of window positions and settings.
1 Like
You are welcome to contribute to the API and its implementation on Haiku side, of course 
1 Like
Hi all. Based on my own thoughts and recent feedback I’ve come up with a potential list of priorities to help me decide where to spend development time. Please do give feedback on this - it’s just an idea at this stage.
In order of descending importance
Paladin primary goals
- Support those new users coming to Haiku and learning development there
- Reasoning: Having more developers use Haiku and Paladin helps drive usage and innovation, and feedback for Paladin and Haiku, and creates new volunteers for development, accelerating the remainder of this list
- Samples (C++ generally, and Haiku Dev)
- Project Templates
- Tutorials
- Help material (or links to existing API docs)
- Primarily support native Haiku development
- C++, Be GUI API, Layout API
- Fit in with the Be GUI paradigm
- stacks, tiles, remember window positions, workspaces, etc.
- Enable fast workflows
- developer centric, quick key shortcuts, invocation and automation of the whole build and release process, including source control
- Don’t re-invent the wheel - link to existing tools and approaches rather than re-writing things (E.g. using Koder and LPE, Debugger, etc.)
- May have to create a Be GUI builder though - none currently being actively developed or supported
- May have to develop a source control management interface - most functions already there (but hidden)
- Allow Paladin tools / windows / views / replicants to be re-used by other IDEs / apps
- Minimalist UI by default - no dead space, or hardly ever used buttons cluttering the screen
- Support legacy BeIDE .proj files and code
- Support 32 bit and 64 bit development, and old (low resourced) hardware
Stretch goals
- Support other build systems (CMake, make)
- Testing ground for UI and Haiku API innovation
- Messaging protocols (E.g. open file at line x and col y)
- New UI controls (StreamingTextView, MonitorWindow)
- Potential core APIs (CommandThread, GenericThread)
- Support increasing code quality
- TDD & BDD automation
- Profiling and reporting (gcov, lcov, etc.)
- Support hey scripting (of the Paladin UI)
- Extend and more tightly integrate with other tools (Terminal, Koder, lpe, Debugger)
- Support other programming languages (C, python, hey, BASH)
- Multiple UI options for different developers’ needs (E.g. fullscreen dev, replicants for stdout/err, single window support)
- Support targeting non-Haiku platforms (E.g. sdcc for z80 and 8051, Arduino, arm)
8 Likes
Here is my wanted list of features:
Type inference and code completion
Symbol and name lockup (quickfind)
Jump to symbol
Find usage
Refactor Rename/Extract
Code Coverage
Great to see work on an IDE, thanks!
There is a symbol finder under the tools menu in Paladin. Is there a particular type of search you needed for this?
Paladin is now compiling with debug flags. Profiling flags were working, but are a bit hit and miss (related to the many ways commands are executed from Paladin, which I’m cleaning up at the moment).
Coverage is in the roadmap - a personal mission of mine with testing!
All of your other ones are language server / Koder related, so will be solved when I’ve researched that. I need to finish the refactoring of command execution first really. It’s getting closer though! 
3 Likes
Just wonderful Christmas gift you will give us here…
Wow…
1 Like
For those wondering why editor features like syntax highlighting aren’t in my list it’s because that really belongs in Koder or lpe.
Having said that, I’m looking to integrate a Language Server in to Paladin. These need to be ‘project aware’ and so should sit inside / alongside Paladin rather than the editor itself. I will probably test this by enabling quick find for class and function definitions/declarations, but the editors themselves will need to be extended to use it too for all the code editing functionality.
I can pass in the project info, language server URL, and other metadata to the editor when Paladin launches the editor. I’ll document this protocol so any editor creator can integrate well with this feature.
(FYI I’ve already done some enabling work by generating a compile_commands.json when you do a build in Paladin. That’s in the develop branch. This file is used by language servers.)
2 Likes
how are you implementing language server? Is it a http server or some Haiku specific socket/Bmessages/hey scripting?
I was planning on porting an existing one rather than re-invent anything. CCLS looks most interesting, but I’m having trouble building it with our ported LLVM. (It uses Clang LLVM). This way Paladin could manage the running language server and give it the context of a ‘project’, and the editors could slave off of this context when editing files to provide type ahead and declaration lookups and such like. Same principle behind VSCode.
Hello, I have not reported any problems since (a) a lot of compiles that did not work seem to be working okay now. (b) My Haiku development is split across 4 computers and I am trying to find if the problems are caused by the different system layouts or because I have different code on each system. I am transferring and testing all versions of my code on all systems to find out.
Also since I downloaded the latest version I could find on HaikuDepot a lot of my problems seem to vanish - Good Job!
1 Like
Great to hear! Any problems please do let me know.
1 Like
All of this could also be phrased as “clang tooling integration” since clang supports basically all of the above.
Yeah I’m looking at CCLS as a way to provide it.
I just tried to add my own template following the documentation. However, /boot/system/apss/Paladin is a protected read-only folder.
Is there another way to add a template?
Currently Paladin only scans the App’s own system folder, which as you say if installed as a hpkg is read only. It would be rather trivial for me to modify Paladin to check a folder under /boot/home/config/settings/Paladin/Templates, if that would help?
Please also send me a link to the docs you have followed so they can be fixed.
It was such a quick fix that I’ve now added it and committed the code to the develop branch. You can either grab the latest source from below, or wait for the next version to be put on HaikuDepot.
A user can place their own template folders in /boot/home/config/settings/Paladin/Templates/ now. If others want to make a set of Paladin Templates and contribute them as a hpkg, you can also target the /system/data/Paladin/Templates/ folder for your own template directories.
Enjoy!
3 Likes
Sorry I’am not sure weather the /system/develop/Paladin/Templates/ folder would be the better choice?
I have no preferences. @PulkoMandy suggested either of these two, so I just picked one. Any background as to the intent of each folder in Haiku?