https://bugs.documentfoundation.org/show_bug.cgi?id=152550
--- Comment #19 from Eyal Rozenberg <[email protected]> --- (In reply to Mike Kaganski from comment #6) > Remove any given property from a given ODF, and the program would need to use > some default. If there is a configurable setting for it, the default value > could (?) be obtained from there Or a hardcoded default should be used. Use > of > hardcoded default instead of a configurable setting has its own pros, like > making documents more predictable So, why not just "combine" the hard-coded defaults, configurable defaults, and template-based creation? When an LO module starts, and if there is no default template - create a template (with default-default values) for the user, and make it the default template. From then on, you only allow a replacement of the default template, never a simple "de-selection" into a no-default-template state. And no more use of registrymodifications.xcu for any of this stuff. Benefits: 1. The "root defaults" are fully configurable (not just fonts - everything). 2. No need for special UI for editing the "root defaults" - you set them by editing the default template. 3. If a user hasn't touched the default template file, then they're using those hard-coded defaults - which have simply been copied into the template. 4. Can keep the hard-coded defaults out of the code: Just have a default-default-template file, part of the LO distribution but not in the editable templates directory (or hide it inside an .so / .dll or whatever). So, no code paths involving hard-coded values, just a check for existence of a default template. 5. Can forget about that part of the "registry" with the configurable defaults. Detriments: 1. It's slower to use a template than hard-coded values. But - we already some configurable defaults... 2. Some may argue that the specific default font settings we now have are more accessible to novice users then locating the default template, opening it for editing, and making changes to a bunch of default styles. 3. Transition from current scheme of things may be a bit confusing/inconvenient, may have some tombstone definitions in the registry etc. -- You are receiving this mail because: You are the assignee for the bug.
