• I guess actually my change to the launcher would apply to all builds - it's just anyone that has launcher 0.15 or later

    Yes, that is probably correct since it evals directly.

    I guess we've got your changes to loadWidgets (with hiding) that could be used?

    The current state of my widgetupdate branch probably solves this independent of the build. It does however do some things that probably need some thought before implementing directly in firmware:

    • Keeping state of widget visibility in a global way, currently that are variables in block scope of the boot.js code
    • Currently it overrides the load method to reset the state, but we could probably do a appload event or something to handle that outside of load.
    • Hiding currently only catches the display handlers(touch,swipe,drag) if they are set directly during load by the widget. Handlers set during the livetime of the widget are not caught. Some widgets do replace their handlers regularly. Maybe some documentation on restrictions for widgets would suffice.
    • The first dummy draw using FAKE_G is not necessary, just a try to save a little bit of drawing time. It could be replaced by a standard call to drawWidgets.

    Checking for loadWidgets in the code seems expensive, but maybe we could mark apps in their info files as using widgets.

    Another idea would be defining a new style of widgets, where they are not arbitrary code somehow modifying WIDGETS but an object like

    {
    load: function,
    remove: function,
    draw: function,
    update: function, //Must handle hiding and reaction to Bangle.CLOCK, e.g. removing handlers
    area: function, //Allowed to be modified by load/update/remove but not draw
    width: function //Allowed to be modified by load/update/remove but not draw
    }
    

    and then only fastload if no classic style widgets are loaded. That would feel less workaroundy.

About

Avatar for halemmerich @halemmerich started