Refine style attribute on components

[ntoll]

Styling is provided by themes. However, we need to provide an "escape hatch" for experienced developers who want more flexibility on styling components. Hence the need for (and refinement of) a style attribute on Component subclasses. In its simplest form, style could just be raw CSS attached to the component via the HTML style attribute.

[ntoll]

Do we have a style collection for each widget? If so, what are they for each widget. Ask Toga..!

Examples include platform agnostic ways to define (as appropriate for each different widget):

• Size of widget (t-shirt size?)
• Background colour
• Font
• Border
• etc...

[mhsmith]

Toga doesn't explicitly list which styles are appropriate to which widget – irrelevant styles are simply ignored. But the Invent builder would need such a list.

The applicable styles depend not only on the class of the widget, but also on the widget's parent. For example, every Invent Component currently has a row_span and column_span, but they have no effect unless the Component is inside a Grid.

So here's what I'm thinking of:

• Separate the "style" properties (which will become CSS) from the "content" properties (which will become HTML).

• Keep the content properties as they are, but move the style properties into a separate class, like this:

  Button(
      name="button honk",
      label="HONK!",
      channel="honk",
      style=Style(position="FILL"),
  ),

• Each Component subclass would declare (in a non-public attribute) which styles it supports for itself. A Container subclass would additionally declare a list of possible styles for its children. For each widget, the builder would offer the combination of the self-styles for the widget, and the child-styles from its parent.

Advantages of this approach:

• It provides a logical grouping of properties in the builder (#96).
• It allows a similar separation of concerns in the code, so that core.py would concentrate on the content, while the style code would be moved to a separate file. This would make them both more maintainable.
• Potential future developments:
  • It would enable a "copy style" command, which is a common and useful feature in WYSIWYG editors. For example, Google Docs calls it "paint format", and uses a paint roller icon.
  • It would allow combinations of style values to be grouped into an object and shared between multiple widgets, which could be useful both in the builder and in manual coding. This would be the equivalent of a CSS "class".

[ntoll]

@mhsmith Thank you for this... it all makes sense to me..! :slightly_smiling_face:

Happy to pair on this with you at a time of your convenience. :+1:

[mhsmith]

How about during the Honkathon on Thursday, unless you already have something planned for that?

[ntoll]

Sounds like a plan! Looking forward to it. We can also explain the work we've been doing on tasks (i.e. the simple abstraction in Invent for asynchronous / non-blocking activity).