Minutes of the Design Hangout: 2016-02-05

* Present: 

* Sidebar max width (Jan-Marek)
 
    + The side bar currently has a maximum size limit
    + We would need more size to implement the WollMux form editor as a LibreOffice sidebar
        - On normal monitor, this means about 30-50%
    + Probably LO will get bug reports, if the sidebar is as large as the window and people can't 
edit?
        - Currently the side bar just collapses, if the whole Window get's smaller then the bar
        - You can already hide the whole edit window
        - It already decollapses, if the window becomes larger then the sidebar width again
    + 1. Idea:
        - increase the maximum limit
    + 2. Idea:
        - set a minimal size for the edit window and let the sidebar freely use the rest
        - already collapses the side bar, when the minimum is reached
        - preferred solution for us (Jan-Marek)

    + so only the maximal size, but not changing the default, right? (Kendy)
        + yes, the max size is the concern, currently the default is the minimum where widgets fit 
(Jan-Marek)
    + 2-3 bug reports currently open (Jay)
        + involved minimal and maximal size (Jay)
        + extending over the current max size does not give much additional value (Jay)
        + https://bugs.documentfoundation.org/show_bug.cgi?id=92317
          https://bugs.documentfoundation.org/show_bug.cgi?id=83526
          https://bugs.documentfoundation.org/show_bug.cgi?id=91915
          https://bugs.documentfoundation.org/show_bug.cgi?id=90374
    + the user can already change the size of the side bar (Jan-Marek)
        + wanted to have fixed size for the sidebar (Jay)
        + the area is not utilized when too big (Jay)
    + sidebar not completely finished yet (Stuart)
        + the thing is - the sidebar wouldn't be bigger when the wolmux extension is not installed 
(Stuart)
    + when the user opens the document, gets an additional window (Jan-Marek)
        + formula edit entry in the extension (Jan-Marek)
        + like a kind of PDF editing, additional checking etc. (Jan-Marek)
        + but more stuff too - choosing documents etc. (Jan-Marek)
    + API in place for many things in the sidebar now (Stuart)

    + when we don't change the default, ie. it the sidebar gets bigger only when the extension
      is installed, that's fine for me (Kendy)
        + defined by the extension itself sounds fine to me too through api (Jay)
    + why don't you use dialog instead? (Heiko)
        + we actually discussed something similar previously - that the sidebar might be useful for
          functionality that we currenly have in non-modal dialogs (Kendy)
        + sidebar easy to abuse, be careful (Heiko)
        + the users want to see both the document and the functionality (Jan-Marek)
        + why that should be the an abuse, actually? (Jan-Marek)
            + the main functionality should not be in the sidebar (Heiko)
            + adds complexity to the sidebar, question of modality (Jan-Marek)
        + duplication is not a problem, no dialog planned (Jan-Marek)

    + in general, let's give freedom to the extension developers (Kendy)
        + we just need to make sure any random extension does not take over the entire LO :-) 
(Kendy)
AI:     + put together few screenshots to explain the needs a bit better (Jan-Marek)

* Impress Default font (suggested by Németh László)

    + https://bugs.documentfoundation.org/show_bug.cgi?id=97577

    + Switch to "Source Sans Pro" with fallback to "Liberation Sans"
    + https://gerrit.libreoffice.org/#/c/22124/

    + what is the reasoning for the change? (Kendy)
       + described in the bug...
       + changing the default might be critical, if the default isn't saved to the document 
(Jan-Marek)
          + Old problem was change of line color default in Writer from black to blue
            => all lines changed from black to blue

    + do we bundle the Source Sans Pro? (Kendy)
       + we do

    + I don't agree with the change (Kendy)
       + if at all, it should be done in the default template, not in the VCL.xcu (Kendy)
       + and - as a default, we need something metrically compatible with 'usual' fonts (Kendy)
       + whatever font, its Unicode codepoint coverage in the SEP (think Emoji's) becomes an issue 
(Stuart)

* Draw-related survey (Heiko)

    + might be interesting to have a survey about what the users actually use Draw for (Tomaž)
        + Heiko will have a look / think this through
    + https://docs.google.com/document/d/1W6aIpZhQo7j33f8W3p_nXLAd6tamwjtUxZFx77jArcU/edit
        + Will prepare a draft about the request to participate on the blog, create the survey and 
share all
          on the mailing list to get more opinions (Heiko)

    + people want better flow-chart support (Heiko)
        + and vector drawing tool
        + and other...