ColorUsageWindow, TileUsageWindow, and SupertileUsageWindow are nearly identical in their structure and share many methods with the exact same names and similar logic:
init
_get_current_tree_config
refresh_data_if_ready
request_refresh
_perform_debounced_refresh
_sort_by_column
_update_header_sort_indicators
refresh_data
_on_item_selected
_on_close
_on_tree_configure_debounced
_on_tree_button_press
_on_window_button_release
_on_tree_motion
Impact:
This is a classic example of code that could be refactored to be more "DRY" (Don't Repeat Yourself). If we need to fix a bug in the debounced refresh logic, for example, we have to remember to fix it in all three classes.
Solution: Create a BaseUsageWindow class that contains all of this common logic. The three specific window classes would then inherit from this base class and only implement the parts that are unique to them (like the specific columns and the data calculation).
ColorUsageWindow, TileUsageWindow, and SupertileUsageWindow are nearly identical in their structure and share many methods with the exact same names and similar logic:
init
_get_current_tree_config
refresh_data_if_ready
request_refresh
_perform_debounced_refresh
_sort_by_column
_update_header_sort_indicators
refresh_data
_on_item_selected
_on_close
_on_tree_configure_debounced
_on_tree_button_press
_on_window_button_release
_on_tree_motion
Impact:
This is a classic example of code that could be refactored to be more "DRY" (Don't Repeat Yourself). If we need to fix a bug in the debounced refresh logic, for example, we have to remember to fix it in all three classes.
Solution: Create a BaseUsageWindow class that contains all of this common logic. The three specific window classes would then inherit from this base class and only implement the parts that are unique to them (like the specific columns and the data calculation).