Create new app from template

[meisenzahl]

To further develop Code into a user-friendly development environment, I thought it would be a good idea to add an option to create an app from a template. This PR is a functional prototype for it.

Could be interesting especially in conjunction with #940.

It adds an option to create a new app.

Selecting this option opens a dialog asking for information about the app and the developer. When all the information is entered, the template folder data/templates/app is copied to the desired location in the background. In the filenames and in the files template tags like {{ app_name }} are used. These are then replaced with the information from the dialog.

In case of an error, a warning is displayed.

The created app supports the following features:

• Hdy.Window
• Hdy.HeaderBar
• Hdy.WindowHandle
• settings to save/restore window position
• supports dark preference
• translations
• Flatpak manifest
• GitHub CI configuration

I am looking forward to ideas how to develop the feature further.

[meisenzahl]

This is removed because install_subdir in data/meson.build only works with absolute paths:

ValueError: dst_dir must be absolute, got out/usr/local/share/io.elementary.code/templates

Reference: https://github.com/elementary/code/runs/2421607609

[danirabbit]

This is definitely really interesting and speeds things up a lot to create a new app. I think in a lot of ways we should probably do less though, especially in places where you need to now go delete a bunch of placeholder stuff.

For the icon files, it would be better to have them named like 24.svg, 32.svg etc and use meson to rename them. In fact there's a lot of data files that could have simpler names and use rename in meson so that they would be easier to identify in the sidebar instead of having to use RDNN there

In the dialog, it probably would be better to use Granite.ValidatedEntry to validate inputs as you go instead of waiting to validate afterwards and throwing errors

[jeremypw]

I would concur with the previous comments that the first PR should only create the simplest possible app but create (or at least be compatible with) a framework to extend the templates on a mix and match basis so the developer is able to only choose those facilities they need. It might be interesting to have a separate repo for templates that Code could clone from (a clone repo function would be desirable for Code anyway). This would keep the Code code base smaller but relying on the web for functionality has drawbacks.

[donadigo]

Some comments for you.

[jeremypw]

Shouldnt this be in a finally {} clause? Looks like the dialog is not destroyed after an error.

[jeremypw]

Needs more detailed and specific validation.

[jeremypw]

Do we need to use the FileChooser portal if this is work in Flatpak?

[jeremypw]

I would really like to get this progressed. I think this is close to the minimum requirement for a Flatpak'd app suitable for the elementary AppCenter but does not provide much of a teaching experience. One thing that could help with that is to provide much more commentary in the templates as to what the code is for and where additional code may need to be placed. Yes that means the user may want to delete these comments from the app but that is going to be a very small part of creating a complete app. I suppose a "Include commentary" option could be implemented in the dialog as a refinement.

The structure within /data/templates/ could be arranged to make mix and matching easier. Maybe need templates that can optionally include other templates so Flatpaking, Window Settings, GitHub CI etc could be added as modules. I suppose the minimum app would be one that runs locally non-Flatpak'd with no settings, no custom icon, no CI, no revision control?? Not sure how basic @danrabbit wants to go.

This PR does not create a git repository for the app, it would be nice to add that at some stage (as an option).

[danirabbit]

@jeremypw My inclination is that there shouldn't be a single feature to create an entire app as this kind of dumps you into an overwhelming amount of code all at once and the case of creating a whole brand new app is a rare case that's kind of weird to optimize for.

It might be more helpful to have a handful of separate features for creating each of the following:

• Vala class file
• meson build file
• AppData file
• Desktop file
• Flatpak Manifest
• LICENSE
• Initialize Git

This would still be really helpful to cut down on boilerplate, it would avoid creating a ton of files all at once that are hard to understand, and it would be more generally useful for projects that in varying states. I don't think it's an anti-feature to require some kind of documentation to create a brand new app from scratch. It's probably more important that a new developer understand what each thing does and why they're doing it than just how fast they can get to a generic project that builds

I think combining this with some kind of snippets for each file type would be really powerful. For example, in an appdata file you'd have a snippet for a new release tag or in a Flatpak manifest you could have a snippet for a new module.

[Marukesu]

It might be more helpful to have a handful of separate features for creating each of the following

Isn't this the case of the TemplateManager?
I mean, the api seems pretty extensible, so they can be used in both cases.

[jeremypw]

@meisenzahl From Danielle's comments it looks like the way forward would be to break this PR up into smaller diffs starting perhaps with the ability to choose one or two basic templates (e.g. stand-alone Vala class file, root meson.build file). You would still need a dialog to gather information such as author name, email address, license, class name, project name, depending on the nature of the module. This could then be iterated on to add further modules and refinements such as updating the meson.build file when another class is added.

Combining these with snippets (for which another PR is currently in progress) would reduce the donkey work without deducing the need for understanding.

[meisenzahl]

I'm closing this because the desired solutions are likely to be solved with snippets and the TemplateManager.