- User Since
- Dec 30 2014, 9:08 PM (224 w, 4 d)
Feb 20 2019
Flow of daemon initialization and processing (WIP):
Feb 18 2019
Preliminary format, current value will be supplied by daemon before sending data to WebUI:
Reference for infinity slider: https://github.com/solodev/infinite-carousel
Feb 6 2019
Yes, consistency, people should read the mentor page also, it's about making binds, so it's not totally unpersonal interaction there
Feb 5 2019
Feb 4 2019
Feb 2 2019
First visualizer preview:
Jan 22 2019
Dec 19 2018
Adjustments to the daemon are done, see comm packet. Also added digital gain and reworked analog gain.
Dec 11 2018
Just a quick update, tested the daemon with web UI and it works great. Of course current setup is still not finalized and daemon runs as app, so it can be killed directly, but "analog gain" setting works fine (done some test snapshots). Next step will be some adjustments to the comm packet, so we have dedicated command parameter for get/set (a bit like REST), so the part of splitting "set_gain" to check the command will become obsolete and the code easier.
Nov 18 2018
Will check it in the next days, have no time as another work travel is on tomorrow.
Nov 17 2018
Wouldn't omit the other camera projects that much, just move them to some area, like "Inactive projects".
Nov 10 2018
Did just few adjustments to web-remote, it communicated almost right away with the WSServer and daemon. Noticed 2 things which should be adjusted:
Nov 1 2018
Maybe this one is better -> https://github.com/ygoe/msgpack.js also consider gzipped versions, where your 50kb file is only 14kb big.
Oct 25 2018
Just as a reference for the future: Usually our JSON packets will be very small, but if we consider to sent larger packs in the future, like restoring some user profiles (no point to sent individual settings, if there are a lot of cahnges) or when receiving the response with all available stuff in the camera (which i expect to be rather big), then we could consider to use MessagePack, to reduce the size -> https://msgpack.org
Oct 24 2018
Have added simple eslint config with settings i'Ve already mentioned before. Don't have any other special preference at the moment.
Is the riot compiler JS still required? As currently pre-compilation is done by gulp.
Dev VM is planned for UI development in first place, then i hope to move daemon to another repo and also place it there, for comm tests.
Nothing to be sorry about, just normal development cycle. Preparing the VM currently, which will hold the web UI dev environment. It consists of Manjaro (XFCE) and Atom.io mainly. Will try to add some plugins, like eslint, after that we have to do a short discussion about code style, e.g. semicolon yes/no, single ' or double " quotation marks for strings and so on. Have my own preferences, but wanted to talk to majority about it.
Please check the code, getting unexpected token "<" in browser.
Oct 23 2018
Then a new repo please, with commit rights for us all. You could upload latest version, so Francis can commit his changes over it, then we can inspect the differences. I've adjusted his code a bit, as showcase for Browsersync stuff, but not very much.
Should we start separate repo for it, and add as submodule to beta-software one later? This would allow to do things in parallel, like independent CI builds.
Oct 22 2018
Here is the version with browsersync support. Lost my websocket adjustments, but there were only few, which is not that tragic.
Nah, not gulp serve, but browsersync. It reloads HTML page on the fly, when it detects changes to HTML or JS files. Also you can stream CSS changes, without reloading the page, which saves time. Also you can adjust it to compile and then reload on changes to Tag files, as an example. Really nice stuff, using it when i can for web development, latest one was development of a Drupal theme, done with this live preview. See pcb-aoi apertus repo on Github for an example.
Adjusted UI code a bit, so it would send correct message on reload, to get available params. Also adjusted websocket server processing, so the response will come back with real data from daemon. Will try to do final tests today, before uploading it.
Oct 21 2018
We can for sure embed it in a JSON file on the camera and send it together with other stuff back. Will resume to inspect your code in a moment, as i want to get exactly this part of comms done, before proceeding with adding parameters.
Oct 20 2018
No problem, adjust it to your liking, just assisting with some infrastructure. Websocket has connected, after my adjustments, see the code, but haven't got much further, as it expects the JSON database. Will try to adjust it, so it actually tries to retrieve it from websocket server, as i'm not sure, if we should maintain separate JSON config file or not. Current plan is to provide it dynamically by daemon, on request.
Oct 19 2018
Improved a bit and fixed small problems, also added build.sh.
My proposal for GULP adjustments, started to implement, as i wasn't sure how to debug riot.js without precompiling:
Oct 18 2018
Yes, but currently no time to fix it. Will try in the next days, if some spare time is there.
Oct 14 2018
@Francis: Do you need some assistance for the setup? I'm usually using gulp, but grunt also shouldn't be a problem.
Have hoped to do it without a server, as it should be self-contained later. The plan, which was created by another user (Task T937), is to send the whole app package to the client (e.g. smartphone) on first call. This would allow to avoid the need for a web server on the camera and spare resources.
Oct 13 2018
@Francis: Tried to execute your app, but the problem is, that it relies on some stuff, which throws cross-domain errors and refuses to work. Also the font shouldn't be loaded from internet, but from a sub-folder.
Oct 10 2018
Thanks, will check it, but also try to connect your app to the real websocket server from the daemon project.
Oct 7 2018
@Francis: Have committed adjusted daemon version, haven't tested websocket server yet, but will try to do so using your code. At least to see, if responses are coming back to it.
@sebastian: Will try to add some parameters from your list, as example.
Oct 2 2018
Could it be spam? As i don't see any purpose for 3G/4G in a camera.
Oct 1 2018
Current plan is, to get things up and running sooner, to use manual string conversion (docs will follow), as we use JSON and flatbuffers. Later it can be extended. Another point is, where i'm not sure about, but will follow for now: to set and get things, the parameters should be prepend with "set_" or "get_", e.g. "set_gain" and daemon selects correct handler method. Other approach to this, would be a path of REST, where the command is set explicitly, e.g. for JSON: command: "set", parameter: "gain".
Sep 30 2018
No problem, trying to help when i can, so we get simpler camera control soon, as many people are afraid of terminal usage, which can be confusing sometimes.
hi, daemon is being adjusted currently, so it responses correctly to the frontend. Following list should cover your questions:
Sep 16 2018
Adjusted behaviour on the test node, please check IRC logs, so i don't have to post link here for now.
Sep 12 2018
Which IDs are involved? Can we generate them as hashes, automatically?
Just out of curiosity: Won't this file be too cluttered after defining multiple pages and related controls? Could we use multiple files, like one per dialog/menu, in that case?
Aug 15 2018
Aug 9 2018
Added storing of last directory, when file was opened. Cannot reproduce other problems (Manjaro, XFCE).
Jul 5 2018
Possible framework, as replacement for ImageMagick: http://www.graphicsmagick.org
Jun 19 2018
- Curly braces should be always placed, even for single lines in if()
Jun 11 2018
Very good video!
May 22 2018
May 18 2018
Done. RESTServer part of the task is obsolete.