Page MenuHomePhabricator

efl.orientation
Closed, ResolvedPublic

Description

|interface Efl.Orientation @beta
|β”œ (P) orientation
|β”œ (P) flip

Related Objects

StatusAssignedTask
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedsegfaultxavi
bu5hm4n created this task.May 3 2019, 11:34 AM
bu5hm4n triaged this task as TODO priority.

I would like to talk about this interface...

It is called Efl.Orientation and it defines two properties to control flipping (mirroring) and rotation. I propose we name it Efl.Orientable, since interfaces should be adjectives.

  • The flipping property is called flip and has type Efl.Flip, with values {none, horizontal, vertical}. No complains here.
  • The rotation property is called orientation (like the interface), it has type Efl.Orient and has values {up, down, left, right} which, according to the docs, correspond to {0, 90, 180 and 270} degree rotations. I propose the Efl.Orient enum is renamed Efl.Rotation and the orientation property is renamed rotation.

In this way it is clear that an orientation is the combination of a rotation and a flip.

Furthermore, maybe we can combine the rotation and flip properties into a Efl.Orientation bitfield which could be used like this:

efl_orientable_orientation_set(obj, EFL_ORIENTATION_90 | EFL_ORIENTATION_HORIZONTAL_FLIP);

The C function name could be shortened further by using c_prefix: efl_orientation; as it has been done in D8898 for Efl.Ui.Directed.

And finally, we should use this interface everywhere a rotation or flip is used: Efl.Ui.Win and Efl.Screen both define an integer rotation property with values {0, 90, 180, 270} which could be replaced by an Efl.Orientation. I remember we already discussed about this.

segfaultxavi moved this task from Backlog to Evaluating on the efl: api board.May 15 2019, 5:03 AM
zmike added a comment.May 15 2019, 6:05 AM

I would like to talk about this interface...

It is called Efl.Orientation and it defines two properties to control flipping (mirroring) and rotation. I propose we name it Efl.Orientable, since interfaces should be adjectives.

I agree.

  • The flipping property is called flip and has type Efl.Flip, with values {none, horizontal, vertical}. No complains here.
  • The rotation property is called orientation (like the interface), it has type Efl.Orient and has values {up, down, left, right} which, according to the docs, correspond to {0, 90, 180 and 270} degree rotations. I propose the Efl.Orient enum is renamed Efl.Rotation and the orientation property is renamed rotation.

    In this way it is clear that an orientation is the combination of a rotation and a flip.

I think orientation/rotation in this sense is meant solely for image loading where it is restricted to 90 degree rotations. For any other case we would want to have more granular control over the rotation.

Furthermore, maybe we can combine the rotation and flip properties into a Efl.Orientation bitfield which could be used like this:

efl_orientable_orientation_set(obj, EFL_ORIENTATION_90 | EFL_ORIENTATION_HORIZONTAL_FLIP);

Is the purpose of flip to be used with images or with all objects?

The C function name could be shortened further by using `c_prefix: efl_orientation;` as it has been done in D8898 for `Efl.Ui.Directed`.

And finally, we should use this interface everywhere a rotation or flip is used: `Efl.Ui.Win` and `Efl.Screen` both define an integer `rotation` property with values {0, 90, 180, 270} which could be replaced by an `Efl.Orientation`. I remember we already discussed about this.

No, this is not accurate. The Efl.Ui.Win rotation is an integer precisely because it does not need to be clamped to 90 degree rotations.

I think orientation/rotation in this sense is meant solely for image loading where it is restricted to 90 degree rotations. For any other case we would want to have more granular control over the rotation.

OK, that is an interesting point. We might want to distinguish between free rotation (an integer) and rotation restricted to 90ΒΊ jumps (an enum). A separate name for each one would be very nice. The interface being discussed (Efl.Orientation) deals with restricted rotations, other places (like Efl.Ui.Win) use free rotation.
The problem still remains, though, that I do not like having a property called orientation inside an interface called Orientable when the interface has another property (flip). That's why I was proposing rotation instead of orientation for the property name. It would need to use the "restricted rotation" synonym.

Furthermore, maybe we can combine the rotation and flip properties into a Efl.Orientation bitfield which could be used like this:

efl_orientable_orientation_set(obj, EFL_ORIENTATION_90 | EFL_ORIENTATION_HORIZONTAL_FLIP);

Is the purpose of flip to be used with images or with all objects?

As far as I can see only images currently use Efl.Orientation, but any widget could choose to use this interface.
What do you think about merging "restricted rotation" and "flip" into a single bitfield? This solves the aforementioned naming issues (free rotation would be called rotation everywhere, restricted rotation would be called orientation and be combined with flip). Widgets would be free to ignore the flipping part (for example) as long as it's documented. The Efl.Orientable interface would contain a single orientation property.

The Efl.Ui.Win rotation is an integer precisely because it does not need to be clamped to 90 degree rotations.

Understood, and taken into account into the above proposal. Thanks.

After recent renames it now looks like this and I think it is good to go:

interface @beta Efl.Gfx.Orientable
{
   [[Interface for objects which can be oriented.]]
   c_prefix: efl_gfx_orientation;
   methods {
       @property orientation {
         [[Control the orientation (rotation and flipping) of a given object.

           This can be used to set the rotation on an image or a window, for
           instance.
         ]]
         values {
            dir: Efl.Gfx.Orientation(Efl.Gfx.Orientation.none); [[The final orientation of the object.]]
         }
      }
   }
}

Sounds good to me :)

zmike added a comment.May 31 2019, 6:20 AM

This is now for images only and seems good.

zmike moved this task from Evaluating to Stabilized on the efl: api board.May 31 2019, 6:20 AM

I am also ok with new efl_gfx_orientable :)