generalize to other frameworks

[kobi2187]

Hi, how about generalizing so that new:app, new:route, new:api will be jester:app, jester:route, jester:api

then add new ones for GUI app (e.g. nimx, nigui), TUI app (e.g. illwill), command line (parseopt or similar, and get going) and unit testing (the builtin unittest:suite macros -- maybe even find all procs in file and create skeleton tests for them).

that could be cool.

a nim.cfg with all the options commented out.
a gitignore or hgignore file is also welcomed.

[Adeohluwa]

honestly, that's an interesting idea! will look into it, do you have background in GUI ... that way you can give me a sense of what's needed to scaffold for GUI apps as an example

[kobi2187]

Thank you for the positive message,
The main idea is to get to a working hello_world once you run your software. It can be for gui, tui, and others. I think combining them in the same code base is more than possible:
for example, I think I would still split the code to files: domain.nim, views/nimx.nim and projectName.nim (which has the main "controller-like" logic), something like that, then have the main proc in the relevant view. (multiple main procs, and we choose which one to compile as the main program)
Possibly fill the main proc with a raises: [] pragma (to check for all uncaught exceptions), and have an args variable, that just read the command line parameters.
You can also be opinionated and choose a parseopt library, (I saw the new simple_parseopt, which looks great - but haven't tried)

Gui examples: (one for gui that looks the same everywhere -- makes it simple and consistent but sometimes foreign, the other gui looks like the OS it runs on -- native)
https://github.com/yglukhov/nimx#usage
https://github.com/trustable-code/NiGui/blob/master/examples/example_01_basic_app.nim

[Adeohluwa]

will certainly be adding Nigui... could you use the recent binary i just pushed update & tell me how well it works?