Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


* 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...


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.