Super-rough structure-only per-screen refactor

[sjoerdverweij]

No description provided.

[learn-more]

Is the name required?
I'd say that 'id' would be enough.

and a nit: this is indented with 3 spaces.

[sjoerdverweij]

We'll need some kind of name to show in the config UI. Whether this is the best way to do it is debatable, I am open to suggestions.

(Alternately, we could have a big switch somewhere that names Ids, but that makes it easy for Orb authors to forget...)

[learn-more]

public is not needed in a struct as first item, everything in a struct is public by default

[sjoerdverweij]

I forget that all the time, so I like to be explicit. If we decide it's an enforced style thing, no problem, I'll take it out.

[learn-more]

Something like this allows to mix and match the orbs, which is a long-standing feature request:

enum class OrbId
{
    Invalid,

    Weather_DateTimeWeekday,
    Weather_CityPrediction,
    Weather_Icon,
    Weather_TemperatureHighLow,
    Weather_3DayForecast,

    Stocks_1,
    Stocks_2,
    Stocks_3,
    Stocks_4,
    Stocks_5,

    Clock_Hour_h,
    Clock_Hour_l,
    Clock_SecondsColon,
    Clock_Minute_h,
    Clock_Minute_l,
};

[sjoerdverweij]

Yes, that's the point of it, I just started with the weather widget -- are you saying you don't like the naming of the enum members?

[learn-more]

I guess so.

In cases like this, having a consistent style in naming pays off imo.

[lyricnz]

Why would we need an enum? Why not a list of list-of instances? (with constuctor/factory parameters as required). Totally value pseudo-code

[
  [
    new Clock(mode=HourH),
    new Clock(mode=HourL),
    new Clock(mode=SecondsColon),
    new Clock(mode=SecondsH),
    new Clock(mode=SecondsL)
  ],
  [
    new Stock(symbol=whatever, currency=whatever, apikey=whateever),
    ...
  ],
  [
    new WeatherTemp(..., location=whatever),
    new WeatherRain(..., location=whatever),
    new WeatherThing(..., location=whatever),
    ...
  ]
]

[lyricnz]

I guess we need something in the UI, ya

[learn-more]

In the UI, and in the config files / web editor / whatever is used to configure this thing.
You can't really transmit class instances over the web ;)

[dreed47]

I like the overall design direction. I have a couple logical model recommendations.

1. A Gadget represents 5 Orbs but as I see it it needs to support both pre-defined Orb sets like clock and also mix/match user defined Orb sets. I'd recommend abstracting out a ContentSet class. Then maybe rename Gadget to ContentManager. So the ContentManager manages a collection of ContentSets and allow switching between them. So the ContentManager manages both predefined and user-defined ContentSets, handle button interations to cycle through the ContentSets and provides methods for creating, updating, and saving user-defined ContentSets.

2. Feeds - The ContentManager (Gadget) should manage the lifecycle of the Feeds, ensure that Feeds are shared across all Orbs to reduce redundant data fetching, and dynamically load Feeds when needed by one or more Orbs. Also Feeds should make use of TaskManager/TaskFactory when getting data from external APIs

3. Button Handling - ContentManager (Gadget) should specifically manage cycling of ContentSets via left/right button clicks.

4. Renderer - The ContentManager (gadget) should coordinate with the Renderer to draw the active ContentSet on the 5 displays. Each Orb in the active ContentSet should use the Renderer to draw its content on the appropriate display.

5. Need support for persistence for User-Defined ContentSets? to non-volatile storage? then would need methods for loading saved ContentSets on startup

[sjoerdverweij]

I like the overall design direction. I have a couple logical model recommendations.

1. A Gadget represents 5 Orbs but as I see it it needs to support both pre-defined Orb sets like clock and also mix/match user defined Orb sets. I'd recommend abstracting out a ContentSet class. Then maybe rename Gadget to ContentManager. So the ContentManager manages a collection of ContentSets and allow switching between them. So the ContentManager manages both predefined and user-defined ContentSets, handle button interations to cycle through the ContentSets and provides methods for creating, updating, and saving user-defined ContentSets.
2. Feeds - The ContentManager (Gadget) should manage the lifecycle of the Feeds, ensure that Feeds are shared across all Orbs to reduce redundant data fetching, and dynamically load Feeds when needed by one or more Orbs. Also Feeds should make use of TaskManager/TaskFactory when getting data from external APIs
3. Button Handling - ContentManager (Gadget) should specifically manage cycling of ContentSets via left/right button clicks.
4. Renderer - The ContentManager (gadget) should coordinate with the Renderer to draw the active ContentSet on the 5 displays. Each Orb in the active ContentSet should use the Renderer to draw its content on the appropriate display.
5. Need support for persistence for User-Defined ContentSets? to non-volatile storage? then would need methods for loading saved ContentSets on startup

Gadget only needs to support configurable mix/match orb sets, because there really no longer is such a thing as a predefined widget; those are just default mix/match configurations. You'd start out with a configuration for a Gadget that has 4 instances of a ClockDigit orb, and one ClockSeconds orb. If we want to prevent users from changing the default settings, we can make them read-only -- but they will still work the exact same way.
Lifecycle and deduplication of Feeds is in the Feeds class. It should be a singleton, which it currently is not properly set up and referenced as.
Button handling etc.; I think Gadgets is what you want ContentManager to be.
Agreed, it will, the draw code isn't fleshed out yet.
I'm open to the best way to save settings. My current thinking is Serialize/Deserialize methods on the top of the settings hierarchy (Settings) which (de)serializes the global settings, then calls all its GadgetSettings, which then calls all its OrbSettings. (GadgetSettings holds which orbs a gadget shows, OrbSettings has the specific settings for that instance of the orb).

[lyricnz]

Sorry I broke this PR merging #218