[Libreoffice-ux-advise] [Bug 155016] New feature: set the source/scope of AutoComplete search
https://bugs.documentfoundation.org/show_bug.cgi?id=155016 QA Administrators changed: What|Removed |Added Ever confirmed|1 |0 Status|NEEDINFO|UNCONFIRMED -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155016] New feature: set the source/scope of AutoComplete search
https://bugs.documentfoundation.org/show_bug.cgi?id=155016 --- Comment #4 from QA Administrators --- [Automated Action] NeedInfo-To-Unconfirmed -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151330] Add option for Optimal row height to ignore hidden columns
https://bugs.documentfoundation.org/show_bug.cgi?id=151330 Stéphane Guillou (stragu) changed: What|Removed |Added Keywords||needsUXEval Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org Version|7.5.0.0 alpha0+ |Inherited From OOo Blocks||108364 Whiteboard| QA:needsComment| Status|UNCONFIRMED |NEW --- Comment #1 from Stéphane Guillou (stragu) --- Thanks Timur, sounds sensible. Same in OOo 3.3 and: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2e57755f72907e4bb604a8ba32edbd6c253ee57c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded UX team, what would be the best UI for that? Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108364 [Bug 108364] [META] Table/Row/Column/Cell management function bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155016] New feature: set the source/scope of AutoComplete search
https://bugs.documentfoundation.org/show_bug.cgi?id=155016 --- Comment #3 from Tylla --- Thank you guys for the prompt reply! As Heiko already pointed out Validity is for a different workflow. While the argument about the plenty of options is true and agreeable, the other one about all the other spreadsheet tools is way weaker. A feature shouldn't be considered on the base that some other software has it or not, but solely on the base whether if it makes sense and if it is feasible or not. <> :))) (actively trying not to offend anyone) As about the repeating/reused data: I wrote the 4 member option list as a logical expansion of my original need. Maybe I overshot the target a little bit. Sorry! So if I want to present my strict needs, that's about getting AutoComplete results from the same column but different worksheet, so the two options would be: "Current column of current sheet (default)"/"Current column of all sheets" Btw in the past I had several times the need to use the other two options as well, but I can't precisely recall those cases, so let's skip that for now. :) Thank you for taking the time to think about my idea, maybe it takes root in one-form-or-another. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155044] Rename Format - Description menu item
https://bugs.documentfoundation.org/show_bug.cgi?id=155044 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=39 ||558, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=96 ||355 --- Comment #7 from V Stuart Foote --- (In reply to Gabor Kelemen (allotropia) from comment #6) > > I can not imagine that most of non-IT educated users (lawyer, public > administration clerk, teacher, economist) know "alt text" from W3C or about > the existence of W3C at all. > And equally we could question why the Name..., and Description... widgets have even made it onto the Format menu--and are not present by default on the context menu for the objects supporting them. [1] The casual user has no interest in preparing accessible documents and doesn't. But as a document authoring tool (providing ODF svg:title and svg:desc) we need to encourage and facilitate accessible documents--hence the presence on the Format menu and context menus active for objects. And suggestions like bug 39558 (to prompt to add title and alt/longdesc attributes) and bug 96355 (for a consistent Properties... dialog). =-ref-= [1] context menu cleanup of bug 81132 that resulted in bug 101193 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #26 from V Stuart Foote --- 64 points = .89 in --or-- 2.260 cm But I kind of doubt our STD_COL_WIDTH (of 64 pts) and STD_ROWHEIGHT_DIFF (of 23 pts) are being calculated the same way on Excel where UI works with character units (default of 8.43 ch and 15 pt height). Also, folks do realize that the "default" cell on MS Excel is formatted with 11 point Calibri, while in LibreOffice Calc we use 10 point Liberation Sans? LO fits 11 at 10pt "12345678901" MS fits 8 at 11pt "12345678" Compounded by the fact that few os/DE actually work at 100% scaling. Windows for example defaults to 125% scaling on a Full HD 1920x1080px display--so it is a moving target unless we move to a character "ch" based UI. Point is a user can adjust their environment to match an Excel session when working in OOXML, but for our ODF originated sheets there is no real point. -1 for any change from current LO defaults pursuing interoperability. It would not offer any real relief as we are unlikely to adopt a UI oriented to character counts for Calc column widths. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153847] Change label for .uno:InsertIndexesEntry and label and tooltip for .uno:IndexEntryDialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153847 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||115596 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=115596 [Bug 115596] [META] Labels of UNO commands bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #25 from Mike Kaganski --- (In reply to Eike Rathke from comment #22) > Sane proportional fonts have monospaced digits. ... which is not what ady talked about - the phrase was that "the width for digits is not the same as some *other set of characters*". (In reply to Eyal Rozenberg from comment #23) > Well, Times New Roman and its brother, Liberation Serif, are not part of > that sane group... and that's the case also for Arial and Liberation Sans. Huh? These fonts do have the same width for digits. > I vaguely recall LO phasing them out in favor of Carlito and Caladea, but that > doesn't seem to have happened very earnestly. LO? TNR and friends are MS fonts, and Carlito at al are a metric-compatible substitutes for a *different* set of MS fonts. LO is not in a position to phase fonts out from users' documents, it can only provide descent substitutions (which it does, both for older and for newer MS fonts). [/OT] -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #24 from Eike Rathke --- Liberation Sans digits appear perfectly monospaced in Writer and Calc. Anyway, this is getting off-topic. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #23 from Eyal Rozenberg --- (In reply to Eike Rathke from comment #21) So 54 points is nice and round. If we were to go with 0.8", it would be 55.6 points or 1112 twips. (In reply to Eike Rathke from comment #22) > Sane proportional fonts have monospaced digits. Well, Times New Roman and its brother, Liberation Serif, are not part of that sane group... and that's the case also for Arial and Liberation Sans. I vaguely recall LO phasing them out in favor of Carlito and Caladea, but that doesn't seem to have happened very earnestly. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #22 from Eike Rathke --- (In reply to ady from comment #17) > Let's not forget that the default font is not mono-spaced (i.e. not > fixed-width), so the width for digits is not the same as some other set of > characters. Sane proportional fonts have monospaced digits. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #21 from Eike Rathke --- For understanding the values: Measurement of cell widths is in typographical points (1/72 inch) and the internal calculation is in twips (twentieth of an inch point, 1/20 point = 1/1440 inch) The current value is 64 points or 1280 twips, which is 0.8" or 2.25775cm. The proposed value would be 54 points or 1080 twips, which is 0.75" or 1.905cm. The nearest value to 20mm would be 57 points or 1140 twips, which is 0.79166" or 2.01081cm. If we defined cell widths directly in twips instead we could get nearest to 20mm with 1134 twips, which is 0.7875" or 2.00025cm or 56.7 points. A rather odd value for typography.. and quite likely provoking round-off errors in layout. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155044] Rename Format - Description menu item
https://bugs.documentfoundation.org/show_bug.cgi?id=155044 --- Comment #6 from Gabor Kelemen (allotropia) --- (In reply to V Stuart Foote from comment #4) > I would agree with Gabor, in standard technical English it should be > "Accessible Description..."--but in reality the "alt text..." is well known > from W3C "alt attribute" and "longdesc attribute" alternative text > practices and would be equally acceptable. I can not imagine that most of non-IT educated users (lawyer, public administration clerk, teacher, economist) know "alt text" from W3C or about the existence of W3C at all. In the Hungarian localization of Word they translated "Alt text" as "Replacement text". But that's just my bias. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #20 from Roman Kuznetsov <79045_79...@mail.ru> --- The "problem" has a very simple solution using default template customizing. I still don't see any real reason to change the default cell size -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #19 from Mike Kaganski --- (In reply to Heiko Tietze from comment #18) > Default of STD_COL_WIDTH is set to 64 twips in sc/inc/global.hxx. No, to 64 *points* (point is 1/72 in) (and that value converts to twips for internal use). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #18 from Heiko Tietze --- Default of STD_COL_WIDTH is set to 64 twips in sc/inc/global.hxx. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #17 from ady --- (In reply to Rafael Lima from comment #12) > I like the idea of 1.905 cm (0.75"). May I ask, why? Is it the amount of digits (9, without separators)? Is there any non-subjective reasoning? Let's not forget that the default font is not mono-spaced (i.e. not fixed-width), so the width for digits is not the same as some other set of characters. Users with accounting requirements might like some default, whereas engineers might prefer some other default width. The current calculation accuracy of 15 digits might sound ideal for some users to match the default width. (In reply to Mike Kaganski from comment #15) > Either we get per-locale default That would result in users seeing different areas according to their locale, which might make it unnecessarily more difficult to reproduce some behavior, either between users sharing some document, or for some bug reports. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154715] "Edit Fields" for cross-reference fields should open on the type, format, and selection of the inserted field
https://bugs.documentfoundation.org/show_bug.cgi?id=154715 sdc.bla...@youmail.dk changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #5 from sdc.bla...@youmail.dk --- (In reply to Buovjaga from comment #4) > Just a note: I was looking at the type to be specific. Will ask UXEval in relation to general issue. Also, maybe this is an EasyHack -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #16 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #15) > Note that, in case there's a decision to go with a change, it is absolutely > bad to make a global default in inches, which are used by minority of the > population of the world. I agree in principle. We don't use inches in Palestine/Israel. The thing is that the current width is close to an inch, so it seemed more intuitive to think about it in those terms. But 2cm, 1.9cm is also fine by me. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150165] Visual Aids for Impress: make all objects' outlines visible while moving an object; always show non-printable table borders as in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=150165 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #6 from Heiko Tietze --- So let's do it. (In reply to Regina Henschel from comment #5) > If you have already accessed the object, it is too late. Not if the main focus is on positioning. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #15 from Mike Kaganski --- Note that, in case there's a decision to go with a change, it is absolutely bad to make a global default in inches, which are used by minority of the population of the world. Either we get per-locale default, or we create a *metric* global default (noting that even where inches are used as a primary unit, metric system is also usable and standardized). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154878] I added my own autocorrection and it requires an extra button press to change it
https://bugs.documentfoundation.org/show_bug.cgi?id=154878 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||0445 --- Comment #2 from Heiko Tietze --- You can add it to the replacement table (mind the language above; it applied only in this context) but all replacement text need a finishing space (for gtk3 see bug 140445), tab, or enter. Otherwise you cannot get the arrow (--> = →), for instance. What you want to achieve is implemented per autocorrect > options > replace dashes, see https://help.libreoffice.org/latest/en-US/text/shared/01/06040100.html. Side note: In case of just a question you might get better and faster replies at https://ask.libreoffice.org/. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #14 from Heiko Tietze --- https://fosstodon.org/@libodesign/110275158368343954 -- You are receiving this mail because: You are on the CC list for the bug.
