.value properties for widgets
See original GitHub issueHow do you feel about creating .value getter and setter properties for the widgets?
e.g.
a value property would allow CheckBox value to be get and set as a boolean
class CheckBox(CheckButton):
@property
def value(self):
return (self.get_value() == 1)
@value.setter
def value(self, value):
if value:
self.select()
else:
self.deselect()
check = CheckBox()
if check.value:
check.value = False
The same value property could be created for all widgets allowing a simple interface to get and set its value.
Issue Analytics
- State:
- Created 6 years ago
- Comments:11 (9 by maintainers)
Top Results From Across the Web
Widget properties and functions - IBM
Properties available for most widgets · The value you assign should be relative to the top left origin of the closest non-static parent....
Read more >Set predefined values for widget properties - Sitefinity CMS ...
Set predefined values of widget properties of any type of widget, so that once dropped on the page, the widget is preconfigured and...
Read more >Widget Common Properties
The properties (common for all the widgets) of the Widget class are: Alignment; Expand (horizontal and vertical); Expand (Horizontal); Focus Skin Property ......
Read more >Defining widget properties | Xperience 13 Documentation
Specify each widget property by creating a corresponding property in the model class. You can also set default values for the properties.
Read more >value property - FormFieldState class - widgets library - Dart API
API docs for the value property from the FormFieldState class, for the Dart programming language.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This is all about formally managing the deprecation process of your API methods in a controlled manner, and there are ways and means to do that.
The problem with saying ‘they can always use an older version of the API’ is that they are bound to want the shiny new features anyway even if on the old API, but probably won’t have the skills or time to do a massive merge to get those new features retro-fitted, or won’t have the time to update their existing homework to the new style.
You can use some getattr magic to delegate to the new inner tk, and make that delegation optional. getattr is only called if the class does not already have that method/attribute defined in it’s attribute dictionary.
In early releases, leave deprecated methods enabled by default. In later releases, disable deprecated by default. That way you can use both styles interchangeably, but the day that you flip the default ENABLE_DEPRECATED to False, the user can still set it to True at runtime if they want to use the old way. Here is a general design pattern for that.
It gives your users a way to migrate gradually, without breaking old code (or if you do break old code, users can easily flip the switch to fix it).
Added these to 0.4 where they make sense, but maintained backwards compatibility.