TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
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) + 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...