Did just few adjustments to web-remote, it communicated almost right away with the WSServer and daemon. Noticed 2 things which should be adjusted:

Maybe this one is better -> https://github.com/ygoe/msgpack.js also consider gzipped versions, where your 50kb file is only 14kb big.

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

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.

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.

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.

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.

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.

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:

Yes, but currently no time to fix it. Will try in the next days, if some spare time is there.

@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.

@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.

Thanks, will check it, but also try to connect your app to the real websocket server from the daemon project.

@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.

Could it be spam? As i don't see any purpose for 3G/4G in a camera.

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".

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:

Adjusted behaviour on the test node, please check IRC logs, so i don't have to post link here for now.

Fixed.

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?

Obsolete

Obsolete

Added storing of last directory, when file was opened. Cannot reproduce other problems (Manjaro, XFCE).

Possible framework, as replacement for ImageMagick: http://www.graphicsmagick.org

• Curly braces should be always placed, even for single lines in if()

Very good video!

Done. RESTServer part of the task is obsolete.

Use HTML email validator for that, as normal one is very picky, but not everything is allowed in the emails, see GMail docs for example: https://developers.google.com/gmail/design/reference/supported_css

Done, build passes after adjustments. Needs maybe some meaningful tests at the end, but for this new task should be created.

Created new footer as replacement for phplist one, see general newsletter thread for info.

Added hyperlink to logo, adjusted "here" URL.

Finally restored the page again, not pretty, but fiducial search is working and the image is unwarped.

Cannot open it without logging in or subscription.

Duplicate to T989

Don't you think there is a bigger security problem when allowing to run websockets permanently in daemon? Also that was a reason for separation of daemon and server. Daemon should just have slim layer, like flatbuffers, for communication. This would also allow different types of servers communicate to the daemon, without opening security holes.

Connection to daemon is done by UNIX domain sockets, then flatbuffers package is sent over it. Split is intentional, so we can deactivate them separately (was asked by @Bertl).

Correct cmv_hist3 link: https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/cmv_tools/cmv_hist3

We can test by replacing Pistache by libwebsockets, but it takes some time (maybe on weekend), as currently preparations for GSoC and my packing for move to new city are ongoing.

@jatha Have you set Travis CI up?

As a new Beta is finally connected to the server, i could test again if i can finally set gain through daemon. If it works, then more usage cases can be implemented and tested. As it is necessary before we know what we need to supply to the camera, but most work should be done by daemon, also using pre-defined (stored in binary files) stuff like FPGA bitstreams.

No complete reference yet, as it was created while developing. Have no direct access to the hardware, so it takes more effort to test.

Yes, looking often into Lab and IRC.

There is a thing missing, which i forgot to tell. REST sends a JSON package, format is described in https://lab.apertus.org/T865.

Logs from LinuxMint 18.3

Aha, so you want to risk legal issues? VSCode is widely accepted, even by Linux community.

To bypass problems with licenses, you can use VSCode, which has a ton of plugins for different areas, also Node, Vue and so on.

Will do it later, if new commits are still not working, am at work now and cannot access my private machine.

JS was enabled, but browser refused to apply a CSS file with cryptic name (seems like hash). Am not new to web development, doing it daily in my regular job (although it's GWT and Java mainly).

A server was used, which was always sufficient for web development. Browser refused to apply CSS, because of security measures.

Using Windows, npm runs through, at least no errors while getting packages. But the HTML page is completely blank, console output in dev tools is showing several resources with 404 and browser refuses to apply the CSS file. Could you take a look, please? Maybe a fresh VM to check if it is possible to build and display the stuff?

NPM is just for the build with gulp or whatever. Device would get slim version of the page, pre-processed by NPM, less, uglified (if performance would be better) and minified.

Local storage data binding through vue.js would be great to have a central place. Seen that there is a npm package for that.

Try it. JQuery is not a problem to remove, as it was used more for AJAX requests at the beginning. Does vue.js suppport two-way data binding? What about templating feature, by separating chunks into other html files?

Downloading fine here. Speed significantly slowed down in the middle, but finished fine, after accelerating again.

@sebastian, here is the test archive, cannot send it per mail:

The ball is on your side. Implement something which fits the requirements and we can test it on the Zynq, to see how it behaves.

It went not well, while GSoC2017, without going too much into details. So i've resumed the work on the daemon, REST server and GUI. The goal is to get rid of scripts to get performance gains. Don't underestimate it, it's an embedded CPU, resources are sparse. There is a reason why C++ was used.

If i remember correctly, then most of this things were discussed with Herbert for the daemon, which was a task for GSoC2017. If you can get it through bash script, fine, but i'm rather sceptical about the performance. Surprise me.

It is planned, but wasn't done yet, as we have lack of people, who are involved in practical way.

Which VM image?

Daemon was started, amongst other things, to remove the need for that folder at some point in time. Feel free to implement something, which could replace current approach.

The goal is to avoid to use bash which spawns a lot of threads and to have a central point which should do the configuration and initializations.

Basic infos about it are here: https://wiki.apertus.org/index.php/Control_Deamon

I think there is a misunderstanding. Node.js is used by me for current tests of PCB inspection, if this software will be used, then on a normal server. The camera has an embedded processor, so we won't use Node.js there. Won't ditch C++ also, because of performance, small footprint and rather simple daemon implementation.

As the software grows, it maybe a good point in time to split it in sub-modules, so the things do not interfere. How would we split the things and keep track?

Fetch API or Axios were considered to replace AJAX stuff from JQuery. Some tests done, but not added to the main code.

What is your experience with the performance? What about application size?

Ah, you want to use it like the R&D at my company. They have also implemented an Android application in that way. But a simple WebView app for Android would be sufficient, in my opinion, maybe with settigns for IP address of the camera. Done that already at work, as we had no requirement for Cordova for customer project.

Current state of testing PCB inspection:

Heard of vue.js before, but haven't used it. What PHP thread do you mean? Currently we do not involve PHP at all for that part of the software. There is a C++ daemon and REST server (also a Go version exists, but not maintained currently) which are used to communicate forth and back.

The general idea is to use a smartphone (but later also tablet or laptop) to control the camera. Sebastian did some mock-ups of the UI before (current implementation is a bit different) -> https://wiki.apertus.org/index.php/Wifi_Remote

At the beginning we wanted to do something with plain JS, but as it is more comfortable for user to have single-page app, the need for more advanced things arose.

Then try it this way first, can optimize later.

I would suggest to avoid JS, performance could possibly be low, but OpenCV sounded great. Just had no time to look into that lib. Also TensorFlow could be interesting, as it uses AI.

Ripple Simulator is also really well simulating mobile device of different kind.