You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently CogShell and CogPlatform are intertwined due to historical hubris, and one needs to know in which order each operation on them has to be invoked to successfully have things work. This is far from ideal, and is a sure footgun in the public API.
Since the switch to GIO modules (#320) and, more recently, the change to allow platform plug-ins to define their own CogView subclass (#570), we no longer need to do this dance because the current in-use CogPlatform object can always be accessed globally, so the CogShell (or anything that replaces it) can fetch it with cog_platform_get_default() (as done e.g. in #565 to simplify the launcher).
Finally, currently CogShell tries to both handle settings that apply to “Cog as a platform” (device scaling factor, whether to run in automation mode, configuration file settings) and also settings to apply by default to WebKit (WebKitSettings, WebKitWebContext, etc.)—and probably it is not a good idea to conflate the two.
Therefore, going forward, we would want to:
Make CogShell handle application settings only, probably renamed to a new CogConfiguration class.
Remove the handling of WebKit configurations from CogShell, or move them to a new utility class which is optional to use, or alternatively have some way of optionally setting default instances for WebKitSettings, WebKitWebContext and friends that would be picked by the custom CogView constructor if not specified during construction.
The text was updated successfully, but these errors were encountered:
Currently
CogShell
andCogPlatform
are intertwined due to historical hubris, and one needs to know in which order each operation on them has to be invoked to successfully have things work. This is far from ideal, and is a sure footgun in the public API.Since the switch to GIO modules (#320) and, more recently, the change to allow platform plug-ins to define their own
CogView
subclass (#570), we no longer need to do this dance because the current in-useCogPlatform
object can always be accessed globally, so theCogShell
(or anything that replaces it) can fetch it withcog_platform_get_default()
(as done e.g. in #565 to simplify the launcher).Finally, currently
CogShell
tries to both handle settings that apply to “Cog as a platform” (device scaling factor, whether to run in automation mode, configuration file settings) and also settings to apply by default to WebKit (WebKitSettings
,WebKitWebContext
, etc.)—and probably it is not a good idea to conflate the two.Therefore, going forward, we would want to:
CogShell
handle application settings only, probably renamed to a newCogConfiguration
class.CogShell
, or move them to a new utility class which is optional to use, or alternatively have some way of optionally setting default instances forWebKitSettings
,WebKitWebContext
and friends that would be picked by the customCogView
constructor if not specified during construction.The text was updated successfully, but these errors were encountered: