Paladin
Paladin copied to clipboard
adamfowleruk
Question: UX issues in how Paladin works with Pe
Not sure how people wanted to address the below, so thought I'd put a question in GitHub about them.
Quitting Paladin should quit child Pe windows
If you're editing a project with many windows of code open, it would be nice for all the Pe windows that were opened by Paladin to be closed by Paladin. Not sure how feasible this is with the current way of launching them though.
Pe windows created by Paladin should be stacked
A nice feature of Koder is that all newly opened code windows are stacked rather than independent. Would be good to do this also. (Also, unlike Koder, the file paths should be relative to the project root, not absolute paths, in order to save screen real estate)
Pe editing options are file based, not project based
Most projects use a consistent set of editing settings. E.g. tabs at 4 spaces width. Pe's preferences for this are file based or global (to the user) - not project based. Again, not sure if this can be resolved give Pe is an external app.
Cross file code references
Pe has the f(x) button which can skip to a named function within a file. It would be good to expand upon this functionality so that hitting a key shortcut looks up the function/class under the cursor, whether in the same file or another one. Again, as Pe is a single file editor it won't know how to resolve a project's references, so not sure how feasible this is.
Pe's .h button doesn't work
Pe successfully lists the correct header files in the .h toolbar button drop down, but clicking on them does nothing. Doesn't open them. Leads to a little confusion for the user.
In Summary
Given the above, is it best to stick with Pe, or should the option be considered of having a Paladin managed editor window? Whether that is an embedded Pe frame, or Koder's approach. I'm not sure what is technically possible integration wise with Pe as a separate external app.
Pe is also on HaikuArchives. Early on Paladin author tried forking Pe if I recall. Probably best if we just leave then as two separate projects. You might also looking into fixing some of the long standing issue with Pe.
Another issue: Position of Pe editor window
If possible, open Pe editor windows to the right of the Project Window. Often it appears over the top of it.
The way I'd see it is a specification of protocol based either on BMessages or Scripting API (which is BMessages, but accessible from hey), that defines a common base to implement for each editor - like go to line, open that file, close/move window, etc. Then we could implement that in Koder, Pe and gvim and have any of them work with Paladin.
