[Bug 161020] Vertical Tab dialogs--initial size of the style dialog is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161020 Heiko Tietze changed: What|Removed |Added Priority|medium |high Severity|normal |major Keywords|needsUXEval |regression CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161030] Vertical Tab dialogs--width available for Tab name is too narrow with jumping view of Tab names
https://bugs.documentfoundation.org/show_bug.cgi?id=161030 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |regression Ever confirmed|0 |1 Priority|medium |high Severity|normal |major Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161031] Form creating is too niche to merit a main menu item visible by default
https://bugs.documentfoundation.org/show_bug.cgi?id=161031 --- Comment #1 from Heiko Tietze --- Maybe make it visible if the Design Mode is enabled? And move this item to the Edit menu. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161037] UNO Sidebar 'Hide' and 'Show' sidebar deck (splitwin) -- a new function (available for assigning a shortcut key to it)
https://bugs.documentfoundation.org/show_bug.cgi?id=161037 Heiko Tietze changed: What|Removed |Added Keywords||accessibility CC||m.wegh...@posteo.de --- Comment #2 from Heiko Tietze --- Sounds like over-engineering but probably needed from the a11y POV. Michael, what do you think? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160951] Navigator: Present sort options per radio button
https://bugs.documentfoundation.org/show_bug.cgi?id=160951 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists | |.freedesktop.org| Keywords|needsUXEval | --- Comment #1 from Heiko Tietze --- I hope this is accepted as UX improvement ;-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158874] Want MS-Word like auto-formatting of beginning of list item
https://bugs.documentfoundation.org/show_bug.cgi?id=158874 --- Comment #14 from Heiko Tietze --- Confirming the nifty function in MS Word: colon, semicolon, question and exclamation mark, hyphen are stop tokens, at least. Works with DF and CS. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161047] Vertical Tab dialogs--Page style dialog is too small and not resizeable
https://bugs.documentfoundation.org/show_bug.cgi?id=161047 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval |regression Severity|normal |major Priority|medium |high -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161047] Vertical Tab dialogs--Page style dialog is too small and not resizeable
https://bugs.documentfoundation.org/show_bug.cgi?id=161047 --- Comment #2 from Heiko Tietze --- Created attachment 194101 --> https://bugs.documentfoundation.org/attachment.cgi?id=194101=edit Screenshot macOS The initial view also has no content, at least on macOS. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161049] Vertical Tab dialogs--Format Cells dialog in recent 24.8 alpha is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161049 --- Comment #4 from Heiko Tietze --- Clicking a long text in the "vertical tabs" auto scrolls the list to the end but I cannot scroll manually back to left. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3eb427b31e624af9b2fe2bd68fee859d3d76a661 CPU threads: 8; OS: macOS 14.4.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161049] Vertical Tab dialogs--Format Cells dialog in recent 24.8 alpha is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161049 Heiko Tietze changed: What|Removed |Added OS|Windows (All) |All Priority|medium |high CC||heiko.tietze@documentfounda ||tion.org Severity|normal |major Keywords|needsUXEval |regression -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161049] Vertical Tab dialogs--Format Cells dialog in recent 24.8 alpha is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161049 --- Comment #3 from Heiko Tietze --- Created attachment 194100 --> https://bugs.documentfoundation.org/attachment.cgi?id=194100=edit Screenshot macOS -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158288] When you select part of a column with merged cells, all columns that are part of the merged cell are selected
https://bugs.documentfoundation.org/show_bug.cgi?id=158288 --- Comment #6 from Heiko Tietze --- LibreOffice behaves exactly like MS Excel, at least on macOS. However, I can follow the idea that selecting b1:b5 should not add a1 and c5 if a2:c4 is merged (as you get it via ctrl). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160820] Slideshow two presentations simultaneously on two different monitors
https://bugs.documentfoundation.org/show_bug.cgi?id=160820 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Heiko Tietze --- Bug 160242 was rejected with the idea to start Impress twice (shift click under Windows), and to control the workflow via a third monitor. Consequently this "control center" needs to be able to use different screens for presentation. => +1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160834] Unclear meaning of "Ignore pieces of length"
https://bugs.documentfoundation.org/show_bug.cgi?id=160834 --- Comment #4 from Heiko Tietze --- Testing with the autotext of lorem, I see a difference in the track changes depending on word vs. character by how the modification is marked. I don't see any effect in the piece length, eg. ibzum vs. ipsum is always marked as either the word is completely different or the particular characters regardless a piece length of 1 or 3. We may just hide the option to solve the UI issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160820] Slideshow two presentations simultaneously on two different monitors
https://bugs.documentfoundation.org/show_bug.cgi?id=160820 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #2 from V Stuart Foote --- (In reply to Stéphane Guillou (stragu) from comment #1) > > UX/Design, should we make it possible to change that Slide Show Setting > independently for each window somehow? +1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160820] Slideshow two presentations simultaneously on two different monitors
https://bugs.documentfoundation.org/show_bug.cgi?id=160820 Stéphane Guillou (stragu) changed: What|Removed |Added URL||https://forum.openoffice.or ||g/en/forum/viewtopic.php?t= ||35310 Whiteboard| QA:needsComment| CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org --- Comment #1 from Stéphane Guillou (stragu) --- I am able to run two presentations at the same time in the one installation of LO, but not able to set a different Presentation Display to each one: changing it for one switches is for the other one as well. Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US UX/Design, should we make it possible to change that Slide Show Setting independently for each window somehow? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160820] Slideshow two presentations simultaneously on two different monitors
https://bugs.documentfoundation.org/show_bug.cgi?id=160820 Stéphane Guillou (stragu) changed: What|Removed |Added Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160834] Unclear meaning of "Ignore pieces of length"
https://bugs.documentfoundation.org/show_bug.cgi?id=160834 --- Comment #3 from Noel Grandin --- Given the source file, it has something to do with comparing documents, other than that, I don't know. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160834] Unclear meaning of "Ignore pieces of length"
https://bugs.documentfoundation.org/show_bug.cgi?id=160834 Heiko Tietze changed: What|Removed |Added Keywords||needsDevAdvice CC||noelgran...@gmail.com --- Comment #2 from Heiko Tietze --- The property IgnorePieces in officecfg/registry/schema/org/openoffice/Office/Writer.xcs has the description "Specifies whether short pieces of matched text are ignored." IsIgnorePieces() aka m_bIgnorePieces defined in sw/inc/modcfg.hxx is used as CmpOptions.nIgnoreLen = SW_MOD()->IsIgnorePieces() ? SW_MOD()->GetPieceLen() : 0; in sw/source/core/doc/doccomp.cxx ultimately applied in CommonSubseq::IgnoreIsolatedPieces(). Quickly skimming over the code it seems the option controls whether "isolated pieces" (characters) are ignored and up to which length. I guess the wording "pieces" is used because the option is not only applied in case of (compare) "By Character" but also "By word". Noel, you made a lot of changes in the source code. Please enlighten us. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160834] Unclear meaning of "Ignore pieces of length"
https://bugs.documentfoundation.org/show_bug.cgi?id=160834 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158288] When you select part of a column with merged cells, all columns that are part of the merged cell are selected
https://bugs.documentfoundation.org/show_bug.cgi?id=158288 Aron Budea changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #5 from Aron Budea --- Thinking about this, I'm not sure this should be considered a bug. There's a merged cell in the range, which means your selection isn't strictly within column A, but spans to column C. Excel also behaves the same way. Let's ask the UX team, can you please share your thoughts? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160834] Unclear meaning of "Ignore pieces of length"
https://bugs.documentfoundation.org/show_bug.cgi?id=160834 Dieter changed: What|Removed |Added CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Blocks||125674 --- Comment #1 from Dieter --- (In reply to Tuomas Hietala from comment #0) > Description: > The UI string "Ignore _pieces of length:" is somewhat confusing and > contradictory. The following explanation is given in Help: "Set the minimum > number of characters to trigger a valid comparison." > > The UI and Help are at odds here, because it's not clear whether the > selected number of characters is to be ignored (as indicated by the UI > string) or if it's the minimum amount to be taken into account (as indicated > by Help) I agree and couldn't really figure out, what is the current behaviour => NEW > "Pieces of length" should IMO also be reworded for clarity. I'd suggest > replacing the string with something like "Minimum number of characters to > compare" (if Help is correct) or "Maximum number of characters to ignore" > (if Help is not). I support a terminology, that is much clearer, but I don't know, what's the best solution here cc: Design-Team (who should also decide, if we should separate the two issues into two different reports. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=125674 [Bug 125674] [META] Document Comparison bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161049] Vertical Tab dialogs--Format Cells dialog in recent 24.8 alpha is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161049 --- Comment #2 from ady --- I would guess that this is at least partially related to tdf#99528 comment 32, patch committed on 2024-05-06? IDK if needs to be bisected in order to confirm? Not only the size of the dialog is too small, the width of the "vertical tabs" box seems to be too small too (so the text to select each "vertical tab" is not completely readable), and cannot be modified. No scroll bars in this "vertical tabs" box either (which is not necessarily the best way to solve it). As a side note, is the UX team really sure that using "vertical tabs" in this Format Cells dialog is really saving screen usage? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161047] Vertical Tab dialogs--Page style dialog is too small and not resizeable
https://bugs.documentfoundation.org/show_bug.cgi?id=161047 --- Comment #1 from V Stuart Foote --- Confirmed, and an immediate problem as dialog can not be resized. 20240510 TB77 nightly Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0ffdfb58a07e2a1b89a36bc241c6a2767e82cd2c CPU threads: 8; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161049] Vertical Tab dialogs--Format Cells dialog in recent 24.8 alpha is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161049 V Stuart Foote changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||samuel.mehrbrodt@allotropia ||.de, ||vsfo...@libreoffice.org Summary|Format Cells dialog in |Vertical Tab |recent 24.8 alpha is too|dialogs--Format Cells |small |dialog in recent 24.8 alpha ||is too small Keywords||needsUXEval Ever confirmed|0 |1 See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=99 ||528 --- Comment #1 from V Stuart Foote --- confirmed 20240510 TB77 nightly Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0ffdfb58a07e2a1b89a36bc241c6a2767e82cd2c CPU threads: 8; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161047] Vertical Tab dialogs--Page style dialog is too small and not resizeable
https://bugs.documentfoundation.org/show_bug.cgi?id=161047 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||samuel.mehrbrodt@allotropia ||.de, ||vsfo...@libreoffice.org Status|UNCONFIRMED |NEW Summary|Vertical tab dialogs--Page |Vertical Tab dialogs--Page |style dialog is too small |style dialog is too small |and not resizeable |and not resizeable See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=99 ||528 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158874] Want MS-Word like auto-formatting of beginning of list item
https://bugs.documentfoundation.org/show_bug.cgi?id=158874 Eyal Rozenberg changed: What|Removed |Added CC||heiko.tietze@documentfounda ||tion.org --- Comment #13 from Eyal Rozenberg --- Heiko FYI. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158874] Want MS-Word like auto-formatting of beginning of list item
https://bugs.documentfoundation.org/show_bug.cgi?id=158874 Eyal Rozenberg changed: What|Removed |Added Resolution|INSUFFICIENTDATA|--- Status|RESOLVED|UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158874] Want MS-Word like auto-formatting of beginning of list item
https://bugs.documentfoundation.org/show_bug.cgi?id=158874 --- Comment #12 from Eyal Rozenberg --- Created attachment 194085 --> https://bugs.documentfoundation.org/attachment.cgi?id=194085=edit Screencast of MS Word behavior Screencast of how MS Word autoformats initial phrase on a line, based on the formatting of that phrase on the previous line, in a bulleted list. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160951] Navigator: Present sort options per radio button
https://bugs.documentfoundation.org/show_bug.cgi?id=160951 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161037] UNO Sidebar 'Hide' and 'Show' sidebar deck (splitwin) -- a new function (available for assigning a shortcut key to it)
https://bugs.documentfoundation.org/show_bug.cgi?id=161037 V Stuart Foote changed: What|Removed |Added URL||https://wiki.documentfounda ||tion.org/File:LO-HIG_SideeB ||ar-Terminology.png CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||rayk...@gmail.com, ||vsfo...@libreoffice.org Summary|close sidebar deck -- a new |UNO Sidebar 'Hide' and |function (available for |'Show' sidebar deck |assigning a shortkey to it) |(splitwin) -- a new ||function (available for ||assigning a shortcut key to ||it) Keywords||needsUXEval Blocks||86899 --- Comment #1 from V Stuart Foote --- This is expected with the current +F5 toggle (.uno:Sidebar) which *closes* or *opens a new instance* of the SB framework. Its workflow and UI behavior is pretty consistent, as is that of the F11 "Stylist". Also, UNO are already available and assigned to open each SB Deck (bug 84502); +[1-9] with 1-4 common (uno:PropertyDeck, uno:StyleListDeck, uno:GalleryDeck, uno:NavigatorDeck) across the modules. IMHO what *would* be useful would be creating an additional UNO action supporting a keyboard toggle of the current 'Hide'/'Show' (vcl/splitwin) thumb/grip button actions for an active Sidebar instance. Currently just available to mouse click on the buttons. While clicking on a Deck's Tab in the Tab bar will toggle the Deck collapsed or open, the "Hide" thumb button fully collapses the Sidebar (exposing a 'Show' thumb button on the opposite SB edge). While the 'Show' button restores the Sidebar, either just Tab bar, or Tab bar and Deck depending on state when hidden. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=86899 [Bug 86899] [META] Requests for the addition of UNO commands -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161031] Form creating is too niche to merit a main menu item visible by default
https://bugs.documentfoundation.org/show_bug.cgi?id=161031 Eyal Rozenberg changed: What|Removed |Added CC||eyalr...@gmx.com, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160938] FORMCONTROLS: Add ability to Find and Replace field names
https://bugs.documentfoundation.org/show_bug.cgi?id=160938 Eyal Rozenberg changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Blocks||107742 --- Comment #1 from Eyal Rozenberg --- Support this. UI-wise, it could be as easy as adding another checkbox in the F dialog: [ ] Field Names like we have [ ] Comments Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=107742 [Bug 107742] [META] Form control bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161030] Vertical Tab dialogs--width available for Tab name is too narrow with jumping view of Tab names
https://bugs.documentfoundation.org/show_bug.cgi?id=161030 V Stuart Foote changed: What|Removed |Added Summary|Vertical Tab dialogs--width |Vertical Tab dialogs--width |available for Tab name is |available for Tab name is |too narrow |too narrow with jumping ||view of Tab names -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161030] Vertical Tab dialogs--width available for Tab name is too narrow
https://bugs.documentfoundation.org/show_bug.cgi?id=161030 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||samuel.mehrbrodt@allotropia ||.de, ||vsfo...@libreoffice.org See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=99 ||528 Keywords||needsUXEval --- Comment #1 from V Stuart Foote --- Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 505803e2cb4d60153be2218a17ede8e34d95b42e CPU threads: 8; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161026] Vertical Tab dialogs--Mouse cursor over tab not activated until pointer touches bottom edge (Win)
https://bugs.documentfoundation.org/show_bug.cgi?id=161026 V Stuart Foote changed: What|Removed |Added Summary|Mouse cursor over the new |Vertical Tab dialogs--Mouse |Vertical Tab dialogs, tab |cursor over tab not |not activated until pointer |activated until pointer |passes bottom edge (Win)|touches bottom edge (Win) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161029] Special Find presets with regular expression
https://bugs.documentfoundation.org/show_bug.cgi?id=161029 --- Comment #3 from Olivier Hallot --- (In reply to Eyal Rozenberg from comment #2) > Perhaps extension material? There is an regex F extension at https://extensions.libreoffice.org/en/extensions/show/70066 However, this extension is far to complicated for "Joe User" ( =average user) and requires knowledge in regex which is the issue we want to hide here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161020] Vertical Tab dialogs--initial size of the style dialog is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161020 V Stuart Foote changed: What|Removed |Added Summary|Initial size of the new |Vertical Tab |kind style dialog is too|dialogs--initial size of |small |the style dialog is too ||small -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161029] Special Find presets with regular expression
https://bugs.documentfoundation.org/show_bug.cgi?id=161029 --- Comment #2 from Eyal Rozenberg --- Perhaps extension material? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161020] Initial size of the new kind style dialog is too small
https://bugs.documentfoundation.org/show_bug.cgi?id=161020 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=99 ||528 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||samuel.mehrbrodt@allotropia ||.de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161029] Special Find presets with regular expression
https://bugs.documentfoundation.org/show_bug.cgi?id=161029 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org Keywords||needsUXEval --- Comment #1 from V Stuart Foote --- +1 But, little room on the Full F dialog so would need to provide a pop-out selector button like checkbox dialog for 'Attributes', but applicable only to the 'regex Replacements'. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Provide framework to suppress editing with direct formatting of a styled document, or template.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org Summary|Prevent direct formatting |Provide framework to |on writer by a password.|suppress editing with ||direct formatting of a ||styled document, or ||template. --- Comment #10 from V Stuart Foote --- Adjusting summary. +1, but rather than "password", identify a per-document/template method to reduce optional DF and emphasize Style based formatting. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160797] File / Export, Export as, Send, Preview in Web browser .... AND: "Generate" ... or
https://bugs.documentfoundation.org/show_bug.cgi?id=160797 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #3 from V Stuart Foote --- In technical English, no issue. Send works fine for all the subitems, it is an alternative action verb to Save As..., Export..., or export to PDF/EPub choices. Expanding the action verbs to include 'Generate' or similar gains us little in technical English and complicates things for the l10n translation efforts. So, -1 and a => WF from me as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161026] Mouse cursor over the new Vertical Tab dialogs, tab not activated until pointer passes bottom edge (Win)
https://bugs.documentfoundation.org/show_bug.cgi?id=161026 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||samuel.mehrbrodt@allotropia ||.de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 --- Comment #8 from V Stuart Foote --- (In reply to Heiko Tietze from comment #7) > So we agree that the missing space between number and unit is a bug. > Nope, norm would be to follow the CLDR. Which I think we do? Space and position as specified in CLDR, otherwise space is not required (we seem to do the correct thing already, if consistent use of the XML can be confirmed on the Statusbar zoom). And certainly not hardcoding a "percentage symbol separated from the number" as suggested in OP. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 --- Comment #9 from Dieter --- (In reply to Heiko Tietze from comment #8) > Rather Tools > Protect > [x] Allow Direct Formatting I agree, if it is enabled by default. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 --- Comment #8 from Heiko Tietze --- Rather Tools > Protect > [x] Allow Direct Formatting -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 --- Comment #7 from Dieter --- (In reply to Heiko Tietze from comment #6) > On the other hand I see the advantage of such protection when you share a > well-styled document with colleagues or when people should use a company > template, and all styling is broken after some modifications. So is it a solution to provide an option (fo example in "Save As ..." dialog) like "Save with password for direct formatting"? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 Heiko Tietze changed: What|Removed |Added CC||mikekagan...@hotmail.com --- Comment #6 from Heiko Tietze --- (In reply to Heiko Tietze from comment #1) > The idea was to have a style highlighter, for just DF see bug 106556. This has been implemented meanwhile. Changing the UI is still possible (with limits how well DF is suppressed). Keep in mind that any new attribute needs to be standardized, so opening a document has the same effect on all platforms and applications. And since users prefer working with DF, this will not become implemented. Ultimately it depends on the type of document how much effort and precision should be done for the layout. If you write a scientific paper you probably want to use styles. But for a short note or a letter it's perfectly fine to use multiple returns for paragraph spacing, or bold/italic to emphasize a passage. On the other hand I see the advantage of such protection when you share a well-styled document with colleagues or when people should use a company template, and all styling is broken after some modifications. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160797] File / Export, Export as, Send, Preview in Web browser .... AND: "Generate" ... or
https://bugs.documentfoundation.org/show_bug.cgi?id=160797 --- Comment #2 from Heiko Tietze --- You talk about the menu File > Send, which has a number of subitems like "Email As*" that sound right to you but also the two menu items "Outline to Presentation" and "Outline to Clipboard" that aren't a good fit for "Send". I never stumbled over these labels and can easily understand the function. And we should not split the Send-menu into Send and Generate (or any other label) to make the children phonetically better fitting. So my take is WF. More opinions? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Ever confirmed|0 |1 Blocks||111942 Status|UNCONFIRMED |NEW --- Comment #7 from Heiko Tietze --- So we agree that the missing space between number and unit is a bug. The code has some level of spaghettiness, simply changing the XML is not enough. And PERCENT_NUMBER is #6, while formatindex is 8... Beyond my skills. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=111942 [Bug 111942] [META] User locale bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160797] File / Export, Export as, Send, Preview in Web browser .... AND: "Generate" ... or
https://bugs.documentfoundation.org/show_bug.cgi?id=160797 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161002] Missing item "Insert/Filed/More Fields.." in LibreOffice Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=161002 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Regina Henschel --- That is a very old request, see bug 53548 and the there listed duplicates. *** This bug has been marked as a duplicate of bug 53548 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161002] Missing item "Insert/Filed/More Fields.." in LibreOffice Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=161002 --- Comment #3 from Martin Pietka --- Yes,this is why I want to add this feature. To be same like in Writer. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161002] Missing item "Insert/Filed/More Fields.." in LibreOffice Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=161002 m_a_riosv changed: What|Removed |Added CC||miguelangelrv@libreoffice.o ||rg --- Comment #2 from m_a_riosv --- The option was never there, all available fields are listed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160497] FR: Print (or export) only tracked changes
https://bugs.documentfoundation.org/show_bug.cgi?id=160497 --- Comment #6 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #5) > We discussed the topic in the design meeting. The proposed macro solution > seems to be the right way to tackle this niche use case. 1. See my last comment 2. How does the macro reproduce complex, formatted, Writer objects within that Calc spreadsheet? Suggest reopening. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 --- Comment #6 from V Stuart Foote --- (In reply to V Stuart Foote from comment #5) > We hold the CLDR in i18npool/source/localedata/data as an XML for each > supported locale, and IIUC the format code for 'PercentFormatskey1' or > 'PercentFormatskey2' is what gets picked up for localized FUNIT_PERCENT > depending on precision. > > If you look through the XML you'll see the mix of usage for localizations. > The tr_TR.xml is a good test case. Its CLDR number format for percentage is 96 97 %0 98 99 100 %0,00 Note that for the Turkish locale the "%" glyph is moved to the front of the format code! And if from Tools -> Options -> Language and Locales -> General you change your LO "User Interface" and "Locale" to 'Turkish' (checking "Ignore system input language") and relaunch the format for the Statusbar zoom control does match that format. Likewise for fr-FR, test that with its 94 95 0" "% 96 97 98 0,00" "% shows the Statusbar zoom control matching the format and a *NBSP (0x00A0) preceding* the "%" glyph. So are we already using our CLDR format values for the stbctrls/zoomctrl.cxx as well? If so, we're doing the correct thing. And any changes would need to be to our CLDR implementation, or upstream. Which for en-US allows both no-space and spaced. And this is a non-issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 --- Comment #5 from V Stuart Foote --- (In reply to Heiko Tietze from comment #3) >... > which starts with the comment > > //Format a number as a percentage according to the rules of the given > //language, e.g. 100 -> "100%" for en-US vs "100 %" for de-DE Don't know why FUNIT_PERCENT (of AOo i56998) was not applied for the status bar zoom control, but upstream Unicode "Common Locale Data Repository" (CLDR) contains the "accepted" usage. When Caolán ported the changes, he was a little sparse in its commenting. In reality, the CLDR addresses spacing, decimal separator and position of the % glyph per locale. We hold the CLDR in i18npool/source/localedata/data as an XML for each supported locale, and IIUC the format code for 'PercentFormatskey1' or 'PercentFormatskey2' is what gets picked up for localized FUNIT_PERCENT depending on precision. If you look through the XML you'll see the mix of usage for localizations. Also, localization doesn't follow SI usage. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 Dieter changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #5 from Dieter --- Hartmut, please don't change status to NEW => I change it back to UNCONFIRMED Heiko, for me this enhancement request is a WONTFIX. Although I'm a fan of using styles and prevent direct formatting I don't think, that forcing people to do so should be part of the culture of LO. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160797] File / Export, Export as, Send, Preview in Web browser .... AND: "Generate" ... or
https://bugs.documentfoundation.org/show_bug.cgi?id=160797 Dieter changed: What|Removed |Added Blocks||111591, 85811 Keywords||needsUXEval CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Priority|medium |low --- Comment #1 from Dieter --- Peter, thank you for your idea. Let's ask design-team. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=85811 [Bug 85811] [META] Main menu bar bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=111591 [Bug 111591] [META] File sending bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161002] Missing item "Insert/Filed/More Fields.." in LibreOffice Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=161002 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Severity|normal |enhancement Blocks||85811 Keywords||needsUXEval --- Comment #1 from Roman Kuznetsov <79045_79...@mail.ru> --- I'm not sure "More fields" is available for Draw Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=85811 [Bug 85811] [META] Main menu bar bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 --- Comment #4 from j22...@gmail.com --- > //Format a number as a percentage according to the rules of the given > //language, e.g. 100 -> "100%" for en-US vs "100 %" for de-DE This is a bit misleading: As pointed out in my original post, there seems not to be a 'correct' way 'according to English', therefore it is not true that "100%" is the 'rule' for this language. If we, as an open and international community, stick to international standards (as I guess we intend to?), then we should follow the widely used and accepted International System of Units (SI) [1], followed even by English-speaking science institutions [2]. [1] Page 151 in https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf [2] https://physics.nist.gov/cuu/Units/checklist.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 --- Comment #3 from Heiko Tietze --- SvxZoomStatusBarControl::ImplUpdateItemText() calls unicode::formatPercent() which starts with the comment //Format a number as a percentage according to the rules of the given //language, e.g. 100 -> "100%" for en-US vs "100 %" for de-DE Now I wonder why ICU defines no space between number and unit while the usual English typography does according https://en.wikipedia.org/wiki/Space_(punctuation)#Unit_symbols_and_numbers. Eike, what's your take? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160497] FR: Print (or export) only tracked changes
https://bugs.documentfoundation.org/show_bug.cgi?id=160497 Heiko Tietze changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Heiko Tietze --- We discussed the topic in the design meeting. The proposed macro solution seems to be the right way to tackle this niche use case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160610] Print multiple non-contiguous print ranges on a single page in LibreOffice Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=160610 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #7 from Heiko Tietze --- We discussed the topic in the design meeting and suggest to resolve as NAB/WF given that some alternative workflows exist. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158932] Icons for promote / demote outline level should be improved
https://bugs.documentfoundation.org/show_bug.cgi?id=158932 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=70 ||102 Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Heiko Tietze --- We discussed the topic in the design meeting. While the arrow-like symbols may depict the function clearly for LTR users it is completely misleading in case of RTL - which has been reported in bug 154523. *** This bug has been marked as a duplicate of bug 154523 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160353] List images in order of document appearance in Calc Navigator
https://bugs.documentfoundation.org/show_bug.cgi?id=160353 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Priority|medium |lowest --- Comment #4 from Heiko Tietze --- We discussed the topic in the design meeting. Sorting can be done in at least four different orders: row first, col first, alphabetically, and by insertion time. The use case is questionable, and rather inspired by the existence of this feature in Writer. But the biggest issue is the fact that the Navigator lists objects from all sheets. Let's keep the ticket for later consideration. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160497] FR: Print (or export) only tracked changes
https://bugs.documentfoundation.org/show_bug.cgi?id=160497 --- Comment #4 from Eyal Rozenberg --- I support this feature request, or rather: I support the ability to export the list of tracked changes. (In reply to Heiko Tietze from comment #3) > printing sounds very niche (and we have the responsibility of > conservation) Disagree. If it is not niche to go over the tracked changes (e.g. in a sidebar), it is not niche to export/print them. Export could be: * to a Writer document with the changes in sequence - in styled paragraphs. * to a Calc table (not a CSV table, since we need the formatting), maybe. and the export could be either into a file or into a new document. The file can then be printed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160544] Quickfind sidebar: Make the sidebar the default for ctrl+F
https://bugs.documentfoundation.org/show_bug.cgi?id=160544 --- Comment #19 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #0) > Follow-up to bug 95405: The sidebar is supposed to be an improvement to the > classic toolbar. We should default the quicksearch to this control - and > have the legacy toolbar as an alternative option. When we have a decent search sidebar, then let's talk about that. Fix some of its bugs (I'm going to file a couple after my first single use), add some of the Find dialog functionality, etc... So, for now, definite no-no from me. Even in principle I'm not sure I would support this, because the sidebar takes a huge chunk of your viewport away, while the find bar is just a vertical bar, and at the bottom where it's less noticeable than a top toolbar. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160610] Print multiple non-contiguous print ranges on a single page in LibreOffice Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=160610 --- Comment #6 from Eyal Rozenberg --- (In reply to Stéphane Guillou (stragu) from comment #2) > As a cumbersome workaround: > 1. Hide columns/rows > 2. Define a single print range > 3. Print Is that really so cumbersome? Also, other alternatives: * Copy the two ranges to a new sheet or * link to the ranges from a new sheet (i.e. use =OldSheet!B11 , or wherever the range starts, then drag to copy with the rows and columns to get the full range; and elsewhere on the same page repeat the same for the second range -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160610] Print multiple non-contiguous print ranges on a single page in LibreOffice Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=160610 --- Comment #5 from Cor Nouws --- (In reply to Cor Nouws from comment #4) > Did you consider hiding rows/columns in a range, so that only visible stuff > is printed? That would (in some cases) remove the need to have multiple > print ranges? [Heiko kindly reminds that Stéphane also mentioned hiding stuff :) ] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160610] Print multiple non-contiguous print ranges on a single page in LibreOffice Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=160610 Cor Nouws changed: What|Removed |Added Version|24.2.2.2 release|Inherited From OOo -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160610] Print multiple non-contiguous print ranges on a single page in LibreOffice Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=160610 Cor Nouws changed: What|Removed |Added CC||c...@nouenoff.nl --- Comment #4 from Cor Nouws --- (In reply to Orwel from comment #0) > Expected Results: > Would be great if the dimension of the paper allows it, a possibility to > print both ranges on one sheet would exist. Hi Orwel, For some cases it could be useful, especially when e.g. the width of the ranges are similar. In other cases it will produce nasty/ugly results. So if added as option, one to handle with care. Did you consider hiding rows/columns in a range, so that only visible stuff is printed? That would (in some cases) remove the need to have multiple print ranges? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 V Stuart Foote changed: What|Removed |Added Component|LibreOffice |Localization -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 V Stuart Foote changed: What|Removed |Added Summary|Use CLDR number and |Use CLDR number formatting |currency pattern formatting |pattern |of Percentage in the UI,|'standard-percentage' in |e.g. show 'X %' instead of |the UI, e.g. show 'X %' |'X%' depending on locale|instead of 'X%' depending ||on locale -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] Use CLDR number and currency pattern formatting of Percentage in the UI, e.g. show 'X %' instead of 'X%' depending on locale
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 V Stuart Foote changed: What|Removed |Added CC||er...@redhat.com Summary|show 'X %' instead of 'X%' |Use CLDR number and ||currency pattern formatting ||of Percentage in the UI, ||e.g. show 'X %' instead of ||'X%' depending on locale --- Comment #2 from V Stuart Foote --- (In reply to V Stuart Foote from comment #1) > ... > -1 Addressed more directly in Unicode CLDR 'standard-percent' number formatting pattern handling, which seems more what is requested. As used already [1] in Calc for cell value formatting of percentages. Just don't know if we apply it anywhere else against the UI, or how involved such an l10n change to be able to label the Status Bar UI (stbctrls/zoomctrl.cxx) might be. If simple enough, then sure. But not if it ends up too complicated and needing substantial refactoring to handle the zoom attribute. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/i18nutil/source/utility/unicode.cxx?r=19ea4aad#1032 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] show 'X %' instead of 'X%'
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #1 from V Stuart Foote --- Thanks for posting! Hmm, gave it some thought about using MS-LCID and applying a number format. But seems over engineered, and mostly the percent formats are without space anyhow. Status quo here for UI suffices. -1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160986] show 'X %' instead of 'X%'
https://bugs.documentfoundation.org/show_bug.cgi?id=160986 Xisco Faulí changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||xiscofa...@libreoffice.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160920] Allow choosing the page style from the sheets tab
https://bugs.documentfoundation.org/show_bug.cgi?id=160920 --- Comment #12 from Cor Nouws --- (In reply to ady from comment #11) > ... > Experienced users make mistakes too. By the time users realize the mistake, > it might be too late to undo it. thnx Ady. I'm glad we sort of agree that using multiple sheets selected is for experienced user. In the case of picking a 'wrong' page style for a sheet, that will only affect the print (preview) and produced PDF - something one would expect to be checked - but nothing in the document is affected in any way. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 Hartmut Schorrig changed: What|Removed |Added Resolution|INSUFFICIENTDATA|--- Status|RESOLVED|NEW --- Comment #4 from Hartmut Schorrig --- And the next for pushing indirect formatting is: It should be more simple to use. For example any knows ctrl-i for italic direct formatting. It should be simple able to assign the ctrl-i instead for using character format "Quotation". Because that is the most reason to use italic. Then I can work without learning new stuff (as a simple user). ... but this may be another Bug number -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 --- Comment #3 from Hartmut Schorrig --- The problem of direct formatting is, many people want to do it. If it is made more difficult, it will cause resentment among normal users. But professional users should know the advantage of indirect formatting, especially it is also familiar in such tools as Latex & co. But professional users (document managers in companies) often have to be convinced of the usefulness of indirect formatting. It means the problem is first time a problem of coaching, information. Not a problem of documentation and not a problem of LibreOffice. But this is precisely why there should be a mode that either prohibits direct formatting or makes it more difficult (with hints), consistently prohibiting it. This must be simple able to be switched on and off. (not with a password, that's nonsense or bullying). Then, if the users are informed about the concept of indirect formatting, incl. speaking about which styles, its meaning, also the styles should be concerted (!), then existing direct formatting parts should be able to higlight, (for ex. yellow background), to remove the direct formatting and think about (!) what to do instead (!). This is hard editing working on the text. Do it step by step, any day a part. For LibreOffice it means, this higlighting of direct formatted parts should be on and off switchable, should not disturb the normal work. The problem whether there are direct formatting parts in a text is not a problem of ban and passwords, it is a problem of able to evaluate where there are direct formatting parts. And a chief can say to the staff people, please remove it. It is a similar situation when there are meaningful style guides in a programming language (C/++), which are checked with a tool and must necessarily be fixed by the programmers in order to have a proper result. It means we need two things: a) Switch on/off possibity and support of direct formatting (for ex. ctrl-I for italic or the buttons for selecting colors) b) Switch on/off buttons for showing direct formatting parts. To clean it, the ctrl-m exists, that is proper. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160908] "Edit cell background highlight"
https://bugs.documentfoundation.org/show_bug.cgi?id=160908 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|libreoffice-b...@lists.free |printfdebugg...@gmail.com |desktop.org | Ever confirmed|0 |1 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #4 from Heiko Tietze --- (In reply to Heiko Tietze from comment #1) > How about "Edit highlight" with a long tooltip? This is going into production. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 98902] Right clicking on selected text unselects it if the cursor is on a misspelled word
https://bugs.documentfoundation.org/show_bug.cgi?id=98902 Heiko Tietze changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #12 from Heiko Tietze --- At least it is inconsistent with Writer. Actually I would prefer the Impress-way as it allows to do spellchecking while text is selected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160752] Protect ratio as Image option
https://bugs.documentfoundation.org/show_bug.cgi?id=160752 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists | |.freedesktop.org| See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||9543 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Heiko Tietze --- (In reply to m_a_riosv from comment #2) > Maybe with the option, only corners should be available to resize, to avoid > mistakes. +1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160947] [RFE] New product to LibreOffice suite - Content file search tool
https://bugs.documentfoundation.org/show_bug.cgi?id=160947 --- Comment #6 from Tex2002ans --- "Everything" is a program on Windows which has an extremely in-depth "search within all filetypes" functionality: - https://www.voidtools.com/ I use that to mass search HTML, TXT, RTF, DOCX, ODT, ... all in one shot. And, best of all, it's WAY faster than the default Windows Explorer search. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160920] Allow choosing the page style from the sheets tab
https://bugs.documentfoundation.org/show_bug.cgi?id=160920 --- Comment #11 from ady --- (In reply to Cor Nouws from comment #10) > > The positive in the status bar: the UI space is already used for Page Style > > info. This is a negative for the worksheet Tab, where a new non-essential > I would love to see a broadly accepted and clear definition of > 'non-essential' in the UI/software? By non-essential I mean that there are other ways to achieve the same goal. Having the possibility of selecting a different Page Style, either from the status bar of from the worksheet Tab could be convenient, but there are other ways to achieve it. For instance, in the worksheet Tab, the context menu includes "Move or Copy sheet", which I think it is more relevant in this menu than the suggested Page Style. After some time, we can read the opposite reasoning: "your request for this new UI artifact sounds useful, but that area of the UI already has many items". At some point, adding items is not as much welcome. Carefully considering which precise items are really a plus in a certain context menu eventually reduces the potential unwanted clutter. > > (but potentially useful) context menu item would be added. > > > > The negative in the status bar: the current info is relevant for the current > > worksheet only. When selecting multiple worksheets, perhaps with different > > Page Styles each, there is no indication of the Page Styles in use by the > > other selected worksheets. In such situation, allowing to select a different > > Page Style for the multiple-selection of worksheets would impact all the > > selected worksheets, and it would be easy for users to not notice the > > multiple change. > That is not different to what happens when applying a style in the Manage > Styles pane. > But honestly I think that users that work with multiple sheets selected, can > be considered experienced enough to.. Experienced users make mistakes too. By the time users realize the mistake, it might be too late to undo it. With the current situation, users can modify the Page Style itself from the status bar, but ATM it is not possible (from the status bar) to make the mistake of selecting a different Page Style to "unwanted" worksheets. Since the status bar can show the Page Style that corresponds to the current worksheet _only_ (while having multiple worksheets selected), the chance for this potential mistake increases. That is not to say that the suggested change is not worth it. I was just mentioning some UX details that might be relevant in order to choose whether the suggested context menu (or whichever other UI method) should rather be located on the status bar or on the worksheet Tab, and perhaps to have additional details in mind. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160920] Allow choosing the page style from the sheets tab
https://bugs.documentfoundation.org/show_bug.cgi?id=160920 --- Comment #10 from Cor Nouws --- (In reply to ady from comment #9) > If I may... If you insist .. ;) - but sure! > The positive in the status bar: the UI space is already used for Page Style > info. This is a negative for the worksheet Tab, where a new non-essential I would love to see a broadly accepted and clear definition of 'non-essential' in the UI/software? Me expects to get dozens - IOW: it's rather subjective. > (but potentially useful) context menu item would be added. > > The negative in the status bar: the current info is relevant for the current > worksheet only. When selecting multiple worksheets, perhaps with different > Page Styles each, there is no indication of the Page Styles in use by the > other selected worksheets. In such situation, allowing to select a different > Page Style for the multiple-selection of worksheets would impact all the > selected worksheets, and it would be easy for users to not notice the > multiple change. That is not different to what happens when applying a style in the Manage Styles pane. But honestly I think that users that work with multiple sheets selected, can be considered experienced enough to.. > Perhaps the display of the Page Style should change when selecting multiple > worksheets? For instance, use bold?, italics?, underline? add symbol? > Currently this distinction is not needed, even when selecting multiple > worksheets. Yes, maybe a bit opaque .. still people would need to learn/see the meaning. > If the Page Style is simultaneously changed for more than the > current/active/displayed worksheet, perhaps a confirmation dialog should pop > up? See before: it is standing practice - and a different subject, so pls open a separate bug report to discuss. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153777] FLUID page number indication option: on / off
https://bugs.documentfoundation.org/show_bug.cgi?id=153777 --- Comment #11 from Heiko Tietze --- *** Bug 158526 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 158526] page number display in the status bar
https://bugs.documentfoundation.org/show_bug.cgi?id=158526 Heiko Tietze changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Heiko Tietze --- Third attempt to revert this into "A-B of C" :-). Please consider more than two pages. *** This bug has been marked as a duplicate of bug 153777 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153777] FLUID page number indication option: on / off
https://bugs.documentfoundation.org/show_bug.cgi?id=153777 --- Comment #10 from Heiko Tietze --- *** Bug 159921 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 159921] number of pages indication: display format options (enhancement request)
https://bugs.documentfoundation.org/show_bug.cgi?id=159921 Heiko Tietze changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Heiko Tietze --- *** This bug has been marked as a duplicate of bug 153777 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 146448] DOCX: A drawing object has a "Remove Textbox" which creates an empty frame (Captionbox/image frame is converted to Drawing object)
https://bugs.documentfoundation.org/show_bug.cgi?id=146448 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval |filter:docx --- Comment #10 from Heiko Tietze --- Undo/redo deletes the whole object, which could be expected considering that deleting the caption frame also removes the content. However, adding a caption to a default drawing object makes the caption frame a frame and not a drawing object itself. I believe this is a bug in the import filter. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160950] Warn before performing a destructive/lossy edit of OLE object
https://bugs.documentfoundation.org/show_bug.cgi?id=160950 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Status|UNCONFIRMED |NEW Severity|enhancement |normal --- Comment #1 from Heiko Tietze --- Properties > Options > Protect > Contents - does not disable/hide the Edit function and allows to change the content => bug. Other than that I could imagine a solution per frame/section that is made read-only. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160947] [RFE] New product to LibreOffice suite - Content file search tool
https://bugs.documentfoundation.org/show_bug.cgi?id=160947 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #5 from Heiko Tietze --- pdfgrep does its job pretty well, and apparently there are also tools for ODF. And ultimately it's up to the OS/DE to search files for content. => WF -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160947] [RFE] New product to LibreOffice suite - Content file search tool
https://bugs.documentfoundation.org/show_bug.cgi?id=160947 --- Comment #4 from V Stuart Foote --- "Solutions" thus far, including the LO bundled native "Windows Explorer Extension" or the LOOOK extension, only parse ODF and OOXML source documents for full-text string contents. This RFE for "non-indexed" search within the LO UI is much broader filter request and seems out of scope to project--even as an Extension -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160947] [RFE] New product to LibreOffice suite - Content file search tool
https://bugs.documentfoundation.org/show_bug.cgi?id=160947 --- Comment #3 from Anton Shevtsov --- (In reply to Regina Henschel from comment #2) > I think such tool need not be a core tool, but could be provided as > extension or as separate tool. Perhaps contact Mechtilde Stehmann. She > provides Loook, which is similar to such tool. > https://mechtilde.de/Loook/index.html Loook for odt only. No pdf, no rtf, no htm... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160955] When selecting an alternative link target for an OLE object, button says "Insert"
https://bugs.documentfoundation.org/show_bug.cgi?id=160955 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #4 from Heiko Tietze --- Edit > External Links... has a Modify button. (In reply to Eyal Rozenberg from comment #0) > Easy hack? Don't spot the string in a quick glance in ChangeSourceClickHdl at cui/source/dialogs/linkdlg.cxx. Maybe mxFileDlg->setTitle( SfxResId( STR_SFX_EXPLORERFILE_INSERT ) ); in sfx2/source/dialog/filedlghelper.cxx but this affects all dialogs then. Could be solved by introducing another flag for FileDialogFlags but using this flag becomes a bit tricky. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160954] Can't change OLE Object link target from context menu and properties dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=160954 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||3536 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160949] When editing an OLE object but not taking any action - undo edit
https://bugs.documentfoundation.org/show_bug.cgi?id=160949 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needsUXEval |needsDevEval CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|UNCONFIRMED |NEW --- Comment #1 from Heiko Tietze --- How would you know what happend in the other module or even external application? Or do we open only in LibreOffice. Anyway, if nothing happens it would be nice to see it in the undo stack as well. But low priority. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160947] [RFE] New product to LibreOffice suite - Content file search tool
https://bugs.documentfoundation.org/show_bug.cgi?id=160947 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #2 from Regina Henschel --- I think such tool need not be a core tool, but could be provided as extension or as separate tool. Perhaps contact Mechtilde Stehmann. She provides Loook, which is similar to such tool. https://mechtilde.de/Loook/index.html -- You are receiving this mail because: You are on the CC list for the bug.
