Load questions from file and display on GUI (Dynamic GUI)

egeldenhuys commented 7 years ago

It would be ideal if Target Life can modify their questions and make simple interface adjustments without having to recompile the source code (Do you even compile Electron Apps?).

Feature Description

Allow Target Life to change the questions in the interface without requiring knowledge of the internal structure

This can be done by defining the interface in an JSON or XML document. We might also be able to give them access to our HTML interface files depending on how Electon works.

Example:

Tab Name
 - Input Field
    - Input ID
    - Question Title
    - Textbox Type
 - Combo Box Container
    - Input ID
    - Max Checked Items
    - Options: [ A, B, C, D, E...]

How to get updates to client?

First get a working version, then we can integrate into FireBase and figure out how the versioning will work.

Functions/Tasks

Convert client documents into format that can be easily parsed (Markdown)
Load questions from disk
Display questions on GUI
- Define format for the data on disk (Need to create the GUI based on these files)
Define how to link user responses with the data. (If bob enters text for Question A, next time we need to be able to load his response and display it under Question A)

egeldenhuys commented 7 years ago

Currently working on creating a dynamic GUI

egeldenhuys commented 7 years ago

Has anyone made progress with the the dynamic GUI yet?

egeldenhuys commented 7 years ago

So I have the following:

    gui = require('./gui.js')
    container1 = new gui.CheckBoxContainer('container_1') // container_1 is the id of an element
    container1.appendItem('Item 1')

How do I use this in master? @Quantum-Sicarius

egeldenhuys commented 7 years ago

I will expose the HTML elements through the GUI API to make it possible to style the elements.

This way the style is separate from the functionality.

Example:

CheckBoxContainer.checkBoxList[0].labelElement.setAttribute('class', 'white-text')

Using the same type of abstraction we can implement our own SPA framework.

I would have created the same abstractions even if we were using Qt.

egeldenhuys commented 7 years ago

I discovered the wiki does not include all the GUI elements. I will be importing them from prothesis-1

Quantum-Sicarius commented 7 years ago

I am concerned that we have put ourselves in a bit of a corner now. Our order although logical (front to back) may be blocking us. We should have started by looking at how we are going to save the information (Key value store) for elements. Basically if we add dynamic new elements we need to produce a unique id for each element to represent the key. We need Objects that contain the information:

UUID: │ Element name (eg Checkbox1). │ Element value (eg true).

So basically we need a sane way to know each unique GUI element and we need to be able to relate that to other instances of our app. (We need integrity across all our app instances. eg Checkbox1 is checkbox1 for all our instances.)

Quantum-Sicarius commented 7 years ago

Reading through the @egeldenhuys code I have a few concerns. How do we say limit the amount of check boxes that may be ticked? I like the markdown approach because it is really simple, but maybe it was the wrong choice. How are we going to implement things like limits without making a ugly header?

Maybe we should consider something like https://github.com/toml-lang/toml (Basically just a nicer JSON) Then we create our own "GUI language":

[panel]
name = "Roles"
    [panel.checkboxgroup]
         name = "checkbox1" # logical name
         uuid = "d131dd02c5e6eec4"  # unique id should be like a hash sum of all values.
         limit = 4 # Limit to 4 checked max.
         [[panel.checkboxgroup.checkbox]]
         name = "Analyzer"
         tip = "You are good at resolving..."
         value = true
# individual checkbox
         [[panel.checkboxgroup.checkbox]]
         name = "Artist"
         tip = "..."
         value = false 
# individual checkbox unchecked.

This can easily be converted into JSON:

{
    "panel": {
        "checkboxgroup": {
            "limit": {"type" : "integer", "value" : "4"},
            "name": {"type" : "string", "value" : "checkbox1"},
            "checkbox": [
                {
                    "name": {"type" : "string", "value" : "Analyzer"},
                    "value": {"type" : "bool", "value" : "true"},
                    "tip": {"type" : "string", "value" : "You are good at resolving..."}
                },
                {
                    "name": {"type" : "string", "value" : "Artist"},
                    "value": {"type" : "bool", "value" : "false"},
                    "tip": {"type" : "string", "value" : "..."}
                }
            ],
            "uuid": {"type" : "string", "value" : "d131dd02c5e6eec4"}
        },
        "name": {"type" : "string", "value" : "Roles"}
    }
}

This is a lot easier. It includes logical state and we can parse it easier into other formats. If they can not edit this then they should not be editing it at all. This leads me to the idea I had. I wanted to build an in app editor, you have some buttons that just can add new elements on the fly.

CDuPlooy commented 7 years ago

I'll have a look at the code again, adding limits shouldn't be hard, we have a list of check boxes so counting the amount that have been checked is trivial.

I also don't think that if the person can't be editing something they shouldn't be editing it at all; with that reasoning nobody should be writing html. I'd prefer a simpler approach to the UI from the users perspective; maybe we should implement both and ask the target life ; see if they are able to work with the json Vs the markdown.

Sent from my Xiaomi Redmi Note 2 using FastHub

Quantum-Sicarius commented 7 years ago

@RagingGrim we should be able to just go around counting things but that just feels like a work around. The problem is we are losing flexibility to the point that it is useless to edit the files. Then again they will probably only be changing one line or a sentence. I want a decision to be made ASAP so that I can help create a plan for state.

CDuPlooy commented 7 years ago

Evert is not working on this during the week as he's already put in the time ; I'd say try calling him but I don't know if he has his phone with him.

Johan is not at home either I believe. Not sure about Charles. We probably won't be able to make a decision about this anytime soon;

As it stands I don't think our approach is any less flexible. I'll have a look at toml in this context and decide how I feel but again we might wait a while for the others.

Sent from my Xiaomi Redmi Note 2 using FastHub

egeldenhuys commented 7 years ago

@Quantum-Sicarius For limiting the checkboxes, we can disable all checkboxes that are not checked once we reach the limit. This can be implanted in the container.

egeldenhuys commented 7 years ago

@Quantum-Sicarius With assigning UUID to GUI elements: this time around I wanted to avoid manually assigning ids to elements. In total the markdown contains roughly 1000 elements.

We can probably have an intermediate step of assigning ids.

egeldenhuys commented 7 years ago

Functionality is now in master

prothesis-software / prothesis-2