Timer objects: remove setTimer, delTimer #172

New issue

Closed

opened 2026-01-03 20:50:21 +00:00 by john · 2 comments

john commented

2026-01-03 20:50:21 +00:00

Owner

Make timers a mcrfpy level collection the same way scenes are available: tuple of timer objects.

With that ability, devs will be able to access any timer, even if they've lost their reference to it. We no longer need setTimer, delTimer module-level functions.

Make timers a `mcrfpy` level collection the same way `scenes` are available: tuple of `timer` objects. With that ability, devs will be able to access any timer, even if they've lost their reference to it. We no longer need setTimer, delTimer module-level functions.

john added the

priority:tier1-active

system:python-binding

labels

2026-01-03 20:50:21 +00:00

john commented

2026-01-03 22:58:06 +00:00

Author

Owner

spiritually related to #126

Timer objects have an "uninitialized" state, which they can't be re-initialized from. It's just to prevent a segfault from an invalid timer object being held by Python. But we could wrap the recreation process and re-use the Python container.
active is read-only, but we use getter/setters in several places now (see mcrfpy.current_scene). active = True to reinitialize, uncancel, or unpause; active = False to pause, would streamline timers a lot.
Timers need a 'start=True' default init arg, so users can pass 'start=False' to create a timer in the paused state.
timers are unique by name, but uninitialized / canceled timers can have the same as a running one. If we reinitialize an inactive/cancelled timer, any existing timer by that name should be canceled.

spiritually related to #126 * Timer objects have an "uninitialized" state, which they can't be re-initialized from. It's just to prevent a segfault from an invalid timer object being held by Python. But we could wrap the recreation process and re-use the Python container. * active is read-only, but we use getter/setters in several places now (see mcrfpy.current_scene). `active = True` to reinitialize, uncancel, or unpause; `active = False` to pause, would streamline timers a lot. * Timers need a 'start=True' default init arg, so users can pass 'start=False' to create a timer in the paused state. * timers are unique by name, but uninitialized / canceled timers can have the same as a running one. If we reinitialize an inactive/cancelled timer, any existing timer by that name should be canceled.

john commented

2026-01-04 03:12:49 +00:00

Author

Owner

superseded by #173

john closed this issue

2026-01-04 03:12:49 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

john/McRogueFace#172

No description provided.

Rows
Columns