Settings dialog to parametrize model in ARE

[deinhofer]

At the moment it is not easily possible to reuse a model for another user. You can just open a model and modify it. This can get very complicated if you have to change many threshold values, event assignments or switch data channels. But this approach is way to complicated for user organizations like Lifetool or for Users themselves.

For this reason the ARE needs a settings dialog that let's you modify some parameters of the model, e.g. mouse speed, threshold values, change some names,... In the case of the lipmouse it would be nice to be able to adjust the "AdjustmentCurve" settings directly in the settings dialog. Additionally it is necessary that the adjusted values in the settings dialog are stored an automatically recovered after an ARE startup. Imagine you indiviudally adjusted the speed value for the mouse, than you also want to have that value after a new startup of the ARE.

To accomplish this, I would like to discuss several approaches:

a) ModelSettings plugin Probably the simplest approach but also not the cleanest one. The ModelSettings plugin would have several properties to describe ONE property of a nother plugin in the model. e.g. settingsCaption="Sipping Settings" propertyKey1="Threshold.1:thresholdHigh" propertyLabel1="Sip threshold" propertyTooltip1="Enter pressure value of sipping to trigger left click" propertyDefaultValue1="230"

This would generate a small Button in the ARE GUI that opens a settings dialog when clicked. The dialog would contain a generic settings dialog with a list of the defined properties. If the user changes a value it could be applied with the method public void setComponentProperty(String componentID, String key, String value) of the DeploymentManager.

Additionally the plugin would use the LocalStorage feature of the ARE to store the set values.

Maybe in a first implementation it would be sufficient to not show the GUI dialog but only store the values and let the user edit the text files.

b) The ACS provides the possibilty to directly select properties of a plugin that should be settable in the ARE settings dialog. This would also need the possibilty to define a verbose label, tooltip and maybe type of input widget This requires changes in the ACS, the model xml schema and the ARE GUI implementation. Seems to be more effort but it would be the cleaner approach.

c) The new WebACS has a mode that let's you edit selected properties in a simplified view? As the ACS could be run in the ARE instance, that settings dialog could simply be a webpage of the WebACS that let's you change some settings and apply them.

Ad David, Stefan: What do you think?

[asterics]

@But this approach is way to complicated for user organizations like Lifetool or for Users themselves.

Modifying the model is not the task of the user organization most of the time. They should make adaptions through the ARE gui designed by the model creator. You can't expect all therapists/nurses/relatives to read a technical ACS model and change connections/insert new components without proper training, technical background etc. The key to reach this people is a well designed ARE GUI and yes you are right, a huge usability problem at the moment is the missing save option of adjusted parameters.

@a) ModelSettings plugin I think thats a good fix considering effort and improvement of the system

@b) This sounds also good but I don't see the big advantage over approach a. Especially if we have the new flexible port count feature implemented, which maybe happens at the next "Chris"mas coding event. It took 28 years to realize where the name comes from ;)

@c) I think that would work very good but I also don't see any advantage over a.

This also leads to the question to port the ARE GUI from Java Swing to the webserver part of the ARE. This would lead to a platform independent, over network reachable configuration GUI of the ARE. I think that would be the best solution to get a platform independent GUI for the ARE which is very important for the future code base of ports e.g. Android, iOS which have no Java Swing libraries available. TOPIC>

Finally: Yes Martin you are absolutely right - we need a way to store and load model parameters during the runtime of a model.

EDIT: commented using the wrong account eldufdo spoke ;)

[ChrisVeigl]

I just want to add: loading and storing model parameters is possible using the LocalStorage service - it can be added to any plugin. Recently I added this features to the Slider plugin (storeValue property) - which is probably the most important GUI element for user-adjustable settings.

regarding the options I also think a) would be most realistic (given the efforts).