Theme Attribute Tagging
Sunday, December 22, 2019
Example of program supplied attribute tag:
app/tilemap_editor/tileset_selection_box/vertical_scollbar/handle_color
Example of Layers supplied attribute:
layers/window_border/border_color
- Central widget shouldn't need to be part of the identifier for every single element in the program. The new concept reflects this.
- Setting up child widget references to the elements that need to be themed is still necessary. The only thing that changes is how the element's attribute names are defined from the element's perspective.
- The only classes that should be able to name themselves within their constructors are unique classes, as in, classes that only one instance will make an occurrence. For example, the Settings_Menu class is a class that only one object will be made from. It doesn't make sense to have two Settings_Menu's. Therefore, it's safe to name the settings menu during its initialization.
- Non-unique classes should be named by their parent class, after their initialization. For example, the ScrollBar class does not name itself, but in the Scroll_Area class, their exists two instances of ScrollBar's, and the Scroll_Area class names them "horizontal_scollbar" and "vertical_scollbar".
- Consider making "layers" the default primary prefix.
- You could make a single function in the Widget_Wrapper class called "set_app_name(QString)" that will override the default primary prefix.
- Also, since every component should know all of it's child widgets, you should be able to do the "set_app_name()" recursively.
- Should start with calling it on the central_widget since this is where application specific components should fall under.
- Supplemental prefixes, element names, and attributes should be established during each instances initialization, and not in their constructors (since not all instances will have the same names).
- Consider making the Window initialize its child widget references so that direct apply_theme calls are unnecessary.