From The Document Foundation Wiki



    Feb 19, 2016; 5:44am Jan Holesovsky-4
    Minutes of the Design Hangout: 2016-02-05
    * Present:  **Kendy, Heiko, Stuart, Samuel, Tomaz, Jay, Jan-Marek** (as recollected - Stuart)
    * 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)
        + 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ó)
        + Switch to "Source Sans Pro" with fallback to "Liberation Sans"
        + 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
            + 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...