https://bugs.documentfoundation.org/show_bug.cgi?id=157276
Michael Weghorn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Michael Weghorn <[email protected]> --- (In reply to Heiko Tietze from comment #4) > We discussed the topic in the design meeting. > > Looking into the code it seems the presenter console has a lot of room for > customization. It should be possible to set background image/color, font > size, name, color etc. via registry - and consequently allowing to set a > theme per extension. > > The fallback is however to use Tahoma. > > PresenterTheme::FontDescriptor::CreateFont() { > ... > if (msFamilyName.isEmpty()) > aFontRequest.FontDescription.FamilyName = "Tahoma"; > > And the majority of participants agree on the request to use the system font > as long nothing is defined per theme. I agree using the system font by default makes sense. Are all of these customization options considered relevant, i.e. something that needs to be kept in the long run? I noticed this and much other complexity (like UNO abstraction everywhere) while looking into Presenter Console code as part of some accessibility work. I was wondering whether there is actually a real need to be able to customize all those things (fonts for the single panes, icons for each corner of the selection rectangle in the "Slides" view,...) or whether that was mostly done this way in the past because direct access to the standard VCL (and other) mechanism wasn't available for the Presenter Console back then because it wasn't part of LO core, but an extension, see commit commit ea91c7d90d74e1ca039ba669b5d3e14fa359c0fa Author: Stephan Bergmann Date: Wed Nov 21 17:19:28 2012 +0100 Turn presenter screen from bundled extension to plain code that changed this long time ago. At the moment, Presenter Console has its own implementation of a scrollbar, all buttons,... instead of using the standard VCL (or even weld) widgets, which has the side-effect of not looking like the rest of the UI, not supporting accessibility properly yet, being extra effort to maintain,... Switching that to use standard VCL/weld widgets would certainly be quite some work in any case (and I'm not volunteering to do it at this point in time). But being able to drop that customizability for all kind of "random" things would certainly help reduce complexity after all, and if that's considered a reasonable approach, would also make it easier to implement single feature requests like this one. What do you think? -- You are receiving this mail because: You are the assignee for the bug.
