Project Generator Ideas

[dimitre]

EDIT: Merged I'm working now rewriting some parts of PG, what was intented to be an issue fix transformed itself in a big patch

• [x] https://github.com/openframeworks/projectGenerator/pull/371 I'll be using here to discuss some ideas of things that can be changed / improved / simplified in near future.

PS: this can be moved to discussion if we enable discussion on this repo.

[dimitre]

One design issue: When passing multiple templates / platforms as parameter some files can be copied twice and overwritten, like Makefile (vscode template has its own, some platforms does it too) This is not easily seen because of the "overwrite existing" options

[dimitre]

@ofTheo Is this ok to upgrade projectGenerator visual studio project to 2019?

[ofTheo]

Absolutely!! 👍

[dimitre]

PG major changes are merged and tested through nightly release. macOS and iOS projects seems OK. I'll do more testing soon to see if it is OK in VS2019.

[dimitre]

Trying to run locally ./scripts/osx/buildPG.sh I find some issues with npm and temporary files (Apple M1) and I read somewhere (I dont know much about npm / electron) we can substitute this line:

# sudo npm install -g electron-osx-sign
sudo npx create-react-app electron-osx-sign

with this alteration the script almost until the end

[dimitre]

Frontend : it would be great to have an alternative to Electron, with lighter binaries like Tauri.app or Neutralino. Better yet would be make a web in OF using Webview https://github.com/webview/webview or even better, using only OF functionalities

[dimitre]

PG does multiple operations of reading files, writing, renaming and find and replace text inside files. it would be great to cache in an object all the actions (reading, replacing, writing) so they are all done at once, avoiding opening and saving the same file multiple times.

[ofTheo]

For the frontend stuff I am def down for anything that is lighter and easier - the app is now 300-400mb on its own. Caching etc, feels like lower priority as there are so many issues right now that need fixing, but would be lovely to add once we are in good place.

[dimitre]

Yes I agree. I can work in a prototype in the next few days, using OF, as a proof of concept to see if it fullfills the needs of the frontend. I can see pros and cons right now cons:

• browser widgets are more familiar to the new user

pros:

• lightweight
• easy to mantain because everybody here knows OF.
• easy and fast to publish / notarize or even build by install scripts

and I remember you mentioning about design, but I think we can manage to make something nice design-wise in OF too. thoughts? ideas?

[dimitre]

Multiple Recursive File Listing

PG list addon files recursively many times, one for frameworks, one for src, and so on. I've made an intermediate improvement which is saving in memory if a directory is already listed but it would be best to invert the logic, instead of trying to find each kind of file and listing directory maybe have one big directory listing and parsing everything from the addon inside this function.

[dimitre]

Duplicate code

OF PG has lots of duplicate code, like for example in addAddon function. Some of them are differently implemented just because it improved in one template and not in the other. One idea of improvement would be take advantage of the classes inheritage and try to centralize all the code pertinent to all templates in baseProject

example:

void xcodeProject::addAddon(ofAddon & addon){
    baseProject::addAddon(addon);
    // specific  xcode code here.

[dimitre]

Difficulty generating cross platform projects

I'm building VS projects in macOS but any project that uses libs, for ex. ofxKinect, the folder structure is not the same among different platforms, so the libs are not added.

[danomatika]

CWD Aware

I would like the GUI PG to also be aware of the current working directory or at least have this settable via a command line argument.

For example, I use the shell alias to launch it from the command line and I often wish it would know where I started it from so I don't have to manually navigate each time. We do this with the Pure Data GUI where if you start it via open or double-click in the UI it starts in a default folder but if you start it via commandline it uses CWD.

The alias I current use in ~/.zshrc is:

# openframeworks
WHICHOF="v0.12.0"
alias ofpg="open ~/src/of/of_${WHICHOF}_osx_release/projectGenerator/projectGenerator.app"

I could change this to invoke the binary inside which would then be CWD aware:

alias ofpg="open ~/src/of/of_${WHICHOF}_osx_release/projectGenerator/projectGenerator.app/Contents/MacOS/projectGenerator"

In this case, we'd want to perhaps change most of the default output to a verbose flag to IM. ;)

Commandline Argument Support / Bundling?

Is the command line PG distinct from the GUI app? I'm thinking if the codebases are/could be the same and the Electron UI is jus ta wrapper, it would be possible to ship a single .app but allow for invoking the command line options from within the app, ala open projectGeneerator.app --args .... This would make the same binary/set of binaries more flexible for both beginners as well as advanced users using the command line or makefiles.

If it helps, I have been using CLI11.hpp for the last few projects and am pretty happy with it, ex. YoloOSC: https://github.com/zkmkarlsruhe/YoloOSC#commandline-options. The parsing is done in the src/Commandline class.