Page MenuHomePhabricator
Open, TODOPublic


class Efl.Ui.Radio @beta
├ (P) state_value
├ (P) value_pointer
├ (P) selected_object
├ (M) group_add

Related Objects

bu5hm4n created this task.May 3 2019, 11:24 AM
bu5hm4n triaged this task as TODO priority.
bu5hm4n added a subtask: T7865: efl.ui.check.

I think there should be another widget called Efl.Ui.Radio_Group, where you can add radio buttons. The whole semantic with with the group itself looks confusing to me.

This here is a try to come up with a design for a group class. I go here with the assertion that any set of radio buttons wants to be added in a group.

A new class Efl.Ui.Radio_Group. This class inherits from You can only add new Efl.Ui.Radio class instances to it. This means the placing and logical connection of radio buttons are now the same. Which is quite sane IMO since radio button groups do come with the same ui placement.

This will result in only having one property state_value.
And another class Efl.Ui.Radio_Group that has value, and selected object.

Does that sound acceptable ?
@zmike @segfaultxavi @cedric opinions ?

I like how this simplifies creating radio groups, since you now provide the Efl.Ui.Box automatically.

However, I fear we lose the flexibility to have radio buttons anywhere in the UI (we only provide the API, we should not judge if that makes sense or not).

How about we keep the current grouping mechanism as the "low level API" (fixing what's broken) and add your proposed Efl.Ui.Radio_Group as the "high level API". The Radio_Group class would take care of keeping each Radio's group pointers pointing to the right place, etc.

We could do it like this:

  • Efl.Ui.Radio.Logical_Group
  • Efl.Ui.Radio.Box


The logical group is not a graphical element but rather just the logical stuff, (ensuring one radio button is only enabled etc.)
The box then is just inheriting from Efl.Ui.Box, and additionally has an internal Logical_Group where all the content is added to.

Does that sound nice ?
I don't think we can fix the logical group in a sane manner in the radio group itself.

I like it. Simple case: you instantiate a radio box and add radio buttons. Complex case, you instantiate a radio logical_group and register radio buttons to it, remembering to also add the radio buttons to the ui wherever you want.

Current Elm implementation already has a Logical_Group equivalent in the Group structure. This approach only makes it explicit and therefore easier to understand.

zmike added a comment.Tue, May 28, 8:48 AM
  • Efl.Ui.Radio.Logical_Group

I like Efl.Ui.Radio.Group instead of Logical_Group. We should be careful to avoid introducing new terms (e.g., Logical) which we don't plan to reuse.

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:19 AM

@bu5hm4n can you update this with what it's (probably) going to look like after all your changes land?