Page MenuHomePhabricator

Efl.Input.Event
Closed, ResolvedPublic

Description

mixin @beta Efl.Input.Event requires Efl.Object extends Efl.Duplicate
{
   [[Represents a generic event data.

     Note: Most Efl Events do not carry Efl Objects, rather simple data
           structures. This class is intended to carry more complex event
           data, such as pointer events.
   ]]
   ...
}

Related Objects

StatusAssignedTask
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
segfaultxavi triaged this task as TODO priority.
segfaultxavi added a parent task: T7964: Efl.Input.Key.
segfaultxavi added a parent task: T7965: Efl.Input.Hold.
segfaultxavi added a parent task: T7966: Efl.Input.Focus.
zmike moved this task from Backlog to Evaluating on the efl: api board.May 16 2019, 10:53 AM

Seems reasonable ?

bu5hm4n added a comment.EditedMay 17 2019, 1:18 AM

Wrong Comment in Wrong Task. :(

Property has_pointer_caps belongs to Efl.Input.Device (T7969).

There is no has_pointer_caps in efl_input_event ... ?

I think this looks good ?

I do not understand this part:

@property processed {
   [[$true if @.event_flags indicates the event is on hold.]]

From the flag's description in efl_input_types.eot it looks like a better name would be in_process.

Also, why are the processed and scrolling properties duplicated in the event_flags?

processed means that someone did something with this event, and none else should deal with it again.

processed and scrolling beeing a different thing -> no idea, i would put scrolling under @beta.

I mean that the event_flags property (which is @pure virtual) already has flags named processed and scrolling. Why do we also have processed and scrolling properties (regular properties)???

Ah! those are actually mirrored properties, for convinience usage i guess, sometimes just &'ing values is better, sometimes a property is easier ... :)

OK, but that's weird, we have no such convenience proxies anywhere else.

I seem to remember a discussion long ago about why this weird structure was needed, but I cannot find it.
Related? 9fdf584d1a47

It does seem weird to have both.

A brief analysis reveals that the processed property is used in elm for getting and setting. The scrolling property has no usage in the tree.

Outside of the implementations for events/classes in efl_input, and some small usage in efl_ui_widget, event_flags does not seem to be used anywhere.

I guess the reasoning is that it's easier to copy the flags if you have it as a bitmask?

So we agree one of the two sets of flags should be removed?

If the only point in favor of the bitmask is that it's easier to move around, but there are only TWO flags... I vote we remove the bitmask.

bu5hm4n moved this task from Evaluating to Stabilized on the efl: api board.Jun 27 2019, 9:13 AM