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

FYI - I updated the README at the Git Repo - and found a couple files that weren't included in yesterday's commit.

You will see a blank page if you just open the html file in your browser - but that just won't work, sorry. You need to serve it (like I said in the message.) In fact, after I finished the build process this is what it says:

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?

I hope it is dynamic enough.

We unified the Control software, its now called "AXIOM WebRemote" (also moved it to the correct folder on github):
https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/http/AXIOM%20WebRemote
https://wiki.apertus.org/index.php/AXIOM_WebRemote

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.

i would suggest using vuex to store the "mutations" within the browser - but be careful with the latest NPM - they botched the release and it is chowning system critical folders - essentially bricking the device. It is only a temporary problem though.

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

Yes, two way is built in and templating is why I suggested it in the first place.

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?

Absolutely. I can look into this while building a git project if you like.

Shall I turn this into a git project with test runner, build instructions and switch out jquery for vue.js?

Did you get the image on IRC?

For the Controller/WebGUI/ControlGUI its currently me and @BAndiT1983 working on it. The current state is https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/control_daemon/ControlGUI
Concepts are here: https://wiki.apertus.org/index.php/Wifi_Remote

So, I know that there is no Loomio decision making process here (our 150 person non-profit in Hamburg - the Gängeviertel - tried it too, with results similar to your experience...) but I still need some guidance from the core-team on how I should move forward and contribute. I can build everything I wrote about in the CONTROLLER, INTERFACE and DAEMON sections, but it is a considerable amount of work and will take some careful planning and integration...

Maybe something related:

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

sorry I meant 403.

503 is not forbidden but service temporarily not available. maybe gitlab has a temproary outage (they sometimes do ;))

Those are GPL v2.0.

Question: I am trying to download this:

@sebastian sorry about the Terminology. (You did although just call it WebGUI and then link to ControlGUI...)

When you say "Controller" do you mean the WebGUI ?
http://files.apertus.org/AXIOM-Beta/ControlGUI/
https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/control_daemon/ControlGUI

I like some of the ideas over at snickerdoodle - especially their app-connectivity. Maybe there are some good ideas over there too...

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

I am seeing two different perspectives here, and just would like to have some clarification - or even better some benchmarking stats. For your information I have done work on arduino, raspberries, Olimex a20-SOM / LIME (including custom flashing of the NAND), Banana-pi and the O-Droid C-1 - so I am VERY aware of paying attention to system resources and the tough design decisions that come with that.

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.

Ok - I've noted what you said @jatha - thanks for the info. Can you tell me where to find the spec for the openAPI and Plugin Modules?

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.

There are some things, that are good to consider, when we build something like this:

• The camera has plenty of resources. When designing something that only works on the parameters, and not on any image data it is almost impossible to design a system that is to imperformant to run on the cam. This means no performance optimisation is needed.
• The software has to work without requiring internet access at all. (in my opinion) I think it would be handy if everything is served from the camera.
• The software should manage the state of the hardware (is the fpga configured? what bitstream should be loaded? what bitstream is loaded? what plugin modules are plugged in?
• New Plugin Modules should be easy to integrate (new bitstrams and new parameter space)
• An open API should be exposed to allow other interfaces (maybe hardware) to be easily developed

please take a look

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

I thought I read somewhere that there is a virtual machine image that I should use to spin up development... Maybe I imagined that.

Which VM image?

Challenge accepted. Can you point me to a resource for a current 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.

Then maybe a single long running bash script with a high priority / nice-value running as a main control interface that listens for changes to the fifo and where necessary modifies the fifo / and non-volatile file-store for use on startup for init and conf...

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.

Gotcha.

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.

Exactly. Going further, you could also allow users to opt-in their hardware into something like a "fleet health check" which would be a pathway to send errors / regressions / heat statistics whatever back to HQ for QA...

As far as the my.apertus.org idea is concerned, it might be worth looking into a scheme that serves unique / registered apertus hostnames on a subdomain with the cert being held on the device.

AND ... you can get rid of the custom C++ code cruft for simple api responses.

if you are already using node.js for socket.io it is perfect because it is a breeze to bind two-way into vue.js...

Yeah you are completely right! Axiom Firmware would be a much better name!
Moreover, I quite like the idea of having repos for each topic (like gateware, web-gui, daemon, configs, ...)

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.

All the PHP is still from the axiom alpha and will be deprecated in favour of the new REST api. (correct me if Im wrong).
Some of your suggestions are already taken care of in the next-gen firmware on github (ie. lighttpd not having sudo rights)

I have to agree with davidak - and go one further:

Sounds cool :).
I think we dont need to optimize for speed so caching is not really important (for now).

The performance for our webapp is excellent - even on mobile. We are using lots of components, routes, icon-fonts, 8 translations and roboto font though. I think for apertus it could be really slim. According to the design mock up you need:

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

We are using in a framework for vue.js called quasar. With one code base we deliver a single-page website, electron native apps for windows, mac and linux and also use cordova for making android and iOS apps. It may be a bit of overkill for your use-case, but if you plan to deliver for more than just phones, maybe it makes sense to tool up at the beginning. That was our decision - and I can say we do not regret investing some extra time early.

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:

cordova would be a build step to make native apps that run within a "webview" container on a mobile device.

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.

One other thing about the designs you linked to, a website in a browser will pretty much always have the OS chrome and Browser chrome at the top. In landscape mode there is a lot of real-estate that goes away. There's probably a way to do that with html5 fullscreen - but that is a part of the spec that browsers / os's have never really gotten right. It will need some testing and tweaking.

And if this seems like a lot to digest, next week I can set aside an afternoon to help you create the tooling and tune the build process in a separate git repo - then you just need to park the submodule in your main repo and you'll be good to go.

Ok. I would highly recommend taking a look at vue.js - its templating features are exactly what is needed here - it has your "ajax" and data-bindings. It is also very lightweight.

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

Before I can really answer that, I would need a really quick 3 sentence explanation of EXACTLY when the users see this interface and on what screens - or even better, a link to the spec page.

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.

In my opinion, until the networking stack and sudoers permissions are hardened in the Beta Software package, any exposure to the lighttpd service is really dangerous...

I can definitely recommend some sort of build pipeline tailored to the final delivery platform(s). Gulp is a great start, but there are also other options. Having a node based build system is very comfortable - but setting it up can be a great deal of work.

Then try it this way first, can optimize later.

I don't think this is application is performance critical, if processing the image take 1 second or 10 seconds doesn't matter much and still saves us a lot of time compared to inspecting each component individually under the microscope.
Using JS would have the advantage that we need to deal with almost no overhead for creating GUI elements and dealing with image rendering compared to qt, etc.

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.

@BAndiT1983 suggested using http://tutorials.jenkov.com/html5/local-storage.html
I will look into that, seem like a good alternative to cookies.