Attribute Dynamic Linking
Tuesday, September 10, 2024
QLBox::paint(QWidget* widget)
{
// ...
/* Draw Fill */
if (auto stops = m_fill->as_if>(s))
{
// Paint fill as a gradient
}
else
{
painter.fillPath(fill_path,
QColor(QString::fromStdString(m_fill->as(s).c_str())));
}
}
When the above function is called, it is called by a definable widget that inherits QLBox, not a definition. So, like in the Main Window example, the Main Window widget would call the above when it needs to be painted. The m_fill attribute, however, would be associated with the Box definition, which has no awareness of the Main Window or any other widget utilizing it. Where m_fill->as() is called, the Main Window's definition could be passed along to provide the needed context for link resolution.
Tuesday, October 1, 2024
Definitions can be made to resolve their own links, sometime after initialization or after the theme gets set.
Consider a definition that inherits the Box definition, like the Nebula definition from the Nebula application. If you take the Nebula definition and obtain its attributes through a call to LDefinition::attributes(), it would include the Box's Fill attribute. This attribute uses a dynamic link whose resolution depends on the definition requesting its value.
Nebula could resolve this Fill attribute link, but it would need to cache it in the form of another attribute.
NOTE: If Nebula stored another attribute to act as a pre-resolved fill attribute, how does it get used instead of the Box attribute like in the above code example? Keep in mind that the Box attribute would not be storing this cached attribute, but the Nebula definition.
Let's consider how the paint function could be modified to better suit our purposes.
First, m_fill is a definable widget attribute that exists as a member variable of the QLBox class. Definable widget attributes have been defined as member variables for direct access as opposed to storing them in a list/map. This choice was made for performance reasons, since widget paint function calls are expected to be frequent, each call requiring the values of around 10 attributes.
NEW NOTE:
Can the Box definition's Fill attribute store cached resolutions for its dynamic link? The following are example data points:
Both of the above Fill attributes are technically just the same Box attribute being used by the involved definitions.
A definition could determine that it has an attribute (likely inherited) with a dynamic link that doesn't have a cached resolution associated with that definition.
Should there be a Resolution class?
Perhaps a resolution data class could be useful. Consider the important information for each resolution: