[Libreoffice-ux-advise] [Bug 139474] Style inspector not showing Direct Formatting in Comment box
https://bugs.documentfoundation.org/show_bug.cgi?id=139474 Dieter changed: What|Removed |Added Whiteboard| QA:needsComment| CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #2 from Dieter --- ... and ask Design-Team cc: Design-Team -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90507] Tools - AutoCorrect - Apply converts non-empty "Default Paragraph Style" paragraphs to "Text Body" PS --even when no [M] options are selected
https://bugs.documentfoundation.org/show_bug.cgi?id=90507 --- Comment #11 from V Stuart Foote --- (In reply to sdc.blanco from comment #10) > ... > But this potentially helpful behavior "collides" with the issue in bug > 59034, namely that (many) [M] options only work with Default PS. > ... Yes I would agree, and would also note the 'Replace Custom Styles' has some interesting behavior as well. Not clear if those are relative to the Standard Template, or to the Template used to create the document--but its action when applied is to remove other PS and revert to something present in the template. So, makes me wonder exactly what is considered a "custom" style as related to the AutoFormat in (editeng/acorrcfg.hxx & acorrcfg.cxx)? I've gotten lost several times now trying to trace it out in Opengrok. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 139522] Don't retain image position when cut/pasting exclusively the image
https://bugs.documentfoundation.org/show_bug.cgi?id=139522 --- Comment #4 from S.Zosgornik --- Paste an image without its formatting attributes can already be archived by either Edit->Cut\Copy->Edit->Paste Special->Paste Special... or Right Click->Cut\Copy->Right Click->Paste Special->More Options Unfortunately, there isn't any option to keep the file type yet. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90507] Tools - AutoCorrect - Apply converts non-empty "Default Paragraph Style" paragraphs to "Text Body" PS --even when no [M] options are selected
https://bugs.documentfoundation.org/show_bug.cgi?id=90507 --- Comment #10 from sdc.bla...@youmail.dk --- (In reply to V Stuart Foote from comment #9) > It is actually pretty handy "feature", but it needs documentation of its > current state Thanks for interesting archeology. Have been trying to improve the documentation, but will appreciate any help I can get. >From one PoV, whether intended or not, it could look like AutoCorrect was designed to make it easier (or to encourage) shifting over to Styles-based document production. This bug 90507 notes that Tools - AutoCorrect - Apply automatically changes all Default PS to Text Body (requested or not). [This has been documented since at least 2015, but now I have tried to clarify the "note" about this]. (Bug or not, this current behavior is consistent with promoting a styles-based approach, and makes it "easy" to get rid of unstyled (default) paragraphs from a document.) Bug 95433 notes (and objects to) that using choosing "Apply Styles" in [T] also changes Default PS to Text Body after Enter is used. (but is that a bug?, especially when user has chosen "Apply Styles"?) In both cases, these "bugs" could be seen as features to help insure the avoidance of unstyled paragraphs appearing in a document. But this potentially helpful behavior "collides" with the issue in bug 59034, namely that (many) [M] options only work with Default PS. In short, at present, this (speculative) "helpful" behavior described in bug 90507 and bug 95433 undercuts the possibility to make post-facto auto-correcting clean-up in a document (unless one is willing to remove all non-default PS). -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 139701] UI: Underline split button in regular toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=139701 --- Comment #4 from S.Zosgornik --- +1 the drop down arrow also helps to distinguish to the next right set of tools -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 135895] Improve documentation about numbered lists without a list style (see comment 15)
https://bugs.documentfoundation.org/show_bug.cgi?id=135895 --- Comment #29 from sdc.bla...@youmail.dk --- (In reply to kitchm from comment #27) > While there are times when a person may do it as you described, many people > do not. Precisely. That is why I have asked how you have done it, so that I do not have to keep guessing. There multiple ways to use LO. The documentation seeks only to document those ways, not to push users into a particular workflow. The procedures I described in comment 26 were meant to reveal something about the behavior of LO (and then to ask the design team for feedback about whether it was intended). So let's look at your intended workflow > Where I want an outline or list, I start with > selecting the outline or list first, and only then do I add text. For example, would this correspond to what you do? A. Select Numbering First, Then add Entries 1. On Formatting bar, use dropdown menu in "Toggle Numbered List" icon to select 1),2),3) numbering scheme. Actual and expected result: 1) appears in document 2. Make an entry, then press Enter 3. Repeat for second line 4. Repeat for third line, but press Enter twice after third line. Result: There is a 4) after the first Enter, and then an empty paragraph after the second Enter. 5. On Formatting bar, use dropdown menu in Toggle Numbered List to select another numbering scheme (e.g., 1.2.3.) Result: The empty paragraph changes to 1. 6. Make three entries, without pressing return after the third. 7. On Formatting bar (or Bullets and Numbering bar), use dropdown menu to change numbering scheme to Roman numerals. Actual and expected result: Numbering scheme on second list changes, but the first list does not change. In other words, I have tried to follow your way of doing things (or at least I have guessed as closely as your description permits), but have not encountered the initial problem that you described. Now here is another way that (sort of) follows your (general procedure) but does produce the problem you have indicated. B. Select Numbering First, Then add Entries 1. Format > Lists > Numbered List 2. Make three entries. 3. Then add a few blank lines after the Numbered List. 4. Format > Lists > Numbered List Actual result: 4. appears in document (with a few blank lines above it, and the initial list with three entries, 1. 2. 3.). 5. Continuing from the 4., make some more entries in this "second" list. 6. (then I followed steps 4 to 6 in comment 0, namely, select the "list" below the blank lines, used dropdown box in the Bullets and Formatting toolbar to select a different outline type, and now both lists use the same numbering scheme, which is the problem that you reported. (You did not mention "Restart numbering" in your initial report, but, I suspect it is involved in someway in your workflow, which is creating the problem that you report. For example, in version B, if we apply "Restart Numbering" after step 4 and before starting step 5, then it looks like the "second list" is separate from the first, but when you change the numbering scheme for the "second list", then "first" list also changes. Is that what you did? If you have used yet another procedure to produce the problem that you reported, then please describe it. Thanks. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90507] Tools - AutoCorrect - Apply converts non-empty "Default Paragraph Style" paragraphs to "Text Body" PS --even when no [M] options are selected
https://bugs.documentfoundation.org/show_bug.cgi?id=90507 V Stuart Foote changed: What|Removed |Added Version|unspecified |Inherited From OOo -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90507] Tools - AutoCorrect - Apply converts non-empty "Default Paragraph Style" paragraphs to "Text Body" PS --even when no [M] options are selected
https://bugs.documentfoundation.org/show_bug.cgi?id=90507 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #9 from V Stuart Foote --- The FN_AUTOFORMAT_APPLY is ancient StarOffice handling by SvxAutoCorrCfg, not surprised that its linkage in AutoCorrect GUI for existing (the Modify 'M' checkbox) only applies between 'Default' and 'Text Body' PS. So, it requires user to assign selection to 'Default' PS for the AutoCorrection to apply to existing text--and that the resulting paragraph receives the 'Text Body' PS. Enhancement would be to provide user choice of target PS conversion, or perhaps to not force the conversion at all--an option on the AutoCorrect dialog. It is actually pretty handy "feature", but it needs documentation of its current state, and absent refactoring probably adjustments in the UI (e.g. some of the 'M' checkboxes should be listed as applicable only to 'Default' paragraph style ). -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 135895] Improve documentation about numbered lists without a list style (see comment 15)
https://bugs.documentfoundation.org/show_bug.cgi?id=135895 --- Comment #28 from kit...@tutanota.com --- By the way, have you noticed any other times where the simpler, common sense approach is not used in the software? Does the documentation force the user to conform to the software, or does the software serve the user's needs? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 135895] Improve documentation about numbered lists without a list style (see comment 15)
https://bugs.documentfoundation.org/show_bug.cgi?id=135895 --- Comment #27 from kit...@tutanota.com --- @sdc.blanco, I think I see a flaw in your reproduction. I do not create a document as you did. Where I want an outline or list, I start with selecting the outline or list first, and only then do I add text. That is the way we were trained from the 1980's. It is a reasoned and common sense approach. While there are times when a person may do it as you described, many people do not. Perhaps this will show the difference in documentation and/or usage. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 139701] UI: Underline split button in regular toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=139701 andreas_k changed: What|Removed |Added CC||kain...@gmail.com --- Comment #3 from andreas_k --- +1 for .uno:Underline in the Toolbar -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 134724] UI - Find in Calc fails when a formula refers to a cell in another sheet's pivot table
https://bugs.documentfoundation.org/show_bug.cgi?id=134724 --- Comment #7 from Eike Rathke --- First off, the "Formulas" vs "Values" label is a terrible naming, but it's probably due to the terrible naming that Excel introduced and its users are used to. What it actually does and the difference is that Formulas searches the *cell content*, be it literal strings, numbers or formula expressions; and Values searches the unformatted *display value*, literal strings, numbers or results of formula expressions. Now if the default in Find&Replace was Values (display value) instead of Formulas (content), a Replace operation would destroy any formula expression where the result matched the Find, i.e. Find the result display value but Replace the formula expression that calculated it => the formula is lost and replaced by the literal replacement value. You certainly don't want that to be the default. Specifically, even worse, you don't want to be the default that a Find would match either the content or the result. The Find&Replace dialog remembers the Values/Formulas setting though and equally may trap the user in the next operation once Values was used. The Find toolbar only searches in cell content (Formulas). Confusingly the Formatted Display option searches displayed strings of *literal* cell content and thus *ignores* formulas and their results (which is logical, but..) Personally I'd always expect a quick find (i.e. toolbar) to search content instead of display values, but YMMV. Though I'd also expect that if I check Formatted Display then formula results were searched as well, not the formula as cell content. For both the toolbar and Find&Replace dialog. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
