Closed Mr-Dave closed 6 years ago
genius3000
commented
6 years ago I did some searching and trialling with different CSS for the menu closing, it didn't pan out well. Anything that successfully closed the menu on click, didn't actually run the onclick function. My thoughts are changing the menu open&close to JS functions. I'll trial this by late next week.
I'll open a WIP pull request tomorrow so it's easy to see any working changes I've commited.
tosiara
commented
6 years ago I have found some incompatible changes in the web API interface, which I probably missed. Can someone provide a bit of information, because this may break existing workflows for users, like in my case. Previous version:
$ curl http://localhost:8080/0/
<!DOCTYPE html>
<html>
<head><title>Motion 4.1.1+git20180130-0f36002</title></head>
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<body>
<a href=/><– back</a><br><br>
<b>Camera 0 -- Thread 0 -- motion</b><br>
<a href='/0/config'>config</a><br>
<a href='/0/action'>action</a><br>
<a href='/0/detection'>detection</a><br>
<a href='/0/track'>track</a><br>
</body>
</html>Latest master:
$ curl http://localhost:8080/0/
<!DOCTYPE html>
<html>
<body>
<h1>Bad Request</h1>
<p>The server did not understand your request.</p>
</body>
</html>Correct, that plain page listing those links is no longer there. The change/write config is done more within the UI now than before. I'm honestly not sure if the ability to change values by direct URL is entirely there though.
/detection/(start|pause) is still available and a few other options I believe.
Can you be more specific with what is missing for your use-case? Status of something, config raw list, etc?
Mr-Dave
commented
6 years ago The functionality is still there to revise the Motion parameters as was done in the previous web interface.
As @genius3000 indicated, this page was included because it is not setting anything. It was a navigational page. The other pages which come to mind that are not in the html interface are get, list and status. The option of 'list' is however available via the non-html configuration option.
tosiara
commented
6 years ago I'm missing http://localhost:8080/0/detection/connection which was used to monitor camera health
genius3000
commented
6 years ago Ah that's probably a good item to have yet (connection). Though I would propose renaming it to status.
I've done up a quick copy of the connection code from the previous web interface into the current. Then when I basically duplicated the function for text and html it raised the question, "Does this need a html version; Or should I just allow the html (as per config) version to use the text version?"
Further thoughts, should we allow the text site to run alongside the html site and/or offer the same "API" type text commands regardless of text or html chosen. Just thinking that some people may enjoy the html display and quick edits, but want to utilise the "API" of connection status and config listing.
Mr-Dave
commented
6 years ago I think running side-by-side wouldn't be right. It adds new threads, new ports, etc. There have already been more than a few comments that there shouldn't even be either of these. So we need to focus on it being a "simple" web interface. I'm also thinking that is it possible that users could just change this on the fly anyways by issuing a command to change the configuration option temporarily.
One note is that connection and status were used in the previous interface with different purposes. The former was whether the camera was working and the latter was whether it was in pause mode. I agree on just using status and that both items should be reported in the text version.
For the html version, this is what was indicated in the code comments. Perhaps we should have a box that shows up for 3 seconds or so below the configuration and tracking drop downs that gives status information? Or perhaps another dropdown like configuration and tracking that shows the status? As indicated above with the "simple" comment, I think that it shouldn't be any new page and should be just part of the main page that may or may not be displayed.
genius3000
commented
6 years ago Ah, good point on the previous connection vs. status, I missed that. So yeah, definitely want to show both. Apologies for my poor wording with "alongside", etc... My thoughts were more of allow both dependent on URL used (ie, append /text/ or /api/ for the raw, scripting usability) rather than a separate port (and thread). That brings complexity to parsing though.
Carrying on with your thoughts to the HTML display for this, I would think maybe a onhover tool-tip over the camera name or small text below it with detection status would be nice and simple. I'm not really for the timed display, rather have it there/available at any time (on the certain page). Now this is thinking only of a single camera page; the All page would require something a tad different to accommodate a number of cameras.
I'll do some playing around with it and see what appears decent and try to post some screens.
tosiara
commented
6 years ago I wish we could re-implement same url api interface for compatibility with old users and deprecate it slowly (like we do with renamed config params), so everyone has time to update to the new api
genius3000
commented
6 years ago I mean, right now this is only in the "stable"(ish) development branch. The latest release still runs the webhttpd version.
It would be easy to have connection also provide the new status output, though it would have a slightly different output. That would make backwards compatibility in this case a tad messy.
I personally haven't used the webcontrol for much outside of debugging/testing but it's use-case (in text form) is quite apparent lately and I do believe these concerns need addressing before a release with this in it. To be clear, I'm not putting down this new WebUI, it's cleaner code, easier to work with, and a nicer HTML interface; just the text version needs to maybe re-gain a function or two from the previous.
j0nson
commented
6 years ago I'd vote for all functions from the old text api interface to be included in the new version. I use it exclusively for programmatic control of Motion, and I know others do as well. (I just updated one install from git master, and was surprised they had gone away)
Mr-Dave
commented
6 years ago I got this Matt. Programmatic access will be via the text option.
tosiara
commented
6 years ago I have created an item to track security issues in the new web UI: https://github.com/Motion-Project/motion/issues/709
Mr-Dave
commented
6 years ago For those interested, I will be investigating / pursuing the use of libmicrohttpd for all the web processing. Those with experience with the lib are invited to contact me to facilitate its incorporation.
Mr-Dave
commented
6 years ago A PR has been created that implements the webcontrol via the libmicrohttpd library for review and testing while documentation is revised.
Note that the library will not be implemented for the stream URLs. It is anticipated that the existing streams provided via unique ports will be depreciated and instead the streams will be provided by specific URLs from the webcontrol port.
Mr-Dave
commented
6 years ago The latest commit to implement libmicrohttpd for streams has been pushed to the PR. (Additional documentation changes are forthcoming)
The commit includes:
The legacy code and associated parameters will be removed before the next version of Motion is released. Included in the removal/depreciation will be the entire stream.c module, the configuration parameters of substream_port, ipv6_enabled and stream_motion as well as stream_preview_method 3 which is used to invoke the legacy code.
The following are samples where 8081 is the stream specified in motion.conf and 8082 & 8083 are ports specified in the camera.conf files. `
The web interface currently has a few issues related to the CSS/javacript
- [x] Help button is not aligned on all devicesC related enhancements include:
[x] Add CORS functionality to the web interface.
[x] Add authentication methods similar to streams.
[x] Use DEFINEs instead of hard coded numbers for memory sizes .
[ ] Revise documentation to indicate URLs and actions available.
Pull requests resolving issues are preferred but providing a gist with just the revised HTML and javascript are also very valued to resolve the issues. (Make sure to redact the IP addresses that will be listed in the javascript section of the page)