and pull the repo again - there seem to have been a few files in the dist folder that weren't added to the repo yesterday

ok... what security measures? have you enabled javascript?

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

PR merged, thanks!

@RexOr Note that the symbol you are using as 'beta' is most likely an sz ligature (or sharp s) and not a greek beta as the beta does not have a serif or swash at the bottom while the long s from sz has.

Good man. There's a new logo pack presently building.

Old (535 kb):

I am using this logo for the loading image on the vue.js version of the WebUI. So I fixed it (in my repo) but also forked the repo and created apertus_Logo_Pack_V2.2b.tar.gz with the fixed logo. I just made a pull request from our fork.

Just thought I would point out that the AXIOM logo in the logo pack as provided at github is cropped at the bottom:

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 ;))

These two symbols are good for consumer trust in the project. Having beta-testers testing it around the world and confirming that it doesn't cause problems for them is also a chain of evidence that suggests due-diligence.

CE is mandatory for certain classes of equipment which we might or might not fall into, depending on the setup.

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

Many thanks!

That also reflects what we have learned so far: Going to a lab and making measurements that show you are in compliance with CE is only for you to have proof in case you need in court.

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

The amount of files on the fileserver is overwhelming, but the current versions are linked in the wiki, so i was able to commit them to Github.

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

Yeah, well of course this is something that the industry wants you to do. Considering the number of Betas out there, maybe just write up a simple declaration for each country where the product has been tested with a super official looking checklist, get it signed by the "tester" and someone from the organization.

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