Page MenuHomePhabricator

efl.ui.check
Open, TODOPublic

Description

class Efl.Ui.Check @beta
├ (P) selected

Related Objects

bu5hm4n created this task.May 3 2019, 11:19 AM
bu5hm4n triaged this task as TODO priority.

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).

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.

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

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...

zmike moved this task from Backlog to Evaluating on the efl: api board.Wed, Jun 12, 7:36 AM
zmike added a comment.Wed, Jun 12, 9:21 AM

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.

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 :)