Skip to content

Conversation

@davep
Copy link
Contributor

@davep davep commented Nov 16, 2022

For the moment this does nothing more than inherit from a Static; but what it does do is make it easier for someone to add text to their application and to style it by styling all the Labels. Before now it would be common to use a Static but if you try and style (or query) all Statics, you'd also get things like Buttons, which inherit from Static.

See #1190

For the moment this does nothing more than inherit from a Static; but what
it does do is make it easier for someone to add text to their application
and to style it by styling all the Labels. Before now it would be common to
use a Static but if you try and style (or query) all Statics, you'd also get
things like Buttons, which inherit from Static.

See Textualize#1190
@davep davep linked an issue Nov 16, 2022 that may be closed by this pull request
davep and others added 2 commits November 16, 2022 15:09
Co-authored-by: Rodrigo Girão Serrão <5621605+rodrigogiraoserrao@users.noreply.github.com>
@UriyaHarpeness
Copy link
Contributor

This feels weird...
I get the idea but if a user would want to change the style of only part of them he'd still need to do work.
And if going with this approach, I think a warning message should be added if constructing a Static directly and not through inheriting it.
What do you think @davep?

@davep
Copy link
Contributor Author

davep commented Nov 17, 2022

I get the idea but if a user would want to change the style of only part of them he'd still need to do work.

Obviously, hence classes and styles and the like in CSS. This early split between a more "baseline" renderable container and a more "has a specific job" renderable container isn't about reducing or eliminating that sort of work (which, as we both know, would be very little anyway), it just starts to set up what seems like a fairly natural split between a basic renderable container that's about showing text, and more involved widgets.

It's possible that at some point in the near future Label may acquire some extra functionality that wouldn't make much sense in Static but which anyone using Label would optionally want. This wee addition acknowledges that.

And if going with this approach, I think a warning message should be added if constructing a Static directly and not through inheriting it.

I'm not really seeing much value in emitting warnings for this. As it stands, using Static rather than Label makes zero difference and has zero cost. What we're likely to do though is update the documentation and example code to naturally show that labels in an application will use Label, buttons will use Button, etc... and Static will sort of transition into being a more foundational type.

@davep davep added the enhancement New feature or request label Nov 17, 2022
Copy link
Member

@willmcgugan willmcgugan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one request for a doc tweak.

@davep davep merged commit 447c9d8 into Textualize:main Nov 17, 2022
@davep davep deleted the label-widget branch November 17, 2022 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a Label widget type

4 participants