GSoC: Libreoffice Theme (application crashes when I modify ColorConfig on startup)

[Sahil Gautam]

Hi, so the issue has been resolved,https://gerrit.libreoffice.org/c/core/+/168016/comment/b977e358_def16582/
[Rafael's comment on missing registry entry for LoadDefaultSystemColors]. Now it loads the default colors
into the registry once (as expected).

On 6/11/24 4:04 AM, Sahil Gautam wrote:
> Hi
> went through the design of data flow this week. I found myself running away from the VCL
> and it's colors, or rather from the question of "how to get 2 way exchange of colors working".
>
> https://gerrit.libreoffice.org/c/core/+/168016  Here's the patch [WIP]
>
> There is quite some information to keep in the head, I would try to briefly describe it.
>
> - So we get colors out of the widget toolkits using the updateSettings() functions.
> - We have ColorConfig() which gives access to the ExpertConfiguration colors (or colors in the registry).
> - We cannot access ColorConfig inside updateSettings() functions in the VCL (because vcl can't depend on svt).
>
> My plan was to (and still is) to load the registry colors in the StyleSettings object when ColorConfig is
> created (in the constructor), and mark a flag in the StyleSettings that the Theme is Loaded.
> Note that I want to keep the ThemeColors object and the bLoaded flag as static in the StyleSettings.
> The reasons are:
>
> a) this feels right, as the ThemeColors are object independent and depend only on the ExpertConfiguration.
> b) this way, I evade the various SetStyleSettings() calls. Otherwise, at the end, there would be some
>     call which overwrites the ThemeColors.
>
> So for a user using some custom theme, it the flow goes this way:
> - When the ColorConfig is created, the colors are loaded into the static ThemeColors object in StyleSettings,
>    and a flag is marked (theme colors loaded)
> - Then in each VCLPLUGIN's updateSettings(AllSettings&), we overwrite the colors from the toolkit, and put
>    them into the AllSettings object passed as argument. So the theme colors from the registry went to all
>    the parts which will be using the StyleSettings.Get...Color() functions.
> - Then I have to add some code, which will send back those colors to the toolkit[PENDING].
> Seems to work fine.
>
> But the issue comes when the user is using the default theme.
> Where would I fill the registry entries from? If I hardcode some values for Automatic scheme,
> then what's the point of reading system colors. So I thought what if I mark a flag in the StyleSettings
> (not static) when I have read the colors from the toolkit once, and then I will check for that flag
> in the ColorConfig constructor. Along with this I added a registry flag for if the SystemColors
> are loaded into the ExpertConfiguration or not.
>
> The idea is to load the system colors into the registry for theme colors (for automatic scheme)
> once, when the application is started for the first time. then I set that registry setting as colors
> are loaded, no need to load when the application starts again. This way the user's preferences for the
> Automatic scheme won't be overwritten. **The application is crashing on startup when I tried this**.
>
> TL;DR version
>
> Custom theme:
> 	Defaults come from the theme, and after that StyleSettings keeps an updated
>   	copy of the registry, which is used for the to-and-fro of colors.
>
> Default System Theme:
> 	System Colors are loaded from the StyleSettings into the registry
> 	on the first startup, then after that an updated copy of the registry
>   	in the StyleSettings is used for the to-and-fro...(same as above)
>
> Problem: When the ColorConfig() constructor is called first, I try to write the colors into the
> 	 registry (via ColorConfig_Impl), but some listeners fire up, and the application crashes.
>
> If you know of any other approach to get a 2 way color communication between the registry and the
> VCLs, then please share. I thought of using the UNO api to access the registry values (seems possible),
> but then what's the point of having ColorConfig, I thought.
>
> Regards
> Sahil Gautam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20240611/0994d62b/attachment.htm>