From The Document Foundation Wiki
Jump to: navigation, search



Present: Stuart, Muhammet, Tomaz, Thomas, Heiko

* HIG about floating widgets
   + Escape to close the floating widget?
   + Heiko, Pedro -1, Alex, Cor, Thomas +1
   + Esc might be pressed accidentaly, toolwindows are also windows and dont act on esc, and there is likely never
     focus on this widget as input is applied immediately (Heiko)
   + today ( on Windows) esc doent have an effect neither ctrl+f4 or any other shortcut
   + F6 cycles through menu, toolbars, sidebar and flaoting windows
   + help says, in general, esc closes without applying changes (Stuart)
   => let's go with escape to close the floating widgets
    + old: Floating controls are non-resizable, stay on top of the app, and don't close per escape.
    + new: Floating controls are non-resizable, stay on top of the app, and close per escape.

 * Selection of adjacent columns in Calc
   + no idea about how the selection of zeros works (Heiko)
   + resolved as WFM/NAB
   + but 
     Better wording for "Use legacy cursor movement behavior when selecting"
   + discussed in the design meeting 2017-Nov-09:  
    * Wording for legacy cursor movement
    + Old "Use legacy cursor movement behavior when selecting",
    + "legacy" isnt useful unless LO previously had this behaviour
    + Option 1 "Excel style selection" (Cor)
    + "style" not suitable word to describe behaviour
    + Option 2 'Excel multiple cell keyboard selection' (Yousuf)(Stuart)
    + Option 3 "Excel compatible selection for multiple cells" (Heiko)
    + Option 4 "Excel-like selection for multiple cells" (Thomas)
    + Option 5: "Convenient selection" (and select by default) (Heiko)
    => take option 2
  + Option 6: "Legacy selection mode" (Muhammet)
  + Option 7: "Compatible selection mode" (Muhammet)
   => "Position cell reference with selection" (Tomaz, Stuart)

 * Keyboard shortcut to move cols/rows
   + go with ctrl+up/down (crogers)
   + Option 1: NAB/WFM because rarely used and dangerous action
   + Option 2: one-hand mode activated by a shortcut, e.g. ctr+foo, which makes cursor moving rows/cols
     + vi'ish solution
   + Option 3: ordinary shortcuts, but not simply ctrl+cursor rather ctrl+alt+cursor
     + ctrl+alt+cursor is used in Gnome shell for workspace
   => no good solution; but option 2 sounds easier to implement and most flexible
     + after switchting into movement mode we can act on row/col independentely from selection
       (left/right select the col, top/down the row) making both possible at once
     + alternatively the movement could be done based on the selection
     + as a compromise do the second if there is a selection but otherwise the first

 * Table line styles are not visible (Muhammet)
   + The first patch merged turns white lines to black, which makes them very hard to see on dark theme, and
     almost invisible on high-contrast theme
   + The second patch involves some trickery, and brings some improvements, but still not satisfied with the result
     (try different themes with different colors to see what I mean)
   + Why do we bother changing the color of the lines in the box?
      + What if we stop doing these tricky things, and make the style box just show the style and the color box
        just the color? (Just like the "Border Color" and the "Border Style" elements do in the Table toolbar)
        + It will be consistent with the rest of the UI
        + It will be always perfectly visible
        + We can also open an enhancement request to add a preview to the Borders tab of Table Properties dialog,
          like the one in the "Insert Table" dialog in Writer.
      + would require a preview that in fact we have under user-defined (line arrangement)
      + alternatively, show the line on a dedicated self-drawn rectangle similar to color dropdowns
    => go with the simple black line ignoring width and color