I have a query about how people use Paladin or their other (heathen!) IDEs for development.
Paladin currently allows you to open multiple projects, each with their own project file list window. In addition to this, each project will have its own child windows. E.g. when you build Project A and Project B, they each get their own build error windows. Same for ‘Run logged’ to show stdout/stderr, and so on.
You can see this in the below image:-
The question I have is, is this useful? Or is it too many windows cluttering the screen? Would developers prefer one set of output windows rather than a set per project?
As you can tell from the above image I’ve started consolidating several windows in to one. This is still a window per project. I hope to have Build output, Run logged stdout and Run logged stderr as tabs in the same window.
Tools like Visual Studio Code have a set of windows per project too, but they are panels in the same IDE. Eclipse has multiple projects in the same navigation menu, and one set of output tabs embedded in the IDE.
The idea I had was maybe having a single window across all projects that would remember its placement and would also hide when not in use, and you could show/hide with a keypress anywhere in the application. This could evolve to be a general project notification panel including updates (E.g. new commits to the remote branch added, new issues in GitHub logged, and so on).
Personally I’d like all non code editing windows to be hidden unless I need them, but my brain works in a specific way and doesn’t like distraction, so I’m wondering if anyone else had their own thoughts or ideas outside of the norm of current IDEs?
I think there is mo problem with multiple windows. Bug they should be on fix Positions, so they are fast available? Stack and tile support can help here too.
If it is possible I would sugesst to concentrate more on the functionality than on design of the windows, tabs, shortcuts… maybe one can adjust the design later on if needed?!
I am not a programmer! I like if the program remember its window possitions! changing workspace may be a help here…
For inspiration: MeTOS is a GUI Editor, it can create the C++ (or other langage with CodeGenerator plug-ins) source-code from a GUI you have created with it.
With that, you don’t need to make every time yourself the code for GUI. https://cvincent.pagesperso-orange.fr/logiciels/metos.html
Just an idea: https://www.faststone.org/FSViewerDetail.htm
Its innovative but intuitive full-screen mode provides quick access to EXIF information, thumbnail browser and major functionalities via hidden toolbars that pop up when your mouse touches one of the four edges of the screen.
Yeah I agree on this point. In order to solve some functionality issues though (Better output parsing / g++ error detection and highlighting, add new programming languages, among other things), I need to standardise the way Paladin works with external processes first, with gave me the opportunity to merge some windows. I thought I may as well ask for feedback whilst developing that feature.
Having said that… The most positive individual feedback I’ve had is from fixing UI and behavioural inconsistencies in Paladin. I think people like it when software ‘gets out of the way’ - so anything I can do to make it smoother in a dev’s workflow seems to be welcomed. Fixing the project window scrollbar being out by 2 pixels seemed to calm some people!
The MeTOS IDE is interesting - I’ll add that to the feature issue on GitHub for a visual designer. There’s a few out there, all a little different from each other, and all in different states of repair. Thanks for the link!
Full screen mode option is an interesting idea. I had thought of something similar like a saved ‘Editing Layout’ for all the windows. Currently Paladin does this (inconsistently per window) for each project, but I think having a dev’s own preferences and hitting a shortcut key to switch between, for example, ‘debug layout’ and ‘coding layout’ would be useful. Kinda like Eclipse perspectives, but with less overhead.
Any other personal workflow preferences / crazy ideas? Keep the ideas coming!
I’m only a (very) small time developer, so take my words with some lumps of salt…
Having separate windows for currently opened projects does have advantages. Many are Windows trained, and tend to clutter their single ‘desktop’.
Haiku, OTOH, has up to 32 workspaces. You can have several projects open and their windows laid out how you like. Then quickly switch between workspaces e.g. with CTRL+ALT+Cursor.
Should you need to compare stuff from two projects, just move the window from one to the other’s workspace and maybe S&T them.
Keeping separate windos allows for some flexibility.
about the crazy stuff i’d like support for other languages and/or support for customize the building workflow via configuration or external plugins to work with languages other than C
Agreed. A large part of what I’m doing at the moment is standardising and refactoring things that need to be in place for this to happen.
At the moment only really C++ compilation is supported (Although other source file types are supported), and language support is not pluggable. Also the code is very tightly integrated - so much so that the ProjectBuilder class actually creates some of the commands to execute C++ compilation itself rather than this being done purely by the SourceTypeC class. I’m slowly breaking these apart.
Post build actions are also limited. For Paladin itself, for example, I need to generate both an app and a library for my tests to link against. Can’t do that right now - only one or the other. Same with catkeys files for translations. Building a hpkg is another one people have mentioned.
Were there any particular build steps that you’d like Paladin to handle?
Fixed in develop branch. I’ve checked, tested, and reworked all the non-settings windows so they now do this on a per project basis. They all only currently remember size and position, not which workspace they were last on.
I am used for many years to work in single window IDEs with project browsers embedded and debug/output windows as panels inside that open/close as needed. Similar to edit/debug modes you described. Most of my dev life with Visual C++ something IDEs. Last years I worked with separate windows for editing/building/debugging but I realized that I spent time and energy switching between various windows. Also other windows/apps for maintaining journal, tasks lists and dev notes. So, from last summer I began using VScode on Linux to unify again my dev experience. I still need to build independently but having embedded terminal solved my problem. So editing/building/debugging now happens under one “mainframe” window and my workflow is better. I have a separate sublime session with extra packages installed that I use for notes/tasks.
So, I think I prefer a unified approach with embedded browsers/panels but I am totally open to other approaches. The truth is that as I was searching for minimizing my window changes at work I tried to find a Haiku like window manager to get stack/tile abilities but I failed. I know that some tile window managers support also tabs but I didn’t want to do severe changes to my existing Linux installation.
So, I think that maybe utilizing Haiku’s unique abilities for window stack/tile would be helpful in Paladin’s case.
Another point, since I didn’t answer to your initial questions, I think that a fast indexing system to allow for goto declaration/definition/references is something very useful especially when working with big piles of code that you didn’t write in a complex project or when trying to learn a new system, like Haiku APIs for example.
Thanks again for all the work you put on Paladin!
I was thinking about this yesterday. An internal task and notes list that gets saved in the repository next to the PLD file. Would this be useful? As an example, for all compilation problems have a tickbox next to each issue, a select all button, and a ‘make task’ button. Then shortcuts to show / complete / skip to next task. (Linked to the relevant source code file/line/col of course). Would be useful for own tasks, and perhaps could have a ‘list issues in GitHub → Make task in project’ option.
I’ve started on this with the Quick Find (Alt+F) option. Currently it only does a fast search by file name within project, but will be extended to search text and definitions within source files.
As a separate/independent note:
I recently evaluated CLion on Linux. I was really impressed by its ease of use, UI consistency feeling, deep attention to details on UI design, huge amount of preferences but logically organized. Overall I had a sense of smoothness that I had many years to encounter on any application. It supports cmake based projects native. I used it with such a (relatively small) project and auto-complete and goto declaration/defintion/references worked immediately and correctly.
The reason for deciding not to use it was that the above essential code-navigation features were not working with a huge C++ project which was not based on cmake; just created the project by adding folders with C++ files. Also, its indexing in this case was very slow. In comparison vscode has a really good behavior with big projects and code navigation features work as expected.
But I am referring to CLion here just in case you want to check it for its overall smooth sense and UI approach. Of course a totally subjective opinion
right now i’m doing some HTML/PHP/JS development so I need live syntax checking for those (including embedded js in <script>) and the ability to launch the php test suite on save
I’m using Paladin for app development on Haiku, and its multilaunch abilities are very useful. You see, there is no such thing as “too many windows” when you can dedicate a virtual desktop to every project. Heck, you can dedicate even two desktops to every project, opening the code on one and keeping the reference material on another.
Virtual desktops. This is the solution for all windows clutter.
The use of multiple windows in Paladin—and the overall design of Paladin—mirror the way Metrowerks CodeWarrior worked on BeOS, which in turn was inherited from CodeWarrior on the Mac, Symantec C++ and THINK C on the Mac, and finally THINK Pascal and Apple Macintosh Pascal (written under contract by THINK).
It’s a very good design and IMO one of the important things about the BeOS environment that Haiku needs to re-create.
I don’t currently use Paladin, but here is what my typical (vim+terminal) workflow looks like.
I often have multiple vim sessions, each with tabs and splits, sometimes running in different Terminal tabs, or different Terminal windows accross different workspaces. Basically this creates a multi-dimensionnal environment in which I can get around very quickly and remember where things are.
I would feel very limited by running an Eclipse-like UI where the opened files are listed in a handful of tabs at the top of the screen, in a single dimension.
The way I organize things is adjusted to whatever I’m doing at that moment. I will usually start with a vim session for the file I want to work on, two terminals (one for building/running, one for git grep and otherwise looking around at things), and then add new tabs as I dig deeper into bugs and need to look at more and more files.
As for build output/run output, having them in the same window may be ok, but I think I see an use for separate build output/grep or find results windows, for example. So maybe stack them together by default, but make them detachable?
