Optionally disable blockly

[ArendJan]

@Ciliaclaij had a nice question on how to disable blockly from Finland

[ArendJan]

How to permanently disable it for now:

in /usr/local/src/mirte/mirte-web-interface/vue-frontend/src/views/Programming.vue:

• comment out lines 28-32 (button blockly) ( at end )
• comment out lines 48-51 ( blockly screen part )
• change line 107, "blockly" to "python"

diff --git a/vue-frontend/src/views/Programming.vue b/vue-frontend/src/views/Programming.vue
index 0d57fc7..7b5b2ba 100644
--- a/vue-frontend/src/views/Programming.vue
+++ b/vue-frontend/src/views/Programming.vue
@@ -25,11 +25,11 @@
                 <div class="text-black p-2 h3 m-0 layoutbox-title w-100 background-secondary">
                   {{ $t('main.programming') }}
 
-        <button v-bind:class="isBlockly?'code-active':''" class="btn btn-outline-light mr-2"
+        <!-- <button v-bind:class="isBlockly?'code-active':''" class="btn btn-outline-light mr-2"
             @click="setLanguage('blockly')"
         >
            {{ $t('programming.blockly') }}
-        </button>
+        </button> -->
 
         <button v-bind:class="!isBlockly?'code-active':''" class="btn btn-outline-light mr-2"
             @click="setLanguage('python')"
@@ -45,10 +45,10 @@
                       </div>
                 </div>
                   
-           
+<!--            
                 <div v-show="isBlockly" class="h-100">
                     <Blockly :visible="isBlockly"/>
-                </div>
+                </div> -->
 
 
                 <div v-show="!isBlockly" class="h-100">
@@ -104,7 +104,7 @@ export default {
     Codemirror
   },
   data: () => ({
-        language: "blockly",
+        language: "python",
   }),
   methods: {
         setLanguage(language) {

Rebuilding app

. /usr/local/src/mirte/mirte-web-interface/node_env/bin/activate # . is same as source
 cd /usr/local/src/mirte/mirte-web-interface/vue-frontend
npm run build
deactivate_node # at the end

[mklomp]

@Ciliaclaij (or @ArendJan): could you elaborate a bit on this. I can imagine having a setting on disabling blockly, but not sure what the issue is with having both.

[ArendJan]

I think that having an explicit button to convert Blockly to Python could be nice instead of just overwriting the current Python code. What we could also implement is that it remembers what tab you were on, so it doesn't switch back to Blockly on refresh (and delete python code).

[mklomp]

A, ok. So the issue is that on a refresh the page defaults to blockly, and not the view you were working in (ie python). I think we should stick with overwriting the python code though. Especially since a nice way to get from blockly to python is: blockly -> blockl&python side-by-side (we not have that yet) -> python.

So I think the two things are:

1. remember which tab you were on (bug)
2. add side-by-side version (feature)

[Ciliaclaij]

Actually the reason is different. A teacher wants to use the webinterface for their course, but they don't want their students to be able to use blockly. Biggest reason for using the web interface is easy access to sensor values and the control panel

[mklomp]

Ok, that indeed is yet another request ;). Lets see if we could think of a solution without rebuilding a separate image. Not sure, would just having this as an option in the settings be enough (easy to change by the student)? Or should it be for example an environment variable when starting the UI (harder to change by the student)? Or even something else.

[ArendJan]

we could add a button to the web-interface to disable blockly from then on, store it on the robot, and if you want to change it back, you need to ssh into the robot

[Ciliaclaij]

I have just tried the above instructions on a mirte and cannot get through the rebuilding stage as I get a JavaScript heap out of memory error.

The more 'permanent' solutions sound better. I think a 'not to easy to find' solution is better as students then won't find the easy way out

Now I think of it. Let's say someone wants to perpare 50 robots for a course, it would be nice to not have to set this manually for every robot. But not sure how your suggestions actually work in that sense

[mklomp]

@ArendJan : That could indeed be an option. But as cilia also mentioned, we need to take into account multiple robots. I think that should/could be done via the extra partition feature we are still considering. When doing this we should also need to implement the same feature (and preferably in the same way) for the MIRTE Basic/micropython.