[Libreoffice-ux-advise] [Bug 148782] "Left frame border" and "Right frame border" options for Horizontal "to" position in Position and Size for shapes should be changed to "Left of frame text area" an
https://bugs.documentfoundation.org/show_bug.cgi?id=148782 sdc.bla...@youmail.dk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||8902 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148153] Frame should respect page margins
https://bugs.documentfoundation.org/show_bug.cgi?id=148153 --- Comment #6 from Dieter --- (In reply to RGB from comment #5) > If I understand the problem right, a part of it is already implemented: on > the frame properties → Type tab → the very last check box, "keep inside text > boundaries," does exactly what the label says :) Thank you for the hint, but as far as I can see, this is only true for top and bottom margin and it doesn't work for left and right margin. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148153] Frame should respect page margins
https://bugs.documentfoundation.org/show_bug.cgi?id=148153 RGB changed: What|Removed |Added CC||rgb.m...@gmail.com --- Comment #5 from RGB --- If I understand the problem right, a part of it is already implemented: on the frame properties → Type tab → the very last check box, "keep inside text boundaries," does exactly what the label says :) The other part of the problem, frames covering footnotes, I agree it's covered by Bug 132248. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 91147] Graphics objects not replaced/overwritten when Paste is used on the marked object
https://bugs.documentfoundation.org/show_bug.cgi?id=91147 Buovjaga changed: What|Removed |Added Keywords|bibisectRequest, regression | Version|4.4.0.3 release |Inherited From OOo Priority|medium |low OS|Windows (All) |All CC||ilmari.lauhakangas@libreoff ||ice.org Severity|normal |minor --- Comment #9 from Buovjaga --- Tested with 3.3.0, 3.5.0, 4.1, 4.2, 4.3, 4.4 and in none of these version do I see: Expected result (as it was for centuries ;) C is replaced by R. So either this centuries-old behaviour was in OpenOffice.org times or this is just a request to do something else than this admittedly unexpected thing. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148153] Frame should respect page margins
https://bugs.documentfoundation.org/show_bug.cgi?id=148153 Dieter changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147880] FEATURE REQUEST: You can indicate @ to call functions in LibreOffice Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=147880 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added Blocks||108019 Whiteboard| QA:needsComment| Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108019 [Bug 108019] [META] Calc UX bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 113603] Enhancement: unified table management in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=113603 --- Comment #16 from Adalbert Hanßen --- (In reply to Heiko Tietze from comment #15) > *** Bug 148867 has been marked as a duplicate of this bug. *** This is also a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=148867, but the proposed enhancement here is much better and general one than my later one! -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 113603] Enhancement: unified table management in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=113603 Heiko Tietze changed: What|Removed |Added CC||adalbert.hans...@gmx.de --- Comment #15 from Heiko Tietze --- *** Bug 148867 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148867] The difficulty to select a whole Table in order to manipulate its properties
https://bugs.documentfoundation.org/show_bug.cgi?id=148867 Heiko Tietze changed: What|Removed |Added Resolution|WORKSFORME |DUPLICATE --- Comment #7 from Heiko Tietze --- So let's draw more attention on this issue. *** This bug has been marked as a duplicate of bug 113603 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148867] The difficulty to select a whole Table in order to manipulate its properties
https://bugs.documentfoundation.org/show_bug.cgi?id=148867 --- Comment #6 from Adalbert Hanßen --- (In reply to Heiko Tietze from comment #5) > (In reply to Roman Kuznetsov from comment #3) > > My POV => wontfix > > Or duplicate of bug 113603. Heiko, you are right: The other suggestion is much more general than mine, and it covers other things that I've often been annoyed with as well. Most importantly, it would create a more consistent operation between LO Writer and LO Calc. Too bad that nothing has happened after a productive discussion on this proposal since 2019! -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146445] Change behaviour of anchor to character in an empty paragraph (see comment 15)
https://bugs.documentfoundation.org/show_bug.cgi?id=146445 --- Comment #18 from Dieter --- (In reply to Mike Kaganski from comment #16) > So please drop that "below". Or the result will quickly become even more > confusing. Second try: So let me give some resons for solution a) 1. Consisteny I: If we have anchor to (an empty) paragraph order seems to be: paragraph start | cursor | anchor (to paragraph) | paragraph end 2. Consistency II: Similar behaviour in an empty paragraph and in a paragraph after inserting a character. 3. Consistency III: There should be the same behaviour as in empty paragraphs without an anchor: New paragraph is inserted after the paragraph (So I assume, this is what users also expect for empty paragraphs with an anchor to character inside) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146445] Change behaviour of anchor to character in an empty paragraph (see comment 15)
https://bugs.documentfoundation.org/show_bug.cgi?id=146445 --- Comment #17 from Mike Kaganski --- (In reply to Mike Kaganski from comment #16) > If you suggest to make insertion of paragraph *before* the anchor ... I'm sorry to create even more confusion. I meant to write "after" where I typed that "before". Sorry. So please read the above as > If you suggest to make insertion of paragraph *after* the anchor ... -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146445] Change behaviour of anchor to character in an empty paragraph (see comment 15)
https://bugs.documentfoundation.org/show_bug.cgi?id=146445 --- Comment #16 from Mike Kaganski --- (In reply to Dieter from comment #15) > Just let me rephrase, what I understand Your rephrase is very correct. Only one, very specific problem in your following explanation (the UX problem itself, and the proposal that you suggest, looks OK to me): > 3. User expectations: If there is an image with an empty paragraph below and > user presses enter we can assume, ... Please do *not* talk in terms of "below/above" in such cases. As I explained in the end of comment 13, the relative position of object and its anchor point is absolutely irrelevant. As soon as you try to define your proposal in terms of "user sees the image above the cursor -> they expect this or that" ... you create a huge inconsistency potential. If you suggest to make insertion of paragraph *before* the anchor when the anchor is the only paragraph contents, then it should be the only behavior: we must do it no matter if the image is above, or below, or to the left or to the right, when it's positioned absolute or relative ... So please drop that "below". Or the result will quickly become even more confusing. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146445] Change behaviour of anchor to character in an empty paragraph (see comment 15)
https://bugs.documentfoundation.org/show_bug.cgi?id=146445 Dieter changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords|bibisectRequest, regression |needsUXEval Severity|normal |enhancement Summary|Anchor of image moves to|Change behaviour of anchor |next paragraph when type|to character in an empty |Enter key at original |paragraph (see comment 15) |(empty) paragraph | --- Comment #15 from Dieter --- (In reply to Mike Kaganski from comment #13) > and that means, for empty paragraph, that the > inserted anchor is *before* ... what? it's before the paragraph end, which > serves the anchoring point in this case. So when you put a cursor into an > empty paragraph, it is *after* paragraph start, and *before* paragraph end; > when you press Enter, you logically insert a "paragraph end - paragraph > start" pair in the place where your cursor is, moving the existing old > paragraph end to the following new paragraph; and since that moved paragraph > end is the anchoring point, the anchored object moves accordingly. Thank you for your detailed explanation. Just let me rephrase, what I understand and let me explain, why I still see inconsistency here and a need for an enhancement: After inserting an image in an empty document, we have empty paragraph below document and order within this paragraph is: paragraph start | anchor | paragraph end After placing cursor in that empty paragraph we have: paragraph start | cursor | anchor | paragraph end Scenario A: press enter => paragraph break between paragraph start and anchor => New empty paragraph before image (so this is, what you explained as expected behaviour and I can understand it now and therefore I won't consider the current behaviour a bug) Scenario B: Press spacebar (or any character) (Order within paragraph is: paragraph start | character (with connected anchor to character) | cursor | paragraph end) Press Enter => New paragraph after the old paragraph and anchor to character is still part of the old paragraph (Expected) So I think we can reduce problem to the question: To what should we anchor an anchor to character, if there is no character inside a) paragraph start => with cursor we have order: paragraph start | anchor | cursor | paragraph end (I would prefer this solution) b) paragraph end => with cursor we have order: paragraph start | cursor | anchor | paragraph end (current behaviour) c) Not possible to have anchor to character in an empty paragraph So let me give some resons for solution a) 1. Consisteny I: If we have anchor to (an empty) paragraph order seems to be: paragraph start | cursor | anchor (to paragraph) | paragraph end 2. Consistency II: Similar behaviour in an empty paragraph and in a paragraph after inserting a character. 3. User expectations: If there is an image with an empty paragraph below and user presses enter we can assume, that he would like to insert a new paragraph below the empty paragraph and not above the image (this is at least what he sees as a result). So I would see it as enhancement, I've changed bug summary and added design-team for additional input. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148848] Make "Auto Spellcheck" a module-level or document-level option
https://bugs.documentfoundation.org/show_bug.cgi?id=148848 Heiko Tietze changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148823] Mail Merge Email Settings confirmation should not be needed each time
https://bugs.documentfoundation.org/show_bug.cgi?id=148823 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mentoring@documentfoundatio ||n.org Keywords|needsUXEval |difficultyMedium, easyHack, ||skillCpp, skillDebug --- Comment #5 from Heiko Tietze --- Code pointer: In sw/source/ui/dbui/mmresultdialogs.cxx at IMPL_LINK_NOARG(SwMMResultEmailDialog, SendDocumentsHdl_Impl, weld::Button&, void) we have if (xConfigItem->GetMailServer().isEmpty() || !SwMailMergeHelper::CheckMailAddress(xConfigItem->GetMailAddress()) ) which seems to cause the trouble. Some debugging needed here. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 91147] Graphics objects not replaced/overwritten when Paste is used on the marked object
https://bugs.documentfoundation.org/show_bug.cgi?id=91147 --- Comment #8 from Heiko Tietze --- My first thought was that overwriting content needs an explicite selection with some highlighting. And selecting a shape wont highlight. But images are replaced! I wonder what commit introduced the change. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148867] The difficulty to select a whole Table in order to manipulate its properties
https://bugs.documentfoundation.org/show_bug.cgi?id=148867 --- Comment #5 from Heiko Tietze --- (In reply to Roman Kuznetsov from comment #3) > My POV => wontfix Or duplicate of bug 113603. -- You are receiving this mail because: You are on the CC list for the bug.
