I am just guessing here, but looks like the intention was to replace the 170 APIs inside elm_config.h by a single generic Efl.Config API which works with key-value pairs.

In C# you have to do now:

var config = new efl.Config_Global();
Console.WriteLine("finger size = " + config.GetConfig("finger_size"));

Does anybody in committers have more information?

@segfaultxavi

Thank you for sharing the information.

Is there any good way to provide key strings and value types to application developers? Otherwise, application developers cannot call SetConfig() easily..

I cannot find any list or enum with the accepted config key strings, they are hardcoded in elm_config.c

Previously, if you made a mistake with the property name, you got a compile-time error (undefined symbol), now you get a runtime error, which might not be noticed.

As you say, I think it would be good to have a list of accepted Elementary config key strings, somewhere.

Unless there was a reason for not adding it in the first place... Go ahead and create this list if nobody complains...

I think it would be nice to have them just as defines, however, elm_config is more generic, and can use whichever key you like to have. With the defines, each user can also use config keys. while the standard ones are defined for elm.

Yes, absolutely, I was thinking in a long list of defines to simplify usage of the generic API:

[...]
#define ELM_CONFIG_KEY_FINGER_SIZE "finger_size"
[...]

So you can use the provided defines or use your own keys.

How are custom keys used in the generic config interface, though? Efl.Config_Global will only get/set the hardcoded keys. Do you need to inherit from it to add custom keys?

@segfaultxavi @bu5hm4n

I think that there is no way to automatically provide value types corresponding to the key string. (e.g. value type "double" corresponding to the key string "scale")

If so, what about picking up some important config keys and supporting them only in Efl.Config_Global?
e.g. Efl.Config_Global.SetScale(Double val)

I think the following properties are enough for now.

• scale
• finger_size

What do you think?

I think adding Efl.Config_Global.SetScale(double val) would be going back to the previous situation. If we do that, we better remove ALL the new generic config and use only the 170 hardcoded APIs...

By design, the new generic config API has to rely on documentation instead of method names, so we need to create a doc page with the list of all config values and their type. Unfortunately, this information is not centralized anywhere. The only thing I could find are the tooltips for elementary_config, set throughout the code in src/bin/elementary/config.c :(

I think we need a list of valid elementary config keys, and their types. 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?

Maybe we could have a string enum in Eolian?

enum config_common_keys
{
  finger_size = "finger_size",
  scale = "scale",
 ...
}

That could be translated to #define in C and some other things in other languages, such as constant strings.

@q66 what do you think of @felipealmeida's proposal in the comment above?

yeah we could probably have that, can you create a ticket and assign it to me?

On a second thought... won't the enum be enough? The string can be autogenerated from the enum key quite easily:

#define CONFIG_COMMON_KEYS_FINGER_SIZE_STR "finger_size"

If eolian generates this table of defines automatically (besides the enum it currently does), we do not need to add support for string enums. Correct?

We still need a way to indicate the type of these config values, for the docs. This is info not currently in any EO file.

@segfaultxavi

As you know, at least we provide Efl.ConfigGlobal.SetConfig(System.String name, Eina.Value value) now. So app developers can use this function although it is not that easy to use this function.

IMHO, there is no effective way to make easier usage unless we provide wrapper function which has enum parameter instead of System.String name parameter and specific type parameter instead of Eina.value value.

So the priority of this task is relatively lower than other important tasks. (at least the function works)

If you need to do something for this task for documentation, then please do that.
Otherwise, let's focus on other important tasks and then later let's get back to this task :)

@segfaultxavi @bu5hm4n

BTW, what do you think about changing class name Efl.Config_Global to Efl.Ui.Config?

Because Efl.Config_Global is for elm_config and elm_config works mainly based on elementary and most of classes in elementary use "Efl.Ui." prefix.

"Global" is used only for this case and seems not synchronized with other class names in elementary.

This naming rule is related to the naming rule of Theme class (T7357).

What do you think? :)

In T7356#125607, @Jaehyun_Cho wrote:

Otherwise, let's focus on other important tasks and then later let's get back to this task :)

Sure, let's work on this later. I wasn't working on this, or I would have set myself as the owner of the task :)

In T7356#125610, @Jaehyun_Cho wrote:

BTW, what do you think about changing class name Efl.Config_Global to Efl.Ui.Config?

I think @lauromoura had a problem with this because Config was reserved by the C# bindings.
There are a few naming issues in the C# bindings which I am currently happy with, like having to start the elm main loop by using Efl.Ui.Config.Run(). These will need to be addressed at some point.

In T7356#125613, @segfaultxavi wrote:

In T7356#125607, @Jaehyun_Cho wrote:

Otherwise, let's focus on other important tasks and then later let's get back to this task :)

Sure, let's work on this later. I wasn't working on this, or I would have set myself as the owner of the task :)

In T7356#125610, @Jaehyun_Cho wrote:

BTW, what do you think about changing class name Efl.Config_Global to Efl.Ui.Config?

I think @lauromoura had a problem with this because Config was reserved by the C# bindings.
There are a few naming issues in the C# bindings which I am currently happy with, like having to start the elm main loop by using Efl.Ui.Config.Run(). These will need to be addressed at some point.

Currently we use Config as a class to hold the init/shutdown functions, but it can be changed (something like Eina.Setup.Init()?).

@segfaultxavi about the loop, are you talking about using something like EFL_MAIN, with hooks that the binding user fill (main_constructor, main_destructor) and the binding would do the dirty work of init/shutdown/looping? We talked about it in briefly in T7204 and I think it can be done.

I meant that I don't like Efl.Ui.Config.Run() as the name of the method to start EFL applications. I would prefer something outside the Ui namespace.

But, if you finally implement the C# equivalent to EFL_MAIN, then this call would be hidden and I don't care that much :)

@segfaultxavi @lauromoura

Is there any suggestion to rename class "Config" which mainly supports Init() and Shutdown()?
(e.g. efl.ui.Config, eina.Config, ...)

My first thought was "System" (e.g. efl.ui.System.Init(), efl.ui.System.Run(), ...) but "System" cannot be used because there is "System" class in C# already.
(e.g. System.IntPtr cannot be identified successfully)

I don't think "Setup" is the right name.. because efl.ui.Setup.Run() does not look good to me..

What about Static ? I think all methods in the Config namespaces are static (Init(), Shutdown() and Run() are static).

So: Efl.Ui.Static.Init(). However, I would still prefer that some C# equivalent of the EFL_MAIN macro hides all this :)