Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Jul-31

[paul hofseth <paul@xxxxxxxxxx>]

sirs,

I occasionally look at your dialogues and at times misguidedly complain 
about program stability rather than lack of "bells and whistles" .

I do realize that your task is dealing with the user interface and not 
with the data mechanics, but do hope that you have communication lines 
that concern program usefulness-.

This time I am sorely tempted to comment on the disability of reading 
monopolistic texts in docX format even if it lies outside your remit.

When working with our new book i have discovered a msjor annoyance when 
my co-authors use microsoft or apple. Black text on black background is 
not enlightening in any sense of the word.

p.

Den 01-08-2024 16:33, skrev Csongor Halmai:
> Hi Heiko,
>
> you wrote this:
>
>    + necessary if the app DPI differs from the screen DPI (Csongor)
>
> but I didn't say this.
>
> I meant in my comment that this feature would be useful when you want 
> to see more information than the resolution of your screen (and your 
> eyes) allows. You could magnify the region of interest (ROI) while you 
> still can see the big picture as well.
>
> I created a mimicking screenshot in GIMP how I think it should look: 
> https://i.ibb.co/WW0WsxC/magnifier-sample.png
>
> Disclaimer: for the screenshot, I used the Spherize filter of GIMP, 
> which is geometrically not identical to a magnifier lens but shows well 
> enough what I would like to see.
>
> In order to not hide anything from the underlying screen, it is 
> essential that the center of the circle shows things larger than their 
> original size but at the same time, around the edge, things look 
> smaller. This way, the magnifier doesn't cover anything, just shows 
> some distortion around the edges.
>
> A realistic lens effect can be seen here: 
> https://youtu.be/XtCW-axRJV8?t=271
>
> I think this would be such a useful feature that it should be supported 
> at operating system level.
>
> Csongor
>
>
>
>
> On 1/08/2024 04:56, Heiko Tietze wrote:
> > Present: Sahil, Eyal, Heiko
> > Comments: Mike, Justin, Stephane, Stuart, Cor
> >
> > Tickets/Topics
> >
> > (Suggested bump-up (Eyal):
> >   * Cell selecting fat border looks ugly especially if you selected 
> > some
> >     cell range, it also can block content in other cells
> > https://bugs.documentfoundation.org/show_bug.cgi?id=161709
> >     + Rafael: Made commits to improve the cosmetic situation, consider
> >       the bug fixed.
> >     + Rafael: This was done to resolve 143733, which requested the
> >       rectangle not cover the active cell
> >     + Heiko: Suggest accepting the current situation for now
> >     + Eyal: Serious degradation of UX - text in surrounding cells
> >       partially hidden, can make one value appear as another due
> >       to hiding.
> >     + Eyal: Suggest back-out of changes to before 143733, for now, and
> >       reconsideration. Must fix this for 24.8 release.
> >     + Eyal, Mihai, Rafael, Roman, flm2: Excel active cell rectangle 
> > looks
> >       nice
> > => please discuss at Bugzilla or the mailinglists (Heiko)
> > )
> >
> >   * No option to automatically indent multiline list entries to align
> >     with numbering followed by space
> >     + https://bugs.documentfoundation.org/show_bug.cgi?id=156071
> >     + line up *subsequent lines* of each list entry, see c12
> >     + no good example for the necessity (Mike, Cor, Heiko)
> >     + mandatory to have this as cross-platform feature (Justin, Cor)
> >     + A tab is, in the general sense, an inherently flawed solution,
> >       because once your number exceeds the tab width - you'll overflow
> >       and the alignment will be messed up (Eyal)
> >     + Request is reasonable (Eyal):
> >       + Follows a different aesthetic principle: Fixed amount of space
> >         between number and paragraph content v-start rather than 
> > uniform
> >         content v-start across all paragraphs
> >       + Should be implemented via a paragraph feature to move all 
> > lines
> >         further in to respect the maximum constraints on each 
> > individual
> >         line (e.g. numbering, wrapping around frames etc.), ensuring
> >         that the paragraph's v-start is uniform across all lines, 
> > without
> >         having to set it explicitly using indentation and/or tabs.
> >       + Should be usable even without numbering being active (an 
> > aspect
> >         of a paragraph's style)
> >     + requires probably also to start a list from any number (Heiko)
> >     + MSO does exactly the same as we do (Heiko)
> >     => comment
> >
> >   * Tab stop of list contents increases then decreases in default
> >     Roman numeral list, looking messy
> >     + https://bugs.documentfoundation.org/show_bug.cgi?id=162133
> >     + Microsoft Office forces right alignment for Roman numerals, 
> > often
> >       with horrible results (Justin)
> >     + right-alignment is not the right solution => WF (Stephane, Cor)
> >   => solution follows bug 156071
> >
> >  * PIVOTTABLE: Formating Pivot Tables
> >    + https://bugs.documentfoundation.org/show_bug.cgi?id=51732
> >    + double-click brings up the Data Field dialog currently, add
> >      a context menu (Stephane. Cor)
> >    + perhaps more obvious via push button? (Sahil)
> >    => provide a context menu for the functions
> >
> >  * Magnifier Tool for a quick overview and spot zoom into a document
> >    in Multiple-page view
> >    + https://bugs.documentfoundation.org/show_bug.cgi?id=162101
> >    + magnifier is always just a click away, eg. Win + +/- on KDE
> >    + bug it does not render again with a higher resolution (Heiko)
> >    + "magnifier" would be an excellent feature *in general* (Stuart, 
> > Cor)
> >    + necessary if the app DPI differs from the screen DPI (Csongor)
> >    + duplicates / relates to bug 101646 "UI option "Scaling" was 
> > removed"
> >      with a lot duplicates itself
> >    + weird relation to multi-page view; suggest to do with low
> >      priority (Eyal)
> >    => comment