https://bugs.documentfoundation.org/show_bug.cgi?id=166444
--- Comment #14 from V Stuart Foote <[email protected]> --- (In reply to Mateusz Wlazłowski from comment #11) > > I am talking about those two menus Styles (Alt + 2) and Styles inspector > (Alt + 6) > > I agree that they both serve a different purposes, nonetheless, I would > personally expect both menus to update at the speed of the cursor OK thanks. But let's use the correct project terminology, those are top level titled Sidebar "Decks", each with distinct "Content Panel" (that may have a title for the panel) holding control widgets. https://wiki.documentfoundation.org/File:LO-HIG_SideeBar-Terminology.png The 'Styles' deck (<Alt>+2 or <F11>, for.uno:SidebarDeck.StyleListDeck) as compared to the 'Style Inspector' deck (<Alt>+6, for uno:SidebarDeck.InspectorDeck). The <alt>+[1-9] accelerators are assigned to each deck. And each deck will "handle" its cursor focus as appropriate to the control enabled. Giving us two text modes to consider UX of cursor handling and UI update: 1.) Toggling between <Alt>+2 and <Alt>+6, with edit cursor focus already into a document a paragraph, the UI changes content panel equally fast. 2.) Making a mouse pointer change of the edit cursor focus (between paragraphs of different styles) *is a tic slower*. Movement cursor <U/D> fire a focus event, so they are consistent with a pointer change and mouse click. With reasonable system HW configured appropriately [1], IMHO neither is objectionably slow to the point of affecting UX, even on older less capable hw. (In reply to Mateusz Wlazłowski from comment #13) > There is actually a flaw with the current implementation of update of the > style inspector. Sorry, don't see an implementation issue with keyboard cursor movements, or mouse pointer clicks, for the Style Inspector deck moving between Paragraph objects. It toggles as soon as focus event fires and the content panel can be loaded. =-ref-= [1] So the skia rendering paths set to Raster rendering, with device/os approriate drivers. Skia lib Vulkan rendering is os and Hardware dependent, unfortunately our defaults are to enable Vulkan rendering which should fall back to skia raster framing for unsupported hw (improved at 25.8). But some hw driver combos sneak by and LO ends up choking on newer LO builds against old hw, or completely unsupportable hw like a VMSVGA device. -- You are receiving this mail because: You are the assignee for the bug.
