[Libreoffice-ux-advise] [Bug 154808] Writer - protected section - allow to insert content into fields
https://bugs.documentfoundation.org/show_bug.cgi?id=154808 --- Comment #13 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #8) > Write protection is exactly meant to protect the content > and there are probably many other ways to define a form with static text > and some input fields. I'm not sure I understand what you mean. As a document author, I may want to protect * just field values, not other content (unlikely, but maybe there's a use case for this); * all content other than field values (very common); * both (somewhat common I guess, conditioned on having fields at all). How, in your opinion, should each of these happen? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153749] Allow entering textbox edit mode with single click instead of double-click
https://bugs.documentfoundation.org/show_bug.cgi?id=153749 --- Comment #10 from Eyal Rozenberg --- My 2 cents: I oppose changing the global default; oppose extending quick-edit-mode to charts based on comments above; but perhaps extending it to other textboxes in Calc and Write makes sense at least for better consistency. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #23 from Attila Szűcs --- justified alignment means text are from left margin to right margin... so, spaces after last letter MUST be on the margin. dropping spaces to new line wont help here.. only if we break the justified alignment.. but i bet we dont want to do that... justified alignment is a commonly used good feature. (justified is not the only problem, but seemed easy to explain) If we accept spaces on margin.. we can choose to A) hide all those spaces.. B) try to show all spaces C) try to show some spaces.. and maybe have some tricks A) all spaces was hidden before my commit... pro: there was nothing to argue about, if the space/cursor is over the margin or the page, or cell border... con: we dont have a chance to find extra spaces if that is a problem.. + cursor movement problems B) showing all spaces is impossible normally .. if i insert 1 million spaces.. ?! ... would we make a scrollbar 1 times wider as the page itself?! :) C) showing some spaces is what i tried to achieve... pro: we can see some extra spaces, and may move on them ... practically we can eliminate A) con part for a limited amount of spaces... in default case it is about 20 space con: after the limited amount of spaces it will have some problems... based on what we do after it.. i did not do much after it .. because: 1) That was the fastest way :) (doing nothing :) ) However i handled a few special cases i found.. like if you put an image into the text... i made sure the cursor wont be displayed under/after the image 2) naively i thought having ~100 meaningless spaces is a so rare case, that we could accept that is a bit ugly , and suggest to delete some of them.. :) 3) There is many special cases that should be handled, and i dont even know every case... if you found 1 and report it.. someone may fix that case.. But dont forget.. we can mix A) and C) in different cases or based on an option.. like a toggle button to show spaces or not... or whatever... I think we should rather analyze the special cases where and what is the problem.. and set the limitation based on that... For example .. i thought having cursor + extra spaces go from margin only untill the page end .. would be better... then it would be like A) with a bit of extension.. that is will work for like 20 spaces better it is good that someone mentioned that in tables it is a bigger problem.. we should fix it... we could disable this behaviour there.. and fallback to A) case... i think Or if someone would find a common solution.. where not to display or move the cursor.. / display the spaces... but im not sure if we could find a common solution.. Selection is just an other special case i did not fixed because of 1) .. :) but if i have to fix all related problems while i fix a bug... then i wont be able to fix any complex problems. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151637] Allow to create document structure in Impress documents for PDF export
https://bugs.documentfoundation.org/show_bug.cgi?id=151637 Stéphane Guillou (stragu) changed: What|Removed |Added Depends on||71854 Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org Version|unspecified |Inherited From OOo Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Stéphane Guillou (stragu) --- We would first need to implement bug 71854. Then, we could have several options available in the PDF export dialog for "Export bookmarks", or as recommend in bug 107932 comment 7, "Export outline". These could be "Sections" and "Titles". Would that make sense, UX team? Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=71854 [Bug 71854] UI: Missing functionality to organize presentation in "Slide Pane" (should allow group, expand, collapse slide objects) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #22 from William Friedman --- I very much appreciate Attila's detailed analysis and especially his concern with breaking older docs. I certainly agree that existing users should not be penalized for having made docs that worked with existing quirks/bugs. At the same time, that's a recipe for stagnation. Compatibility flags/options may be the only way to balance stability/backwards compatibility with innovation and progress. As for the concern that "If we "offer a compatibility option to retain them, but *not* display them" then we resurrect the original bug reports, as we wont be able to see it" -- couldn't they only be made visible with "Formatting Marks" enabled? BTW, with the current implementation, even with "Formatting Marks" enabled, you can no longer see extra spaces (in the form of vertically-centered blue dots) beyond the right hand *page* (not margin) boundary, even though the cursor goes into the gray area beyond the page boundary. More than that -- you can't click the cursor onto spaces that go into the gray area. Clicking on the gray area on a line that has spaces going into the gray area beyond the page boundary puts the cursor at the boundary of the page; you can then press the right arrow or end to get to the end of the spaces. And, as Attila points out, "And at MS the selection is displayed even over the margin.. at LO you can select those spaces, it just dont display the selection." This is yet another problem with the current implementation. Selection should show exactly which characters have been selected so that the user will know what is being affected with the next edit. Upon reflection, it seems that there are really two issues here, which are separable but intimately connected: 1) One is the layout issue -- how are trailing/leading spaces actually treated: do they wrap to the next line, do they extend infinitely, or are they disallowed/truncated? The second is the cursor movement issue, which only shows up if trailing spaces are allowed to extend infinitely. In terms of the layout issue, extending infinitely seems to me the absolute worst possible choice of the three (so of course MS Word went with that option! :-) ), and I think it is deserving of serious reevaluation. 2) The second is the cursor movement issue, which of course only appears if trailing spaces are allowed to extend infinitely. The guiding principles, to my mind, should be: A) the cursor should never disappear, as it now does if you right justify a line and type LTR spaces past the left margin -- try it with Formatting Marks on, the spaces suddenly shift to the right and disappear off the right end of the page! B) you should always be able to click to place the cursor in existing text. You can't right now, because if spaces extend into the gray area beyond a page border, you can't click there. This also addresses Attila's concern that "we may could revert the cursor movement fix, and leave only the extra space display... you wont be able to move cursor into wrong places... but cursor movement will be confusing.. even more as it was long before... because now you would see the spaces, but you wont be able to click into it" -- you already can't fully click into it in the current implementation! C) if selecting text, *all* of the text to be affected should be highlighted (currently not the case, because spaces beyond the page *margin* are not highlighted). In the immediate term, I would vote to revert the new cursor implementation, which in my experience causes more problems than it solves. In the longer term (which I hesitate to say, since in LO terms that has meant and could mean decades!), I think a full re-evaluation of how trailing/leading spaces are handled is in order. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #21 from V Stuart Foote --- As this has moved into the UX-advise arena, I would move to truncate the excessive spaces aggressively. - Any new document would have sane line wrap and paragraph/page/cell margin. - Any existing document would add additional lines--easily corrected by Find-Replace actions and application of style. Perpetuating the odd MS Word handling using characters for layout and formatting is simply not supportable given LO preference for style based layouts over DF. At a minimum--implement the same "truncate surrounding whitespace for line" on *Center* that MS provides to efficiently remove the excess space padding. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #20 from Attila Szűcs --- About following MS... i only made visible the spaces after line end (over margin), and made the cursor visible there too. Those spaces was already there, and the user was able to navigate there, but it was confusing why the cursor seems not to move sometimes.. like in tdf#120715 where the cursor moved between spaces.. peoples still tohught it stucked. And i was very careful with layout... if we start to interpret the spaces over the end of line differently... like droppoing them to new line... many old document may change.. some 1 page long forms may become 2 page long.. we can make a compat flag to have 2 different behaviour.. but then it may become too confusing, when spaces goes to new line, and when not... If we trucate the spaces we probably break already made documents... (dont forget.. users may used this unintentionally.. if he made his doc looks good with this 'error' if we fix it, he will only see that we broke his doc... ) If we "offer a compatibility option to retain them, but *not* display them" then we resurrect the original bug reports, as we wont be able to see it. If we think so complex resolutions then it still easyer to make an option, to display spaces/cursor this way, or the previous way... because the document, and the layout would be the same.. only the visibility of cursor, and extra spaces would be changed Sorry about the confusion with the cursor movement... i was mistakenly believed that wont be a big problem, and if a user put more spaces after end of line, then in most case it is a mistake... But i did not checked tables.. and it can be easyly annoying.. I dont want to advertise MS office.. but i think they made this thing very well... the only difference i see with actual LO is that MS does not display spaces/cursor when it is over some logical boundary... I mean after page end, it does not display the cursor.. (the cursor wont be visible) In table it diplay sapces/cursor only in the cell.. but sure you can put more spaces, and move the cursor out from the cell.. you just wont see the extra spaces/cursor... If there is an image over the text.. i mean the text is around the image... then the spaces/cursor displayed only until the image... you can put more spaces and run throught the image... but you wont see that. And at MS the selection is displayed even over the margin.. at LO you can select those spaces, it just dont display the selection. If i will have some spare time i can check if i could hide cursor in some of these cases, but there may be a lot of special cases i didnt even thought about... i'm not sure if i could find them easily... if anyone want, feel free to do it.. :) Or we may could revert the cursor movement fix, and leave only the extra space display... you wont be able to move cursor into wrong places... but cursor movement will be confusing.. even more as it was long before... because now you would see the spaces, but you wont be able to click into it.. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #19 from William Friedman --- Thank you everyone for the engagement around this issue. I agree with V. Stuart Foote's comment #18: "we really should be breaking lines at paragraph/object margins--wrap like other sane word processors and text editors." As for what should be done with the "extra" spaces: 1) I tend to oppose imposing unnecessary limitations on users, even if I can't imagine any use case for manually inserted spaces at the end/beginning of lines. My preference would be to treat spaces at the end of a line like any other character, wrapping them and displaying them on the next line. 2) If this is a problem, then second best would be to ignore the attempt to insert spaces at the end/beginning of lines, and to truncate such spaces automatically when importing Word documents (or to offer a compatibility option to delete or retain them, but *not* display them, as was the behavior prior to LO 7.5). 3) Alternatively, in the interest of maximizing user flexibility/customization, a checkbox could be added somewhere under Tools | Options | LibreOffice Writer: "Allow trailing/leading spaces" -- when checked, spaces would be treated as regular characters, wrapped at the end of lines, and displayed normally (as I suggested in 1 above); when unchecked, no trailing/leading spaces would be permitted, and pressing space at the end or beginning of a line would have no effect (as I suggested in 2 above). 4) Regarding the issues caused by such spaces with centered/justified alignments, I would advocate for a checkbox somewhere under Tools | Options | LibreOffice Writer: "Truncate trailing spaces in center/justified alignments." -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #18 from V Stuart Foote --- Sorry, clearly not a Harfbuzz issue--spaces are stamped correctly between actual text. Whole question is interesting in that MS Word apparently had (through Word 2010, and still supported for .doc binary formats) a '"Wrap trailing spaces to the next line" (for compatibility with WordPerfect)'. Also referred to a Word6 handling. But there is no apparent functional use for the spaces extending beyond the paragraph/page margin, and MS Word user forums advise to use a + to insert a line break. Smells like DF to me--MS's "solution". Why are we following MS's lead here for handling excess spaces? Seems we really should be breaking lines at paragraph/object margins--wrap like other sane word processors and text editors (including MS Notepad). MS Word user forums suggest: 'Select' the full line of text (including all over the edge spaces), and 'Center' it (with +E shorcut) to delete all extra spaces, then still selected 'Align it' where preferred. Unfortunately, in LO Writer the centering action does not remove the extra spaces in similar fashion. @Attila, truncate on centering might be useful if we continue with parity in function. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146488] Callout does not snap to the object
https://bugs.documentfoundation.org/show_bug.cgi?id=146488 Heiko Tietze changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Heiko Tietze --- Taking Reginas comment to resolve the report as WF. The workaround is to simply use two shapes, the cloud serves well as speech bubble, and to add a connector manually. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146488] Callout does not snap to the object
https://bugs.documentfoundation.org/show_bug.cgi?id=146488 --- Comment #7 from Regina Henschel --- A connector is the element in markup. It has the special attributes draw:start-shape, draw:start-glue-point, draw:end-shape and draw:end-glue-point. These attributes determine a relation ship to other shapes. These attributes are specific for the element and not available for other kind of shapes. Handles in custom shape callouts or the tail tip of the classical callout are defined relative to the shapes rectangle, which has the text. There exists no attribute to describe a relationship to another shape. Therefore it is principle impossible to glue a handle or a tail tip to a glue point. Changing the current behavior would require changing the ODF standard. I would vote against doing it for custom shape callouts, because custom shapes are designed to be compatible with shapes of MS Office. I could imagine adding such feature to the classical callouts. But who will implement it? Moving a callout together with the object, to which it points, could be solved by grouping them. But there is still the problem of using glue points of objects, which are inside a group (bug 76277, bug 106621). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155393] Crash in SfxShell::GetViewShell()
https://bugs.documentfoundation.org/show_bug.cgi?id=155393 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Status|NEW |ASSIGNED Assignee|libreoffice-b...@lists.free |rayk...@gmail.com |desktop.org | --- Comment #10 from Heiko Tietze --- (In reply to Stéphane Guillou (stragu) from comment #9) > just wanted to make sure others were notified... LGTM > (And possibly get a +1 on gerrit!) done -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155502] Cannot scale image to edge of paper size despite margins set to zero
https://bugs.documentfoundation.org/show_bug.cgi?id=155502 Heiko Tietze changed: What|Removed |Added Severity|normal |enhancement OS|Windows (All) |All CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|UNCONFIRMED |NEW See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||5509 Ever confirmed|0 |1 Keywords|needsUXEval |needsDevAdvice --- Comment #3 from Heiko Tietze --- Scaling the image beyond the page width (or height) is not possible, yet. But a reasonable expectation; I wonder if there is any reason to limit the scaling to the page size (if so we could auto-crop the remaining part). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146488] Callout does not snap to the object
https://bugs.documentfoundation.org/show_bug.cgi?id=146488 Heiko Tietze changed: What|Removed |Added Blocks||108742 --- Comment #6 from Heiko Tietze --- Regina, are there good reasons to not glue the connection lines of callouts? Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108742 [Bug 108742] [META] Shape points (glue points) bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146488] Callout does not snap to the object
https://bugs.documentfoundation.org/show_bug.cgi?id=146488 bna...@web.de changed: What|Removed |Added Version|unspecified |7.4.3.2 release --- Comment #5 from bna...@web.de --- (In reply to Heiko Tietze from comment #3) > What exactly do you mean with speech bubble? Ok, the english documentation name it 'callouts' > And "snap-in the connection" is also not clear. Snapping means you drag an > object and some points are "magnetic"; Exact. Create a object and use a connector line. The endpoint of the line snap to the glue point of the object. But the connector line of the 'callout' object does not snap to the glue point. So, if I adjust the position of a object I have to correct the corresponding callout object. (resp. the connection line of the callout object) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 143500] Calc EDITING - Add option to keep the original selection after "Find and Replace / Replace All"
https://bugs.documentfoundation.org/show_bug.cgi?id=143500 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Heiko Tietze --- Duplicate of bug 132031, discussed recently in bug 141296 *** This bug has been marked as a duplicate of bug 132031 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146488] Callout does not snap to the object
https://bugs.documentfoundation.org/show_bug.cgi?id=146488 --- Comment #4 from bna...@web.de --- (In reply to LeroyG from comment #1) > Please copy and share the information from menu Help - About LibreOffice. Version: 7.4.3.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #17 from Heiko Tietze --- Breaking the white space has no value; the hanging indent should be done via paragraph attribute. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 141042] Feature request: add a new function REVERSE(string)
https://bugs.documentfoundation.org/show_bug.cgi?id=141042 Heiko Tietze changed: What|Removed |Added CC||er...@redhat.com, ||rb.hensc...@t-online.de --- Comment #4 from Heiko Tietze --- (In reply to Buovjaga from comment #3) > I could not find such a function for Excel (just tried to find documentation > online). Would it be a compatibility problem to add it? Likely a showstopper. And Miguel shared a solution that is working out of the box. Could imagine that this also can be done with Regex. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 --- Comment #16 from خالد حسني --- (In reply to V Stuart Foote from comment #14) > @Khaled, could this be a Harfbuzz composition issue? What width for a space > is used for composing line wrap position a line of text against > document/paragraph margins? Tabs are not similarly affected--just strings > of characters. No relation to HarfBuzz here, space is a character like any other character and its glyph takes the advance width specified in the font. The decision to collapse spaces at the end of the line is a higher level decision. As for the issue here, this behavior seem unusual to me. I don’t have MS Office to check, but I tested TextEdit and Pages and both keep the cursor at the end of the line no matter how many spaces as entered. I think a survey of how different text editors and office suites handle this situation might be in order, but I can’t imagine the cursor going infinitely into the margin is something common. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146488] Callout does not snap to the object
https://bugs.documentfoundation.org/show_bug.cgi?id=146488 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO CC||rb.hensc...@t-online.de --- Comment #3 from Heiko Tietze --- What exactly do you mean with speech bubble? I can add a "cloud" from symbolic shapes and connect this with any other shapes. And "snap-in the connection" is also not clear. Snapping means you drag an object and some points are "magnetic"; snap lines and page margin by default object frames/points optional. The connector line uses so called glue points, see https://help.libreoffice.org/7.5/en-US/text/simpress/guide/gluepoints.html -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155257] Document recovery dialog should not delay the opening of unrelated files
https://bugs.documentfoundation.org/show_bug.cgi?id=155257 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |needsDevAdvice CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #3 from Heiko Tietze --- Reasonable request but what do we do in case the application is started with the very same document that crashed last time? Could imagine to show the recovery dialog first in this case and non-modal in all other situations. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155494] Cursor goes beyond margins when typing spaces at the end of a line
https://bugs.documentfoundation.org/show_bug.cgi?id=155494 Heiko Tietze changed: What|Removed |Added Keywords||needsUXEval --- Comment #15 from Heiko Tietze --- How about keeping the current functionality for centered/justified paragraphs but wrap spaces in case of left/right-aligned? The progressive space as implemented today is easy to understand (assuming non-printable character are visible) and familiar for users coming from other office suits. And it sounds rather easy to add a condition that makes it dependent on the alignment. However, doing so breaks compatibility as MSO always continues right, which was always paramount for us. -- You are receiving this mail because: You are on the CC list for the bug.
