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.
]]
...
}Description
Description
Details
Details
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T7562 efl.input.interface | ||
| Resolved | None | T7963 Efl.Input.Pointer | ||
| Resolved | None | T7964 Efl.Input.Key | ||
| Resolved | None | T7965 Efl.Input.Hold | ||
| Resolved | None | T7967 Efl.Input.Event | ||
| Resolved | None | T7969 Efl.Input.Device | ||
| Resolved | None | T7970 Efl.Input.Device_Type |
Comment Actions
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?
Comment Actions
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.
Comment Actions
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)???
Comment Actions
Ah! those are actually mirrored properties, for convinience usage i guess, sometimes just &'ing values is better, sometimes a property is easier ... :)
Comment Actions
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
Comment Actions
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?
Comment Actions
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.