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

https://www.crowdsupply.com/krtkl/snickerdoodle

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 mention of a focus pulling device, external touchscreen and toast messages (android app specific) confuse me...

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

My understanding of HTML, CSS and JS is that it is possible to run it everywhere - in the browser, in apps or even possibly on a touch-screen layer. Toast is not just for Android - it is a method of informing the viewer.

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

Do you think it is a viable model? Is it totally stupid? Is the wording too strong? Are there existing specs that I should have looked at first?

To get to a point where I can contribute, I am trying to identify the current state with an eye to future use using modern toolchains and well-known patterns for low-powered machines and distributed computing. (Yes, offloading the interface to a different device is distributed computing.)

As an external contributor it would be very helpful to have some onboarding, i.e. know with whom and which groups I should be working. Something like a contributor starter kit would be awesome. (Here is a VM, don't use MALLOC when testing, these are the git repos, here is your contact for X feature... etc.)

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

The next steps are adding more interface elements like radiogroup like selections and implementing gulp so we can split the different "pages" in the menu into different files to improve overview:T933
There are also some other tasks that are still pretty much open like T931 or T932

For me the best way of helping/contributing would be to participate in small steps like the above tasks rather than start again from scratch or rewrite everything. This is very much an iterative process: we make small improvements here and there then evaluate if we are happy with it, discuss ideas and then make small changes again.

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

Working spec document

hey everybody,

i started working on a UI System with Websocket and it needs still a lot of work but i can Communicate with a Server and update values.
For me the Question came up what type of data and commands are existing? (example: battery state, power, iso offset....)
and how is the data defined? (example: On/Off, List of values, range 0 to 100.....)

Current Code can we viewed on: https://github.com/Mandrake0/Apertus_Configurator
Test Server (bad code btw): https://github.com/Mandrake0/Apertus_Demo_Server
Here is also a Video of the bootstrap version i made a change to mini.css saved about 60-70% of code size: https://vimeo.com/288860500 Password: apertus

The current Setup uses a json file (data.json) where the pages / camera functions and diagrams are defined.
as a test it's okey but i need to change the data structure to make it more cleaner. here i would like to get some input!

My current json setup:

Define a Component

{ "_id": "id_01", "type": "component", "name": "ISO Offset",
        "class": "component",
        "value": "1/100",
        "defaultValue": "1/100",
        "selection": "1/10, 1/50, 1/100, 1/200",
        "command": "no command"
    },

Define a Page

{ "_id": "id_06", "type": "page", "name": "Image",
        "pos": "0",
        "components": [
            "id_01",
            "id_02",
            "id_03"
        ]
    },

Define a Diagram / Status

{ "_id": "id_08", "type": "component", "name": "Battery",
        "class": "**diagram**",
        "value": "",
        "defaultIcon": "icon/battery/baseline-battery_unknown-24px.svg",
        "selectionType": "range",
        "selection": {
            "range":[5,20,50,99,100],
            "icon":[
            "icon/battery/baseline-battery_alert-24px.svg",
            "icon/battery/baseline-battery_20-24px.svg",
            "icon/battery/baseline-battery_50-24px.svg",
            "icon/battery/baseline-battery_90-24px.svg",
            "icon/battery/baseline-battery_full-24px.svg"
            ]
        }
    }

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?

Hi Francis

Great to see you are pushing this forward!

@BAndiT1983 it should be possible to do that just the ID must be unique over all files.

i had in the plan to add a drag and drop editor for customizing the interface and functions but that's a task when everything works as expected.
have made for learning purpose a test project: https://github.com/Mandrake0/Riot.js-Formular-Builder
Video: Formular Builder (sorry quality is somehow bad)

@sebastian
you had that request and i need to learn more web coding.

Which IDs are involved? Can we generate them as hashes, automatically?

Your video looks very interesting, it's also of good quality, if you set to 1080p manually.

at the moment the ID is just a unique value (example: "_id": "id_08" ) it could be made with a hash value it doesn't matter for the interface.

ahh maybe later vimeo add the HD verson i just seen a 480p version.

made a small update: https://vimeo.com/289786668

• new interface is working (moved from bootstrap to mini.css)
• searchbar some functions are working but there are 2-3 open bugs
• data handling is now oberservable based

hey all,

my progress in the last two weeks where a bit low because i'm on tour (traveling in asia) and i don't know whats the best way to implement the file specification for the camera functions.

EXAMPLE:

Iso Offset

For the GUI I need:

• ID
• Name
• Type (what is this Object a Input Value / Information / etc.. )
• List of selectable Values
• Icon List (if there are icons for visualisation)
• Default Value
• New Value
• Class (for sorting it into a specified Area this case Image (Image / IO / Recording / Audio / etc.... ))

what does the server need?
I also don't know how many functions are existing at the moment sadly there isn't a list? (for me a quiet important list) :-)

