[EventGhost] - Enhancement - Changes eg.Cli to use argparse #212
Conversation
Changes eg.CLI from using sys for parsing command line arguements to using argparse. I have also added error reporting in the event of an incorrect argument. This is done through the use of a wxDialog because py2exe overrides stdout. There is one big change and that is the -h -hidden is not longer supported. this is because of -h -help, so the -h -hidden has been changed to -mg -minimizegui since this is really what it does in the first place. I do plan on hadding a -ng -nogui option to completely hide EG except for having it in the process list. This is not a large issue due to someone using the -h is going to bring up the help dialog.. and they can read it and discover the change I have also added -- switches as well. Todo: Reformat the help
Adds a verbose logging option using the-d -debug --debug command line argument Adds 2 additional decorators @eg.LogItVerbose, @eg.LogItWithReturnVerbose To use this you would specify the module you wish to add verbose debugging to.. this works as a hierarchy. If you want to enable verbose globally -debug eg If you only wanted to enable it for core plugins -debug eg.CorePluginModule For a specific core plugin -debug eg.CorePluginModule.System Maybe even a specific module under that -debug eg.CorePluginModule.System.PowerNotifier You can also specify more then one module to debug at a time. -debug eg.CorePluginModule.System.DeviceChangeNotifier eg.CorePluginModule.System.PowerBroadcastNotifier doing somethinhg like this would be pointless -debug eg.CorePluginModule eg because the CorePluginModule is apart of the eg module
|
Added verbose debugging see commit for details |
|
Could you do /? for help instead? Any change to the command line switches should also update https://github.com/EventGhost/EventGhost/blob/master/_build/data/docs/commandline.rst accordingly in the same commit. |
|
I am not all that familiar with argparse.. I have not gotten into the help end of it .. one of the reasons why the Todo is for the formatting of the help |
Changes -h from help back to hide and adds -? for help Formatted Help is DONE!
|
@per1234 you asked and you shall receive! did what you asked with the -? And I also formatted the help so it's understandable.. well I think it is anyways LOL... |
|
well... i didn't change the rst because I knew I was going to be working through the Help bits also and didn't know if i was going to find a better way. and also if i remember correctly that rst file is BLANK anyways!! and seeing as how there is now an actual -? or -help or --help for this bugger.. having an rst file for the command line switches is kind of redundant if you ask me... most people are just going to try the typical -help Now i just have to figure out how to allow for both - and / switch prefixes |
Adds the old style /? and /f /e type of switches
|
OK so the / switches were pretty simple. i thought i saw something for setting the switch prefixes when i was reading the code for argparse |
That's fine, I'm just saying the documentation needs to be updated before this is merged.
No, GitHub just renders it that way for some reason. See: https://raw.githubusercontent.com/EventGhost/EventGhost/master/_build/data/docs/commandline.rst
I disagree. I think it much more likely that people would check the help contents or the online documentation, both of which are generated from commandline.rst. I do think it's great to have help also available via command line but I just don't see it getting used as much. That might seem strange that users wouldn't use command line help to get information on command line switches but I don't think many people actually using the command prompt these days, rather the command line switches are used to allow EG to be controlled by other applications or shortcuts. I even tend to just write a batch file when this is necessary like: eventghost/?
pauseinstead of having to run CMD and then having to type out the correct path. It would be nice if there was a way to have commandline.rst be automatically generated so there is no chance of it getting out of sync but I'm not sure how difficult that would be or if it's worth the effort. |
|
syncing the rst file shouldn't be an issue. I have to take a look at it.. and either i can parse the rst file to populate the CLI help or vice versa.. I will take a look.. |
|
ok.. syncing the rst file would have been some work.. the only easy way to do it would be to alter the builder to do so.. the CLI args aren't something that gets changed all that often. so having to add some lines to the rst file wouldn't be all that hard.. I updated the RST file as well as the /? output to be the same. |
|
as far as the syncing goes I am pretty sure I could use the docsort and add an entry into the builder for building it.. I would have to check with @topic2k for instruction as he just did this with the eg.WindowsVersion. It would be far easier to ask then for me to go poking about to figure it out LOL. |
|
The cli args help could be automatically added to the help file. I've tested it but it doesn't look good in the standard layout. It would need some more work to display it nicely. Not sure if the effort will be worth it considering that it want change often (as @kdschlosser already mentioned). |
|
The thing is the help is also located in a different spot meaning when you open help from inside of EG.. the current builder is not set up to add anything other then what goes into "eg". Now that being said.. It would be nice to include the "Help" for a specific bit in that bits file.. but i would much rather see the use of markdown if at all possible and deep six the windows help and just have it load up a web browser based help. we could always compress the html files into a single file for all of the help and have it decompress it into a temp folder upon opening up the help. I feel this would be far easier to maintain. then having to have separate files like it is currently setup.. and having to know yet another "language" to code in.. and having to remember what does what with who and why as far as markers in the doc. But i would deep six the use of commonmark for this because of it's very limited markdown abilities. I found that when i was making the help for the device change notifier I have a markdown editor for my IDE and commonmark doesn't support 1/4 of the things that can be done. |
We had discussed using browser based help on the forum but it got bogged down by the complaint that it wouldn't be available without internet connection. I don't know why the idea of providing local copies of the help HTML files didn't come up at that time. It sounds like a reasonable solution to me if the current system of generating Windows help files during the build is causing limitations.
What do you propose should be used instead? There is possibly relevant discussion of switching from reStructuredText to CommonMark markdown here: #18 |
|
nah that's not going to cause an issue. that can be very easily changed. and a web browser supports all kinds of different code types. so we basically have our pick of what we would like to use. I personally would like something that would make use of the doc in the code files. and build the "help file" dynamically. this would make it easier to change the documentation when the code gets updated.. because it's in the same file. Now we would most likley have to make or own language for the doc files and have it convert it into html. because the use of html in doc is not going to be the prettiest thing to look at if you load up the help in an IDE or from the pyshell in EG. and it also contains way to much markup language in it. using a markdown language is good. but commonmark is very limited in what it supports. I am going to take a look see at what might be better to use. and run some tests to see if dynamically creating the help is a way to go. This would also make it a lot easier for a plugin dev to add documentation on their plugin as this information can be loaded into the standard EG help |
|
ok so CommonMark supports more then the docs state. But I have found one that i kinda like alittle better. only because it supports adding plugins to it so if we wanted to add some additional formatting options we can.. and there is a whole lot of plugins already available for it. I have not looked to check if CommonMark supports plugins as well. and what is available for them. |
Changes eg.CLI from using sys for parsing command line arguments to using argparse.
I have also added error reporting in the event of an incorrect argument. This is done through the use of a wxDialog because py2exe overrides stdout.
There is one big change and that is the -h -hidden is not longer supported. this is because of -h -help, so the -h -hidden has been changed to -mg -minimizegui since this is really what it does in the first place. I do plan on adding a -ng -nogui option to completely hide EG except for having it in the process list. This is not a large issue due to someone using the -h is going to bring up the help dialog.. and they can read it and discover the change
I have also added -- switches as well.
Todo: Reformat the help