Can these be installed concurrently? Are they mutually exclusive, as in only one can be installed to provide the functionality at a time?
I am hesitant to install and then uninstall a plugin not knowing how well plugins clean up.
If I could make a recommendation, that screenshots of the installed plugins be made a submission requirement so that users can see what they are installing beforehand. Some do, most don't.
Most of the plugins offered are third-party / user contributed software. Having multiple choices is usually a good thing although it does make it harder to choose sometimes.
My experience with the plugin manager is that it cleans up nicely. In addition to uninstalling, you can also disable a plugin so you could install both and then use disable/enable to decide which you want to keep.
With regards to the progress pair, they display slightly different information on the same status line of the LCD display. While they both could be installed concurrently, they would overwrite each other's LCD display. Probably not optimal.
Some plugins do conflict with each other, especially ones that mess with the UI and replace elements but for the most part they should all get along.
If I could make a recommendation, that screenshots of the installed plugins be made a submission requirement so that users can see what they are installing beforehand. Some do, most don't.
Not all plugins offer visible changes though. Making it a requirement to include a screenshot, what would you include a screenshot of if your plugin offers no visible changes? For example the m84 motors off plugin works on OctoPrint's back end with no UI interaction.
In the case of your example, where no UI changes are visible, then at least tell the users that "No visible changes to UI will be made". It may not have to be a picture, but put it in the documentation so that at least those of us who RTFM may find it.
As Octoprint becomes more mainstream and gets publiscized, you should conder the users who may not be as tech or code savy. Imagine the number of help or support requests that can be avoided with a few statemetns in the readme or a picture that speaks a thousand words to someone who is just learning.
What you are asking for here is basically a fully curated plugin repository with editorial staff that makes sure that all plugin metadata at all times is kept up to date and as visually appealing as possible. As things are right now, that's simply completely outside of what can be done with the existing resources.
Additionally it would probably also keep a lot of beginning plugin devs from even daring to submit something.
As things are now, the contents of the plugin listings are the responsibilities of the individual plugin authors. And I'd prefer to keep it that way. I wish we had a more dynamic repository that would allow more nifty stuff like rating + comments (which I hope to achieve through integration with this forum) and also updates by the authors without having to go through PRs, but I simply don't have the time to a) develop and then b) maintain & administrate that, so the jekyll based repository we now have it is.
In any case, IMHO keeping the entry barrier low here and living with the one or other slightly duplicated plugin is better than a walled garden approach that discourages people from even attempting to register their plugin.
i'm not that demanding.... i understand what you are saying but its not that complicated.
would you consider suggesting in your submission guidelines that the plugin include pertinent info so that users know what the plugin will look like and what they should be looking for?
Additionally it would probably also keep a lot of beginning plugin devs from even daring to submit something.
I don't know, if having to add a screenshot of your plugin is what stops a developer from wanting to submit their entry, I'd suspect some shady shenanigans are afoot, why do they not want people to know what it does before installing? Creating a screenshot is about the easiest part of developing a plugin, you can even get browser plugins that capture screenshots of stuff.
I know it's hard to actually enforce and I wouldn't expect it to be enforced, but I actually sort of agree on at least on just putting something in the plugin submission template like if your plugin adds or modifies UI elements, you MUST include a screenshot. If no visible changes are made, please make a note of that. and just whatever happens happens, if there's no screenshot submitted then c'est la vie.
In the case of your example, where no UI changes are visible, then at least tell the users that "No visible changes to UI will be made".
I didn't mean having to add a screenshot, I meant having to go through a more editorial heavy registration process. There are some plugin authors out there whose work could potentially help a TON of people but who are self conscious about registering things. I want to avoid to give those another reason to say "ah... nah... I'll just leave it there" by enforcing any kind of metadata requirements on the plugin listing itself.
However, I guess some kind of checklist indeed can't really hurt here. I just added that. While at it I also did something I'd been meaning to do for a long time and added a general plugin checklist with points that in fact should always be adhered to (mostly for safety reasons) - that in fact might now sadly do the exact thing I was afraid of (scare people off), but it also gives me and @kantlivelong something in writing to measure registration requests against which so far was more of an informal thing.
I see what you mean about enforcing things in some automated way like having travis (hates me that's for sure) put up that big red cross if something's missing, having the checklist is good though.
You might want to add one more additional clause:
If your plugin requires the use of external services, and those services are unreachable (say for example a user's internet is down), your plugin must fail in a way that does not cause OctoPrint to malfunction.
r.e. that one plugin that causes octoprint to just not load if the internet isn't connected. I know you're taking steps to help prevent that but it might still be nice to have plugin authors at least try to do something about it.
Good point, did just that. Also added an exception to the "thou shall not install stuff" to make clear that additional python libs installed through setup.py of course are fine.