for the Data validation does the backend service this?
is there a GO Demo Server or has that moved to a c++ Server?
https://github.com/apertus-open-source-cinema/beta-software/tree/dev/software/control_daemon/API_WS

hi, daemon is being adjusted currently, so it responses correctly to the frontend. Following list should cover your questions:

• Parameter list is not available yet, but will be created soon, whne daemon is adjusted, then people can start to bring in the requirements for parameters, which leads to further extensions and improvements for the daemon
• Daemon should send a JSON array/list with available commands, when a command "get_available_methods" for module "general" is sent to it (not fully implemented yet), also reworking that daemon part currently, so available parameters /methods can be registered without much hassle there
• Registered methods could also reflect max/min value, default etc., still needs more evaluation
• Icons should be handled by the UI, no need to bother the camera with it, icons should be placed inside pre-compiled web app, which should be self-contained, without the need to request further data from the camera, just websocket request to WSServer
• GO server was frozen for some time, as there was no maintainer and i have no time to handle multiple implementations, in fact it should use the C/C++ lib, also because of performance and smaller footprint (GO executable was rather large after compiling, also compiling on camera required too much memory), so the methods are generalized and use same logic
• What do you mean by class?

thank you for the information.

In T939#15354, @BAndiT1983 wrote:

hi, daemon is being adjusted currently, so it responses correctly to the frontend. Following list should cover your questions:

• Parameter list is not available yet, but will be created soon, whne daemon is adjusted, then people can start to bring in the requirements for parameters, which leads to further extensions and improvements for the daemon
• Daemon should send a JSON array/list with available commands, when a command "get_available_methods" for module "general" is sent to it (not fully implemented yet), also reworking that daemon part currently, so available parameters /methods can be registered without much hassle there

sounds good i wait. if you need some input just ask. :-)

• Registered methods could also reflect max/min value, default etc., still needs more evaluation

in my view it would be nice to have one file (csv or json) with all function with the range min/max / default ....description? so if somebody wants to develop a CLI / native app / desktop app / another web app.... it can use that file and gets all benefits. it could be even a csv that gets optimized to each defined app.

• Icons should be handled by the UI, no need to bother the camera with it, icons should be placed inside pre-compiled web app, which should be self-contained, without the need to request further data from the camera, just websocket request to WSServer

to get the web app working (PWA) it needs a manifest and a service worker. manifest i have done but the service worker is a open task. the icons will be in a font so it shouldn't be a problem.

• GO server was frozen for some time, as there was no maintainer and i have no time to handle multiple implementations, in fact it should use the C/C++ lib, also because of performance and smaller footprint (GO executable was rather large after compiling, also compiling on camera required too much memory), so the methods are generalized and use same logic

ok.

• What do you mean by class?

"class" is more like a classification of that function to a group

btw. thanks for the fast replay

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.

Like i said before, the plan is to provide a JSON data on demand with all available methods per module, like image_sensor, general etc. (the classes you've asked about), which would also hold more information like ranges and such. Format is not fully defined yet, let us talk about it as soon as i have finished the general parameter handling, so we have a base for discussion. On demand, because it should be gathered automatically by the daemon, for certain models/revisions/versions. Static file would require permanent maintenance, when new things are added to the camera, like modules.

sounds perfect :-)
take your time....

I started a google doc so we can collect actual/abstracted potential parameters and possible values/ranges:
https://docs.google.com/document/d/1avhqneK2whvau_XBEGza_ujum8SB4EgMCl6i5aC9e18/edit?usp=sharing

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

If we have a stable system, then i can investigate overloading of handler methods and their binding.

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

@BAndiT1983 there is a simple setup where you can sent some strings to the websocket server on https://github.com/Mandrake0/Apertus_Demo_Server for the testing.

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

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

Edit: Or can we surpass cross-domain exceptions by pre-compiling?

@BAndiT1983 yes there some stuff that i didn't optimzed yet like the icons, for that i need to make a setup.

you don't need to compile (optimize) it it should run just like that. Does it happen also when you use a simple python http server? (you need a http server that serves the site or the browser gives a cross origin error.)
the current version on github should work i also have got a newer version with local icons but i need to investigate more for optimizing it and fix some small bugs.

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.

But i can test with a simple server locally for now. Wanted just to give you the idea of the overall plan.

@Francis: Do you need some assistance for the setup? I'm usually using gulp, but grunt also shouldn't be a problem.

@BAndiT1983 for to make a PWA it looks like it requires a http server the reason is the PWA / Service Worker checks if there is a update or not from the server.

Whats possible:

