Commandline arguments?

[sphh]

I desperately miss command line parameters, so that I do not have to click all those buttons on the start-up dialog. I would be happy to make a PR, but would like to coordinate with you first, so that my efforts are not wasted.

What do you thing? Would that be something you might accept?

My idea would be to tap into the run() function in ryven/main/Ryven.py. In a first step I could think of implementing arguments for both the window and the flow theme, to enable debugging to the terminal and of all the three buttons in the start-up screen ("Create new project", "Load project" or "Load example") …

Further steps could include:

• Importing nodes (I would love to have this!)
• Set performance mode
• Set animations
• En/disable info messages

IMHO this would also be a good place to read an configuration file (do you have any preferences regarding the format?)

Does that sound sensible to you?

[leon-thomm]

What do you thing? Would that be something you might accept?

Oh, please go ahead! I suggest argparse.

I desperately miss command line parameters, so that I do not have to click all those buttons on the start-up dialog.

I did add some shortcuts and autofocus stuff so I usually do navigate quickly only using the keyboard, but they are not really documented and are very incomplete. And command line arguments are invaluable nontheless.

run() function in ryven/main/Ryven.py

yep

arguments for both the window and the flow theme, to enable debugging to the terminal

yes, support for setting the REDIRECT_CONSOLE_OUTPUT attribute would be great

and of all the three buttons in the start-up screen ("Create new project", "Load project" or "Load example") …

Further steps could include:

* Importing nodes (I would love to have this!)

* Set performance mode

* Set animations

* En/disable info messages

agreeing with all of those. performance mode, animations, info messages are set in MainWindow during setup, see setup_menu_actions() (just parametrize this with the config argument of the MainWindow constructor or something). You might also want to skim through the constructor and the rest or run() and adapt it, it's currently not too consistent, e.g. remove

        if 'info_msgs' in sys.argv:
            rc.InfoMsgs.enable()

IMHO this would also be a good place to read a configuration file (do you have any preferences regarding the format?)

Absolutely, I do not have strong preferences, you probably know better than I do (otherwise, YAML is nice because it is obvious and allows comments).

[sphh]

Oh, please go ahead!

Thanks!

I suggest argparse.

That was my idea, too.

Absolutely, I do not have strong preferences, you probably know better than I do (otherwise, YAML is nice because it is obvious and allows comments).

IMHO YAML is always a choice I like. But it would pull in another dependency. But I have another idea, let's see if it works …

[sphh]

I've three more questions:

1. Do you want to keep the signature of the run() function in ryven/main/Ryven.py for backward compatibility? If that is not required and the possibility to pass arguments to run(), I would suggest to use a syntax similar to the command line arguments. This approach would also cater for additional arguments introduced in the future.
2. I noticed, that the project is passed as a dict (read from the file) and not as a filename. Shouldn't the loading of the project file be part of the flow window (then it would be possible to load a script into the running application)?
3. I would also like to pass the list of nodes packages to load as a list of directories to the flow window (instead of a list of NodesPackage instances).

[leon-thomm]

1. Backwards compatibility not strictly required but passing python objects as arguments to run() (like a QApplication) definitely is for scripting support. But you could move your argparse stuff to the main block in Ryven.py instead (might be cleaner anyway)
2. This was a deliberate choice because it needs to extract the required node packages from the project file for the SelectPackages_Dialog before the editor launches, for which it needs to parse the project anyway.
3. I would prefer sticking to NodePackage objects for MainWindow. When using command line arguments to spcify node packages etc. you probably want to completely skip the StartupDialog, so I suggest then converting the pecified node package paths to NodePackage objects in run() before passing them to MainWindow. Otherwise we might end up doing everything in MainWindow but I wanted to split responcibilities a bit so MainWindow doesn't need to worry in which environment it is running. (imaging deeply integrating ryven in a larger python application and passing NodePackage objects to run())

[sphh]

1. Backward compatibility […]

Yes, I want to keep the qt_app and gui_parent arguments as they are at the moment. My idea was that all other arguments are compatible between run()'s keyword arguments, argparse command line arguments and a configuration file; that means they have the same names in all three appearances.

2. This was a deliberate choice […]

Fair enough. That's why I have asked.

3. I would prefer sticking to NodePackage objects […]

Fair enough!