• @Andreas_Rozek - feedback / comments as requested.

    1) definitely a problem with widget bleed through when configuring - I thing the hide unhide widgets functions that Gordon pointed to in
    https://github.com/rozek/BangleApps/treeĀ­/master/apps/widviz will resolve those issues.

    2) Takes a long time to load. There are 1355 lines to load here. When we get the GIT compiler that was pledged from the kickstarter this will probably not be a problem.

    3) When I connected through the IDE I noticed the response was slow.

    ={ free: 6126, usage: 5874, total: 12000, history: 13,
      gc: 506, gctime: 35.98022460937, blocksize: 15, stackEndAddress: 537087280, flash_start: 0,
      flash_binary_end: 582520, flash_code_start: 1610612736, flash_length: 1048576 }

    In this case I think there is a lot to be gained by splitting out all of the settings / configuration code into a seperate apps.settings.js file. That file could then simply load your settings app which on return reloads the clock app. This would split the code into better partitions for maintainability.

    4) I am not a fan of swipe to get a in app config menu. My preference is to go to the Settings app and look under Apps. This is where an apps.settings.js file would end slotting into without issue. The advantage is better partitioning of code and standardisation in terms of where to go to configure an app. You can still invoke the sophisticated UI in your code as your settings.app.js effectively becomes its own app for the during of your configuring.

    5) I found the settings UI quite unresponsive. Sometimes quite a noticable delay between touching a button and getting a response. I think it needs a buzz to acknowldge a touch being actioned otherwise you can end up touching it a second or third time, then these events are queued up. I noticed you are using Bangle.on('stroke'...) and wondered if Bangle.on('touch'...) might work better. I'm not sure, I'd have to experiment to see if it was more responsive. Part of the performance issue might be the extra load on the CPU from the code. I did have some code I used to measure how long functions were taking so I could optimise them, I can did that out if needed.

    6) I think there is a 4th hand type you could get with little effort - namely colour filled hollow hands. These hands have spindles to start with so they wont look the same as the bolted hands if they are filled with colour - and the colour could be configurable or just the same as the second hand color.

    7) I'm still not convinced that updateClockFaceSize() and the override of Bangle.drawWidgets = function () are needed. In the screenshot below only 1 small battery widget is displayed and yet the code still treats the clock size as if widgets were loaded on the bottom. If the code provided advantage then the top and bottom of the clock would meet the top and bottom edges of the screen. Basically the code can acheive the same result and better by examining the values in Bangle.appRect which are automatically adjusted depending on which widgets are loaded. The code can be written in such a way that it does not even have to know that the widget areas are 24 pixels deep. The 3 lines below will acheive exactly the same result to within 0.5 of a pixel. This save 100+ lines of code and widgets all display quite happily taking on whatever theme is selected.

    const CenterX = g.getWidth()/2;
    const CenterY = (g.getHeight()/2) + (Bangle.appRect.y/2); 
    const outerRadius = (g.getHeight() - Bangle.appRect.y)/2;

    Thanks for all your work on this - it looks like its 10s of hours of work !
    Definitely the best Bangle analgue clock I have seen so far !!!

  • The following screenshots should illustrate the benefit of not just using Bangle.appRect, but investing a little bit of processing capacity (once!) in order to make a circular clock face as large as possible (its already small enough)

    2 Attachments

    • smartClockSize.png
    • simpleClockSize.png