My opinion: I'd just merge kdev_contextmenuextension & kdev_mainwindowactions into kdev_plugin to reduce the maintenance burden imposed by the number of templates this adds.

Both kdev_contextmenuextension & kdev_mainwindowactions just show off a tiny feature of the plugin infrastructure, I'd rather have the plugin example carry everything, then users can remove features by removing the code snippets one-by-one. Personally I like it a lot better to instantly see all the hooks I have in a plugin (thus a full-fledged kdev_plugin with minimal code snippets to show off what's needed) and then remove what I don't need when I iterate on the code.

[09:16:23] <frinring> kfunk: as the file template supports injecting code into existing files, when you choose an output filename that matches an existing one, the workflow I followed when using these templates was: having an existing kdevplugin class, I had to enter the matching class name in the option page or manually fix the filename. then the snippets were added to the right files already (as currently you have no preview to correctly select the injection
[09:16:25] <frinring> position). then I moved the snippets to the right place in the file
[09:17:15] <kfunk> okay, I didn't know it supports injection...
[09:17:37] <kfunk> and I don't suspect our users know it either. I'd still find it cumbersome to use personally

Seems like frinring & me don't agree on this:

• me: have one big kdev_plugin template with most commonly used features
• frinring: minimal kdev_plugin template, extra features (context menu extension, main window actions) in separate templates

Other opinions/ideas?

I think I'm with Kevin here, if I imagine being a user I would prefer having one demo project which shows up all the things a lot over having lots of individual templates I have to piece together.

Guess one template type does not fit all developers :)
All I can tell is that, as already stated initially, for my workflow those template snippets have worked well and were designed following my needs, other than a full-featured template variant which I even wrote first for myself.
I found having to manually cut a full-featured template down to the things I only needed spoiled the idea of a quick "need X" -> "have X" + having to enter some options or being confronted with I did not care for. Also did it not fit the iterative development of the plugins I did, where I only added feature by feature, starting small with a minimal plugin with basic functionality and making sure after each little step that things worked and initially even had no clear idea what the plugin should do in the end (he, some call that "agile" ;) ).

Surely there are other use-cases (like the mentioned "demo project" and development models or conditions where a full-featured template fits better than these small bits. So we might look into having both approaches perhaps.

But then I also still think this:
[Freitag, 17. Februar 2017] [09:25:21 CET] <frinring> kfunk: okay, so thanks for feedback. seems in the current state they should not be in, as the overhead of maintainance and risk of bitrot might not match the possible usefulness to users, given the oddness. so will keep as WIP for now and first see to improve the wizard. perhaps I could instead upload them to store.kde.org, so people interested still have access

Note that for simple snippets, using the snippets plugin would be better, not the full-blown template engine.

In D4490#87785, @mwolff wrote:

Note that for simple snippets, using the snippets plugin would be better, not the full-blown template engine.

Yes, very possibly. I yet have to explore the world of (Kate?) snippets though. Are multi-file snippets supported? Do they have access to codegen knowledge?
Where do I need to look at to learn more about the technical details?

When I dream, all the app template, file template and snippet stuff would be more integrated :) Too many inconsistencies in the generated code, different template syntaxes and features, etc.
Why can't the world be perfect already :) Because we would be bored?

Sorry for 'your loss', but I think it makes sense to just abandon this patch. It's probably easier for someone to start off from an already-existing plugin (which is similar to what the author intends to do with his new plugin).

I'm afraid these templates here would bit rot quite easily, and you are probably the only one caring about them enough to maintain them.

No loss here for myself, I just offered to share them with the rest of the world :) I now just need to have proper personal backup and cannot rely on the global internet kdevelop git backups ;)