Missing customization option at configs

[ManuelKugelmann]

I'm working on stuff like an embeddable ramses renderer, ramses Spout sender, etc. . I do not want to make any changes to this project to make maintenance easier. I am missing an option to add custom data to the configs. Right now I'am misusing cfg.setAndroidNativeWindow((void*)cfgx); ...

[jcsneaker]

hi, this sounds interesting. From where to where exactly do you want to transfer custom data?

[ManuelKugelmann]

CreateDisplay() to e.g. Window_..., Context__..., Platform_..., PlatformFactory_...

There is also some private and final methods that hinder code reuse - I e.g. had to copy Window_Windows instead of deriving from it.

And some methods do not have access to the configs, so I had to expose the Window_Windows_... member. To getContextAttributes() I had to add a parameter to get access to the config - different windows may use different attributes.

At some places I was also wondering why the Platform stuff made no use of C++ templates - I think the whole per-platform code of PlatformFactory_... could be templated and neccessary custom code put into Platform_...

[ManuelKugelmann]

Bump - my extension needs an update to the current ramses version - any progress here? I saw some potentially related stuff, but did not dive into the source, yet.

[violinyanev]

Hi @ManuelKugelmann this looks like a "summary" of the other issues you posted, right? The other ones are a lot more concrete - should we close this one then, and follow up in the others? Or is there something here you still consider worthy of its own issue?

[ManuelKugelmann]

Hi @violinyanev, this is actually its own issue - I'll try to rephrase: DisplayConfig is not very extensible. I currently use a Hack where I put a pointer to my own config extension into a suitable unused (by me) member of DisplayConfig: I just do cfg.setAndroidNativeWindow((void*)cfgx) where cfgx is a pointer to an instance of my own ConfigExtension class. This way I can get to my custom config data (e.g. Spout settings) everywhere the DisplayConfig is available ;)

[ManuelKugelmann]

In general: DisplayConfig could be much cleaner if it followed a composition pattern, where platform specific settings are wrapped in their own platform specific configuration blocks.