- Is Sprint
Initially @bu5hm4n stated that Efl.Config should contain all the API and Efl.Config_Global should just be a singleton implementing that API (nothing has been done in this regard yet).
Then @Jaehyun_Cho brought in the discussion from another thread (T7356):
- The ELM config API has a thousand methods: elm_config_finger_size_get(), elm_config_scroll_thumbscroll_min_friction_set(), etc
- This was replaced by a generic config API in the new API: Eina_Value *efl_config_get(const char *name) and efl_config_set(const char *name, const Eina_Value *value).
- While the new API is more flexible, it has two drawbacks:
- The user does not know which config values are available since they are strings which must be looked up in the docs (previously, the IDE could help you).
- The user does not know the TYPE of the config values, they must be looked up in the docs (previously this was known).
Which leaves us with 1 thing left.
Tue, Feb 19
- From the Focus tutorial: "There are 6 commands for Focus navigation: 4 *directional* (Up, Down, Left, Right) and 2 *ordinal* (Previous and Next).". I never liked the word "ordinal", and I am going to change it to "sequential". Therefore, I propose we change the method to sequence_setup or sequence_prepare. The docs should explain that this method is meant to configure the sequence of widgets you get when you navigate through "previous" and "next". The event then could b
- prepare_logical_none_recursive should be prepare_logical_non_recursive (this is not critical as it is internal).
Sat, Feb 16
@lauromoura Afaics this only affects bindings, but not the efl.object definition perse. @segfaultxavi improved the documentation big time. To me the API looks good, except one tiny thing, i don't know if we want to have allow_parent_unref out of beta or not, because to me this seems like a hack that should not be needed in future, opinions @zmike @cedric.
Fri, Feb 15
As a part of T7653 this interface can be removed completely and moved into efl_access_object. Additionally events can be refactored into regular methods, so instead of "window,created" we will have something like window_created_emit method or just emit with some parameter. Is this acceptable?
This function is called before logical movements are performend, this is esp. usefull to set the explict ordering on a node. Hence, prepare logical. Any ideas for a new name ?
Yea seems fine on the rename. As for method naming, I meant that prepare_logical is not a super informative method name. What does efl_ui_focus_object_prepare_logical even mean at first glance? Nothing, at least to me...
@zmike which one do you mean ?
Closing this since we're removing the interface.
So I think all we need here is to rename the event? I'm on it.
The method naming here seems a bit uninformative?
Why does this have a moved event?
What's going on here?
I've created patches for the above, though the new properties lack implementations. This can be solved at a later point.
So maybe something like:
We could merge the idea of multi selection and selection class model into one class easily, so let's do it that way.
For the long term, I would love to have a way to load from an Efl.Io stream as a load function, could be load_from_io then.
I think I agree with @segfaultxavi here on most bit:
Oh, I thought to meant "conceptual" overlap, sorry.
Looks like that, yeah.
(E) focus,in (E) focus,out
I do not like the name of this interface. First off, it not only contains size hints, also position (like hint_align). I'd prefer something like Efl.Gfx.Geometry_Hint.
Secondly, Size_Hint suggests that this is a hint, instead of an object accepting hints, but I cannot come up with a better name for that.
I agree is_frame_object() seems internal, as its own docs say.
Where? I cannot find any overlap.
I initially listed some concerns, which you addressed with specific proposals:
And we all agreed, so you are free to implement those.
I don't think there's any way this makes it for 1.22 given that it goes with T7575 and requires dnd/selection types...
Not totally sold on hint_margin naming? Was this hint_padding or similar at some point?
is_frame_object seems bad to expose since this should only be used by internals?
This seems like it has some overlap with T7584?