Page MenuHomePhabricator

Efl.Config and Efl.Config_Global
Open, Incoming QueuePublic


The implementation in Efl.Config_Global has a lot of API that should be part of the interface in Efl.Config. The Efl.Config_GLobal should not define API and just serve the prupose of beeing a singleton pattern.

Also, as discussed in T7356 (in this comment), it would be nice to have a list of valid config keys:

This list should be machine-readable so it can used to generate a list of #defines for C (only key names), a list of static const string for C# (only key names), and a nice table for the documentation (key names and types). Maybe EO already has everything we need and this list could be simply an EO enum?


I am wondering if you expect that the new form supports IntelliSense.

e.g. If I input key name SetConfig("scale", then its value type "double" can be displayed?

I really want to support IntelliSense for this case but I have no idea how to support it in this case..

Could you give me the function form of SetConfig() which you expect?

What I had in mind (An enum in C (or a list of #defines), and a list of static const strings in C#) would not provide type information. The SetConfig() method would be generic, as it is now:

public class efl.Config {
  static const string EFL_CONFIG_KEY_FINGER_SIZE = "finger_size";
  bool SetConfig(System.String name, eina.Value value);

If we want IntelliSense we need something else... Maybe a second list with all the types?

static const eina.ValueType EFL_CONFIG_TYPE_FINGER_SIZE = eina.ValueType.Double;

This could then be used like this:

var val = new eina.Value(EFL_CONFIG_TYPE_FINGER_SIZE);
efl_config.SetConfig(EFL_CONFIG_KEY_FINGER_SIZE, val);

Which cannot be compressed to:

efl_config.SetConfig(EFL_CONFIG_KEY_FINGER_SIZE, new eina.Value(EFL_CONFIG_TYPE_FINGER_SIZE).Set(15));

because eina.Value.Set() returns a bool instead of this (There's a proposal in T7388).

In C this could be wrapped in macros to make it simpler, but in C# I do not know (generics? variadic args?). The C# people should help here (@lauromoura @vitor.sousa @felipealmeida).

Since D7526 things can be far simpler:

efl_config.SetConfig(EFL_CONFIG_KEY_FINGER_SIZE, 15.0);

And the new implicit conversion operators will automatically generate the Eina.Value.
However, the user still has to provide the correct type (int, double, string, ...) so we are not done yet :(

zmike added a subscriber: zmike.

What's going on here?

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).

This has not yet been solved, although some suggestions were given starting in comment T7356#124323.

zmike edited projects, added efl: api; removed efl (efl-1.22).Mar 20 2019, 7:39 AM
zmike moved this task from Backlog to Evaluating on the efl: api board.Jan 30 2020, 7:13 AM
bu5hm4n renamed this task from Efl.Config and Efl.Config_GLobal to Efl.Config and Efl.Config_Global.Jan 31 2020, 4:32 AM

Another idea to simplify that:

How about we are adding a efl_configs.json that looks something like:

   name: "finger_sizer",
   documentation: "The size the finger has on the screen",
   type: int,

Types can be either int, string, double, boolean

This way we can generate the implementation for _efl_config_global_efl_config_config_get and _efl_config_global_efl_config_config_set. *AND* we can autogenerate all the helpers, and the structs containing all this.

Is that something you guys would agree on? I think we should rely here on the power of autogeneration to solve this, otherwise we are loosing too much hours here.