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

[Sahil Gautam]

Hi, I missed the email for the last week, sorry for that. So the patch 
for gtk was pushed, and the one for QT will be out by tommorrow(+1 day). 
I spent quite some time with QStyle trying to get it to paint the UI 
elements, which complicated stuff, and took a lot of time, where it was 
just palette manipulation (mostly). Also I found that we handle the 
menubar separately, and it's not drawn via drawNativeControl(...). What 
is left for QT: - color customization for menus 
(menubar/window/button/etc done) - adding a listener for instant redraw 
- And some improvements on the GTK patch (on color coverage). Then I 
will start with windows vcl plugin. Can't say, but I would be very happy 
if I get done with windows vcl plugin before the mid term evaluation. In 
this time I tried setting up macos VM as well, and using quickget (as 
suggested by Ilmari), it was quite simple. (Though it took years to 
install neovim via brew, and I had to C^c it every time) Regards Sahil 
Gautam

On 6/11/24 11:44 PM, Sahil Gautam wrote:
> 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/20240628/aae65aa0/attachment.htm>