[RFC] build plugin proposal for modification
current situation
- The offered preset Target-Set suggest you can build something which is not true
- The offered preset Target-Set is virtually always wrong and give in best cases only a hint what can be set there
- You can't delete the offered preset Target-Set, well you can, but it comes back on next session start
- In combination with the project plugin you becomes even more confused, what does it mean "Project Plugin Targets", where suddenly come there from?
- Having more than one target-set on some project, in terms of "Project Plugin" vs "Build Plugin", is nonsense. You may have different kind of already configured build types, like "debug or "release"
- When you have created an own project, you can't share the configuration done in the plugin
- When you start to work on some received project, you need to read the shipped manual/README and configure the plugin on your own
- When hacking on KDE stuff, as advised by e.g. https://kate-editor.org/build-it, you will be flooded with targets and you becomes annoyed by the preset Target-Set which often pushes in front
proposed modifications
The build plugin should:
- Never load or save any configuration from or to a session file besides from current selected stuff
- Git rid of the term "Target Set" in its current form, even if the term is still used here, use "Project File" instead
- Save its configuration inside the project so you can share it
- Not offer any preset Target-Set ("Project File") without user request
- Offer a menu with different blue prints when clicking "Create new set of targets" ("Create Project File")
- Guide the workflow. No "make" when "configure" is needed, but not done
- Create some directory on it's own when it not exist, at least/latest after a user confirmation
- Have a filter field to search for a target when there are too many
- Be able to select more than one target to remove or copy them. "copy" from one "Project File" to another, e.g. from CMake generated into "you own", see below
possible ways to achieve the goal
If you disregard the many small details, it's all about where, or better how, to save the configuration. Where is no doubt inside the project.
1. we could save it as part of .kateconfig
But I know that Christoph is against that idea. I had made this suggestion in BUG-451238 in a slightly hasty way. In the meanwhile I came to the conclusion that there is a better possibility.
2. we should use .kateproject.local
From project plugin documentation:
In case you have a .kateproject file tracked by a control version system, but you need to tweak the configuration for a particular workspace, you can save those changes to a separated file named .kateproject.local. The content of this file will take precedence over .kateproject.
Once you are ready to publish your new project you can copy .kateproject.local to .kateproject and modify, if needed, it in a way that it will fit in most cases.
This approach results in the need to read and write that JSON file. And here is again Christoph against extra complexity or duplicate functionality, because the project plugin already read that file an feed it to the build plugin.
conclusion, discussion and personal opinions
To avoid redundant code or "duplicate functionality", it may be necessary to make major changes to the project plugin as well.
Let me a little digress from the topic.
A single usable build plugin is fine, I have done so for years, but a project plugin without a build part?
The current project plugin has many tabs that may useful. But for some of them I can't see a need. We have a already a terminal plugin which works very similar. "Code Index/Analysis" tabs sure, good but never used by me, like the LSP plugin. The "Notes" tab, really? Whats wrong with a simple file used on the main window?
I don't want to trash them but couldn't all these not be stand alone?
I personally asked myself if there is even a need for the "Projects" tab. It's essentially like the Filesystem Browser plugin with enabled "Auto Sync". Sure, not exact but is the small difference worth the effort? I guess the context menu entries can add to the other plugin as well, when the project plugin is active. The upper project chooser looks to me obsolete, switching to some opened file has the same effect. And the branch switcher my better fitting to the Git tab.
Can the Git tab also handle Subversion/Mercurial as stated on the config page? Change then the caption? Ok, now it's going to far with my digressing.
The point is, I think the build plugin should be much more part of the project plugin than other parts of the current project plugin. Especially if it writes the project file as proposed.
Thanks for reading.