class Efl.Ui.Check @beta ├ (P) selected
Description
Description
Details
Details
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T7510 evaluate stabilization potential of efl.ui classes and dependencies | ||
| Open | None | T7867 efl.ui.radio | ||
| Open | None | T7865 efl.ui.check | ||
| Open | None | T7586 efl.access.widget.action |
Comment Actions
IMO this should not inherit from nstate. Check is not made for displaying n-states, everything else then 2 states is going to break the displaying (same for efl.ui.check).
Comment Actions
The whole point of Efl.Ui.Nstate is that widgets like Efl.Ui.Check inherit from it. It provides them count (number of states) and value (current state) properties.
I agree this is a bit over-engineered, but I do not see anything wrong with it.
Efl.Ui.Check is not meant to display more than 2 states. It's a particularization of Efl.Ui.Nstate that only supports 2 states (just like Efl.Ui.Button).
These two widgets should override the count.set property and show an error if anybody tries to use it.
Comment Actions
Then what is the point of having this property, it is an abstraction that does not work. It's useless API. Additionally, due to the fact of inheriting from button, we also get things like autorepeat implemented on check, which is something we definitely do not want ... I would really just make it inherit from layout, and continue from there
Comment Actions
Sure, I have no objection.
Do we have any real N-state widget in EFL, though? Something like a checkbox that accepts a grayed-out third state, or something like that? Looks like most of the work on this class was done by @jpeg so we cannot ask him...
Comment Actions
I'm not aware of any kind of tristate type widget, I guess this was some kind of future-proofing? Would be good to get @woohyun or @Jaehyun_Cho to reply here.
Comment Actions
I don't think nstate would be used in the near future. That was the reason why I hoped to cut the relation between nstate and check :)