Remove global settings and instead pass a YGConfig struct to calculate layout #418

New Issue

2017-02-22T03:27:28-08:00

emilsjolander commented

2017-02-22 03:27:28 -08:00

(Migrated from github.com)

We need a way to configure tree calculation. Two examples are:

Experiments
Point scale factor

Currently these are global settings. This works if your application only has one instance of yoga but in some cases you may be running different frameworks which both use yoga (maybe without knowing it) and they may want to configure such settings differently. This is not currently possible.

I suggest adding a variant of YGNodeCalculateLayout called YGNodeCalculateLayoutWithConfig which takes a YGConfig struct as a last parameter.

We need a way to configure tree calculation. Two examples are: - Experiments - Point scale factor Currently these are global settings. This works if your application only has one instance of yoga but in some cases you may be running different frameworks which both use yoga (maybe without knowing it) and they may want to configure such settings differently. This is not currently possible. I suggest adding a variant of `YGNodeCalculateLayout` called `YGNodeCalculateLayoutWithConfig` which takes a `YGConfig` struct as a last parameter.

❤️ 1

woehrl01 commented

2017-02-22 10:14:31 -08:00

(Migrated from github.com)

I'd like to give this a go.

I'm not sure about the best way to structure the YGConfig. As we can quickly produce some binary incompatibilty here, as soon as we add a new experiment.

Some pseudocode:

struct {
  YGExperiment[2] experiments;
  float scaleFactor;
};

would change the struct size any time we change the experiments array. So for improved readability we could change to:

struct {
  bool IsExperiment1Enabled;
  bool IsExperiment2Enabled;
  float scaleFactor;
};

we still need to zero out the struct here. Thus I'm think of moving the creation to fully internall:

YGConfig * YGConfigNew();
YGConfigFree(YGConfig * config);
YGConfigSetExperiment(YGConfig * config, YGExperiment e, bool isEnabled);
YGConfigSetScaleFactor(YGConfig * config, float f);

We need a lot more calls to set this up in C, but could be hidden by other languages. Best benefit, we can change without breaking the ABI, and it's always properly setup.

So the question is do we expose the struct to the caller or do we hide it internally?

What do you think @emilsjolander ?

I'd like to give this a go. I'm not sure about the best way to structure the ```YGConfig```. As we can quickly produce some binary incompatibilty here, as soon as we add a new experiment. Some pseudocode: ```c struct { YGExperiment[2] experiments; float scaleFactor; }; ``` would change the struct size any time we change the experiments array. So for improved readability we could change to: ```c struct { bool IsExperiment1Enabled; bool IsExperiment2Enabled; float scaleFactor; }; ``` we still need to zero out the struct here. Thus I'm think of moving the creation to fully internall: ```c YGConfig * YGConfigNew(); YGConfigFree(YGConfig * config); YGConfigSetExperiment(YGConfig * config, YGExperiment e, bool isEnabled); YGConfigSetScaleFactor(YGConfig * config, float f); ``` We need a lot more calls to set this up in C, but could be hidden by other languages. Best benefit, we can change without breaking the ABI, and it's always properly setup. So the question is do we expose the struct to the caller or do we hide it internally? What do you think @emilsjolander ?

emilsjolander commented

2017-02-22 10:24:37 -08:00

(Migrated from github.com)

You have definetly thought this through more than me! We could hide the YGConfig struct the same way we currently hide YGNode. I'm not too worries about the C API being verbose as the C API tends to only be used from within other higher level frameworks and not in user space code.

You have definetly thought this through more than me! We could hide the `YGConfig` struct the same way we currently hide `YGNode`. I'm not too worries about the C API being verbose as the C API tends to only be used from within other higher level frameworks and not in user space code.

woehrl01 commented

2017-02-22 10:35:06 -08:00

(Migrated from github.com)

Ok, than I'll hide it like YGNode and keep the experiment array, so we can simple reuse (with a little change) the already existing YGSetExperimentalFeatureEnabled.

Ok, than I'll hide it like ```YGNode``` and keep the experiment array, so we can simple reuse (with a little change) the already existing ```YGSetExperimentalFeatureEnabled```.

❤️ 1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: DaddyFrosty/yoga#418