1. The PWA can be hosted on apertus.org example: app.apertus.org and in the app the camera ip has to be added for the websocket. then you don't need a http server on the camera and all updates can be hosted on app.apertus.org.
2. The PWA can disable/enable the http server on the apertus camera per websocket.
3. make apps with something like cordova

note: PWA is to make a Web APP that can be offline, works on Desktop / Mobile like a normal app and you don't need a installer or any kind of add-on ( cordova ).
it only needs a manifest ( have made one) for define the app and a service worker (open task) that checks in the background if there is a update or not and some other functions.

i will check for gulp... i will come back for your help. :-)

We don't know if camera users will have internet connectivity where they are shooting so serving from apertus.org is not a good idea.
Whats the problem with having a http server on the camera? Its already prepackaged and available. Updates to the WebRemote can be done with the camera firmware.

@sebastian it only needs internet connection when you load the site after that it can work offline. i'm sure most user will test first there setup at a location that has internet.
PWA requirement is a http server (can be a very simple one) and a modern Web Browser the decision if it's in the firmware / internet or where ever is at the moment not relevant and can be solved on a later stage when the server is working.

worst case as example : when there is a ressource limit on the fpga us another MCU example a ESP32 (cost 8-10$) with some free flash it's possible to integrate all there websocket and http stuff and communicate to the fpga with serial.

i'm sure most user will test first there setup at a location that has internet.

You identified the problem yourself already :) -> what about the other users who didn't do that beforehand.

We currently use lighttpd. The webserver runs on the CPU not the FPGA and while resources are of course not unlimited there I don't see any issues of having lighttpd idle along when nobody sends any requests to it.

@sebastian the others don't know that is important to test and understand the equipment. (could tell storys about that! a good hint this was a reason why i support apertus! we lost nearly customer data because we haven't test the memory cards before shooting)

lighttpd sounds good and i know that the zynq has some ARM cores. :-)

I agree that its important to familiarize yourself with the technology but still we cannot punish users who didn't.

What if your smartphone is out of battery and in the field you need to switch to a different one... -> least possible obstacles is the goal.

My proposal for GULP adjustments, started to implement, as i wasn't sure how to debug riot.js without precompiling:

• Put required files into src folder
• Output will be done to dest folder
• JS and CSS can be minified later, by using some preprocessor
• Tag files are compiled through gulp-riot module
• Using node_modules/.bin/gulp, to avoid the need to install gulp globally, later we can add shell scripts to avoid to type this in every time
• If you are interested, then i can upload adjusted code folder

please commit/upload!

Improved a bit and fixed small problems, also added build.sh.

Instructions:

• Install npm, which should also install nodejs and related packages
• Extract attached archive
• cd to extracted folder, run npm install, verify that you are at the root level of it, where package.json is
• Run build.sh to precompile and copy files to dest folder
• Tested with lighttpd on Ubuntu, symlink in /var/www can be created (to avoid user rights hassle), which points to the dest folder -> sudo ln -sfn /home/dev/HTML/axiom_remote/dest/ axiom_remote

@BAndiT1983 thank you! i didn't invest a lot in gulp yet but it looks very simple. thanks

i will add it when i have done some other updates that are currently in the works in the end of next week. hope that is okey for you.

the targets for next update:

• 2 new components (chart & boolean widget) (chart is 50% done / boolean not started yet)
• some small fixes in the css (card definition has now a new design)
• add some missing function in the searchbar (nearly done)
• your gulp setup

btw: did the websocket worked?

current state: F31785

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.

My target is to use indexedDB from the browser to store the data. There shouldn't be a big task to go over daemon (it takes maybe 20-40 LOC to make it happen) .

The question is more if there will be a function to store the GUI setup on the camera.
I would like to integrate interface customisation, favourite selection and other stuff that is not realted to the camera hardware.

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.

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.

Another thing we should consider, and which was already on the TODO/discuss list for quite some time, is the split of beta-software repo, by moving modules to new repos and linking them as sub-modules. This would be more manageable, as modules grow more and more.

I could include browsersync setup in gulp, for live preview/reload and CSS streaming, while developing UI. Anyone interested?

Sound's good and take it easy 😉...
For the UI my view was to have for each data type a own widget and the module maker defines the widget for his module.

The gulp serve would make sense for the development, have seen it in the docs bit not try it out..

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.

Here is the version with browsersync support. Lost my websocket adjustments, but there were only few, which is not that tragic.

Instructions:

• Follow previous instructions about nodejs and npm setup, if not already done
• cd to extracted folder
• Execute ./run_dev.sh
• Browser tab should open with localhost:3000 as address
• Try to adjust some file in the src (!!!) folder, like HTML or one of the .tag, save afterwards, nodejs should process files, according to their type and reload the page automatically
• Try to modify CSS, also just save the file afterwards, browser shouldn't reload the page now, but the changes streamed to it, like new text color.

