<http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a02076358a547bae8a9b596d9722a7cd2d46c34> "Windows registry configuration backend" added support to read configuration data from the Windows registry (see <https://wiki.documentfoundation.org/ReleaseNotes/4.2#Windows_Registry_changes>), but does so by creating intermediary XML files. <http://cgit.freedesktop.org/libreoffice/core/commit/?id=ecc617e797aa5ed329668114e54ec7ffa5c0e87b> "configmgr: support reading from a dconf layer (WIP)" (which does something similar for Linux dconf support), can now be used as a blueprint (modulo any bugs that new code invariably still contains) how to avoid intermediary files and directly feed into the configmgr's internal data structures.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
Re-evaluating the EasyHack in 2022 This enhancement is still relevant. The dumpWindowsRegistry() method in configmgr/source/winreg.cxx still creates and uses temporary xml files.
Hi everyone, I’ve assigned this bug to myself and have been digging into the relevant parts of the code. From what I understand so far: The method dumpWindowsRegistry() in configmgr/source/winreg.cxx is still responsible for creating intermediary XML files. There is a change from readDconfLayer() in readdconflayer.cxx to readLayer() in dconf.cxx. I’m trying to follow a similar path for the Windows registry backend. Before I go too deep into implementation: Are there any specific edge cases with the Windows registry (like key types or value conversions) that I should be careful with when bypassing the XML serialization step? Any pointers or confirmation that I’m heading in the right direction would be appreciated.
(In reply to Mohamed Zaghloul from comment #4) > Any pointers or confirmation that I’m heading in the right direction would > be appreciated. Yes, the plan would be to replace the current two-step `dumpWindowsRegistry` -> (temp file) -> `parseFileLeniently` approach so that `dumpWindowsRegistry` would instead directly modify the `configmgr::Data` instance, similar to how `readLayer` in `configmgr/source/dconf.cxx` does it for dconf. (When looking at the dconf case for inspiration here, note that the relevant code layout in `configmgr` has changed a bit since the initial commit <https://git.libreoffice.org/core/+/ecc617e797aa5ed329668114e54ec7ffa5c0e87b%5E%21> "configmgr: support reading from a dconf layer (WIP)") mentioned in comment 0.)
After reviewing the relevant files and considering the approach used in the `dconf`, I’d like to confirm my plan Processes and read registry keys recursively (`RegOpenKeyExW`, `RegQueryInfoKeyW`) Creates appropriate Node types (`PropertyNode`, `GroupNode`, `SetNode`) based on registry contents Handle special cases (`finalized`, external`, `nil` values) Integrate into Data tree Does this plan sound good, or are there any specific considerations I should be aware of?
(In reply to Mohamed Zaghloul from comment #6) > Does this plan sound good, or are there any specific considerations I should > be aware of? sounds good, but please just get started and create a Gerrit change, and details can then be discussed there
For sure https://gerrit.libreoffice.org/c/core/+/184174