Modular and extensible UI framework and ui elements.

2 of n posts

To provide a first glimps into the components, here some code facts:

• ui.js uses 247 variables for code and data.
  
• uiBtn.js uses 90 variables for code, and about 25 variables for each instance.
  
  

The numbers for the slider ui element have not exactly settled yet, but are around the double of a plain button... considering the capabilities, still a very small foot print...

...and this is the actual code:

Tip for best display of code sections without line wrapping : change browser window to the sweet spot where no line wrapping happens.

// ----- pull in dispaly and touchscreen
var dsp, dMod = require("ILI9341"),
    touch, tMod = require("XPT2046");

// ----- pull in ui base and ui element
var ui = require("ui")
      .add(require("uiBtn"))
      ;

// ----- define callbacks (to log ui element id and value)
var cb = function(id,v) { console.log(id + ": " + v); };
 
// ----- define UI (in level 0, so it does not use memory for source)

//   0  1     2       3  4     5    6    7   8
// flgs clazz id      x  y     w    h   bc  fc
//      btn                 ->x2 ->y2         
ui.c(3,"btn","b1"  ,  5, 40,  65,  35,  4,   4

//                    9       10  11 
//                    valObj  cb,  l (label array obj)
//                                 fv tc    x  y  label text
                   , "B_1",   cb,  [15, 7,  13, 9, "RED"  ]);
                   
ui.c(3,"btn","b2"  , 70, 40,  65,  35,  5,   6
                   , {v:1},   cb,  [15, 0,   9, 9, "Y-w-B"]);

// ----- run UI
function onInit() {
  SPI1.setup({sck:B3, miso:B4, mosi:B5, baud: 1000000});
                   // spi, dc, cs, rst, callback
  dsp = dMod.connect(SPI1, B7, B6, A8, function() {
      dsp.clear(); A5.set(); // display clear and back light on
      // connect ui to dsp and display it
      ui.connect(dsp)
        .w(0,0,239,319) // wipe screen w/ background color
        .d() // display all elements
        .di=true; // set display changes to immediate
      // setup touchscreen and connect it to ui
      SPI2.setup({sck:B13, miso:B14, mosi:B15, baud: 2000000});
      touch = tMod.connect(
          // spi, cs, irq, callback, calc (calibration calc function)
          SPI2, B10, B1, function(x,y) { ui.evt(x,y);
          }, function(yr, xr, d) {
            return [ Math.round(xr / -121.44          + 259.70685111989) 
                   , Math.round(yr /   88.90357142857 + -19.78130398103)
                   ];
      });
      if (touch._eRegisterCanvas) { // only in emulation and before listen
          touch._eRegisterCanvas("dspCanvas", 10, 10); }
  });
  if (dsp._eRegisterCanvas) { // only in emulation dev and before drawing
      dsp._eRegisterCanvas("dspCanvas", 240, 320); }
}

onInit(); // development convenience only... not part of final, saved application code.

The onInit() invocation - last line in the code - does not really belong to the application code... but while developing, it is is very convenient, because the system behaves the same way as with saved code on power-cycling but without actually having to save the code and do a power-cycling... ;-)

To understand touch screen related lines 45..47, take a look at recent Touchscreen conversation.

Lines 49..50 and 52..53 are cross development environment related and were a quick (and dirty) compromise to keep the emulating modules application independent... These lines do not belong into Espruino, and that's why they are conditioned and do therefore no harm...

As in above paragraph, emulation shows... but really marginal... and with some smart thinking - or (with some not so beloved) conventions - emulation can become completely transparent.

The code shows how the Espruino code is prefixed in order to run in cross development. Below few javascript lines are the only required entries to precede the Espruino code to run it in an plain html document in a Web browser:

<script src="_emulationConfig.js"></script>

<script>function _eeLoad(eComponentName) {
  document.writeln(['<scri','pt src="',_eEmulationPath,eComponentName,'.js"></scri','pt>'].join("")); }
</script>            

<script>_eeLoad("_eEspruinoJsShim");</script>
<script>_eeLoad("_eEspruinoPicoShim");</script>

<script> // (pre) load emulating modules - emulating code upload to board
_eeLoad("ILI9341"   );
_eeLoad("TouchRD");
</script>

<script> // (pre) load (non emulating) modules - emulating code upload to board
_emLoad("ui");    // ui base (code and runtime data holder)
_emLoad("uiBtn"); // uiBtn (Button)      element
</script>

As obvious, a plain .html file is used. To avoid a Web server, it is all pulled with just file:// protocol from directories which are configured in line 1 - pulled in as well from a java script fragment while the page is loaded... same concept as files are uploaded into Espruino, they get evaluated... and so does the html with embedded code when pulled in by the browser.

Lines 3..5 show this loader that adds javascript on the go, as you see in lines

• 7..8: Espruino ecosystem with emulated board
  
• 11..12: Emulated display and touchscreen modules
  
• 16..17: ui base and uiBtn ui element modules
  
  

I was surprised how well the UI behaves regarding speed - even though the communication with the display is serial... Text (drawString()) still drags its feet - understandably - but all other things are extremely snappy, such as visual touch feedback. I guess it is thanks to @JumJum who recently made some speed enhancement when using the Graphics objects - the 'inner' implementing of the LCD displays...