In case of problems, just give me a note.

i made a update my stuff is still under development but the other part hasn't been changed so gulp should work.
made also all component tag's to a single js file so it looks slowly better in the index.html file and less stuff to load.

Great to see things flowing so steadily here!
Shall I give you commit access to github so you can more easily commit/collaborate on code?

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.

Whatever you prefer.

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.

https://github.com/apertus-open-source-cinema/web-remote created

made the upload, i will also delete my repo in some days.

Please check the code, getting unexpected token "<" in browser.

@BAndiT1983 strage bug the precompile for the .tag files didn't see the end correctly i removed emty space's and it works againe. sorry for that.

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.

When there is a code style guide that you prefer or has been defined it's no problem to adapt it. I'm new in terms of code development and it's my first real code project i'm happy to get inputs to reach a better result.

Is the Dev VM only for the server or do you want also the web-remote development in the VM?

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.

No problem, we can just discuss what's good or bad for the style. My basic preferences are:

• Semi-colon at the end of the line
• Single quotation mark -> '
• As it's JS world, then i'm fine with first brace in the same line

Is the riot compiler JS still required? As currently pre-compilation is done by gulp.

the riot.js compiler is not required can be replaced with riot.min.js (~12KB less) i will do that when i have done the new widgets.

For the style guide do you want to use a predefined one like google js style guide or what ever there are some to select?

Have added simple eslint config with settings i'Ve already mentioned before. Don't have any other special preference at the moment.

Okey thanks i will check that when i have more time.

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

Thanks for the info! We can see whats possible when everything is getting into shape. The only thing what i don't like is the msgpack lib (50KB) in javascript is 50% of the current JS/CSS/HTML files. (<100KB)

I sorry for some delays i'm still on new widgets. I will updated some code for next week.

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

Have seen it, when you compress the src JS/CSS/HTML it's below 30KB (it's even smaller then the react javascript as gzip!). No problem when the time comes we can analyse the best solution. I'm with your idea to optimze the message size as a future task.

I like to have a tiny project even when there are font's and images that makes it big. It takes more time but to develop but on the end it's not overloaded.

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

• Send index back to daemon, it's easier to process than "1/3" or "3/3", in the future we will get an automatic list, so the daemon would know the array
• Add slider control, as drop-down boxes are cumbersome to use for quick settings, e.g. for first tests i would like to use one for gain setting

If we sort out small things, then we can try a test on the camera at the apertus° hub. Will do preparations, to see if the daemon can be controlled from CLI first, although i know that at the moment it has its quirks and ends the connection, as there is no handler to resume waiting when client disconnected.

i changed on the end from the IRC Meeting the data.json for your requirements.

the only reason at the moment that it sents "1/3" is you can sent a custom value over the searchbar! it can be changed.
for the development i was finding it would make things simpler when you also have the option to sent custom values.

i will try to resevate more time so i can make a slider interface or you can use searchbar if it's faster: https://vimeo.com/299272995 ( TAB for selecting top value)

Note: i add from anuejn his files so it uses now npm for running grunt.

slide control
just checked for slide control and seen some solutions but i need to investigate more into it. what i have done is a autoupdate so you don't need to close the modal window and it should be possible to use the arrow keys for change the values (up/down).

@BAndiT1983 made some small updates is it for you now better?

Will check it in the next days, have no time as another work travel is on tomorrow.

small progress can now make a desktop app :-)

In T939#15554, @Francis wrote:

small progress can now make a desktop app :-)

Hurray :D

I think the code is in a stage where it's good for testing on the Camera. There are surly some functions missing but that can be added when the test gives some results.

At the moment i'm on the icon generation for to have only the required icons to be load. Other task are mostly code cleaning and fix some bugs in searchbar.

@Francis do you want a remote Beta account? https://wiki.apertus.org/index.php/AXIOM_Beta_Remote_Access

@sebastian i think it doesn't make much sense for me. I don't know the backend so i could only see if the web-remote works.

In T939#15578, @Francis wrote:

@sebastian i think it doesn't make much sense for me. I don't know the backend so i could only see if the web-remote works.

Right. Bandit will take care of the testing on actual hardware I assume.

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.

Made today a update:

• Iconfont is now generated
• slider in the modal window

Adjustments to the daemon are done, see comm packet. Also added digital gain and reworked analog gain.

made a bigger update.

• Add indexeddb as backend storage
• Updated Websocket
• Add node.js Websocket development Server (very basic)
• create widget-element for next bigger UI update hasn't been much done yet.
• fix bug's and created some more bigger bug's :-)

i think next week i will push some more updates for dev server and client websocket, specialy error handling and reconnection.