Is your feature request related to a problem? Please describe.

There is very little unique content stored in a .kpj file. We encourage a directory structure already. Why not formalize this and move away from projects and instead open a 'folder'. Then populate the 'project' view with the contents of the folder.

Proposed by @MattGyverLee:

The package (.pkg) solves a real issue of cherry-picking files/keyboards for the release. The Keyman (.kmn) file connects all the keyboard bits (OSK, Touch, Icon) to the keyboard.

What does the .prj file really do for us other than duplicate data from other sources and be out-of-date when you make changes with Developer closed? It seems like we could just open the folder, let it auto-populate folder contents on open, and the contents of the .prj file could be reduced to a “.env” file.

Is there a use-case for people keeping data (keyboards) from different root directories in a project? I can, of course, see a use case for different roots in a package.

Commentary by Marc:

This is a good suggestion. The .kpj.user currently maintains state -- but it can always be thrown away and is easily transitioned to a folder concept. The .kpj served more of a purpose in the past. We've really come full-circle on how the projects interact with keyboards and packages. This seems like it would be a good future feature.

I'm not sure how we'd transition from .kpj to .env (or whatever it is called). We can't assume that existing files are structured by folder. Perhaps it could be a test when loading the project and if the project meets certain structural requirements offer to upgrade it (and offer reasons why not if it can't be upgraded).

Considerations:

• Project Options remain important: these would need to be stored in a .env?
• build Folder can be a bit confusing -- needs to be cleanly ignored in the project view (shaded down similar to .gitignored files in VS Code, perhaps).
• multi-keyboard packages (not super recommended anyway) in the existing repository reference files from outside the folder. These are the biggest use case for projects.
• This would mean two sets of 'project' style code to maintain in Developer. Some re-abstraction would be necessary to make this maintainable.