Countdown size strategy

[jhanarato]

The Countdown class should accept a way of changing the appearance given certain parameters. At the moment we have an external function, appearance() that does the job. If we can pass something similar then one strategy could be to "zoom" and another to allow testing. The current Appearance dataclass is pretty much what we want to return and the Countdown class can pass those to the Icons and GridLayout instances.

[jhanarato]

GridLayout can accept a complete Appearance instead of having three methods for max_columns, icon_size and gap.

Icons simply needs the size.

[jhanarato]

As for inputs:

Our old appearance() function takes the two dates making the countdown range. I guess that was where my Icons/GridLayout refactoring started. However, we need:

• At least the number of icons.
• The total number of days between the uposathas. i.e. 14/15 day

The second could be useful. I think it would be nice if a 14 day started with 7 columns and 15 days with 8.

[jhanarato]

This works now, albeit without the 14 day feature.

[jhanarato]

I think we can revive the Appearance dataclass and have it referenced by both Icons and GridLayout. The same object can be modified by the resize() function.

[jhanarato]

From my notes:

Countdown Component Order of Events

1. Create the icon sequence
2. Get the sequence length
3. Calculate icon size, gap and max columns
4. Set the icon sequence icon size
5. Set the grid layout icon size, gap and max columns

Now the component is initialised and we can get its height and width, and draw it. We cannot resize it after construction.

max_columns and resizer function

We're changing max_columns according to the number of icons. I think that's unnecessary as the component can drop columns as it gets smaller. We can just leave it at 8 columns but a nice feature would be to pass in a flag for 14 day uposathas and use 7 columns instead. Then the rows line up nicely.

Should resizer modify the icon sequence and grid layout directly?

We could do the following:

1. Resizer returns an Appearance dataclass as previously, but frozen.
2. Icon sequence gets icon size from appearance.
3. Grid layout gets icon size, gap and max columns from appearance.

Embiggen small icons

The smallest icons could be slightly larger.

What is our exposed interface?

I've made a note to review the public interface of the countdown module classes to see what we're exposing publicly. Countdown could provide get-access directly to its Icons and GridLayout attributes to provide measuring points for our tests.

Resize method

We could add a resize() method to Countdown. At present we don't need this as we always check the size and then draw, but it is interesting to think about how this would work.

[jhanarato]

So the public interface problem. The following test cases ask for protected values:

test_countdown_component.py test_countdown_resize.py

We probably want to fix this up before reworking the resizer function.

[jhanarato]

By passing an Appearance dataclass to GridLayout and making it available via a property we can remove access to the GridLayout protected members. This is probably the next step to take.

[jhanarato]

Baby steps:

1. GridLayout creates and provides an Appearance as a property built internally.
2. Construct an Appearance after resizer is called and pass to GridLayout constructor.
3. Change GridLayout internals to use Appearance.

[jhanarato]

If we provide the Appearance object via Countdown, should it hold a copy of the object or access GridLayout's?

[jhanarato]

OK!

GridLayout just takes an Appearance and icon_count with all the setter methods removed. Starting point is provided when icon_coordinates() is called.

Next step is to provide a 14 day flag.

[jhanarato]

Fourteen day flag is available now. I'm going to close this issue.

See Issue #14 for policy level approach to resizing.