[Libreoffice-ux-advise] [Bug 113235] Better wording for "Tools > Options > Calc > General .. Use legacy cursor movement behavior when selecting"
https://bugs.documentfoundation.org/show_bug.cgi?id=113235 --- Comment #7 from Heiko Tietze --- (In reply to Cor Nouws from comment #6) > test harder ;) /done & confirming that it works (guess I messed up with the setting yesterday) -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 113603] Enhancement: unified table management in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=113603 --- Comment #4 from Heiko Tietze --- Created attachment 137588 --> https://bugs.documentfoundation.org/attachment.cgi?id=137588&action=edit Mockup for simple table management Word cuts out the col/row and inserts it above or left of the new selection. User feedback is given via cursor which turns into an arrow down/left at the respective position at the table (plus a 'select all' floating button at top/left). We do the same for user feedback, and I think that's sufficient. Adding a lot of decorations around the table on hoover might be annoying for most users who don't want to manipulate rows/cols and is not much helpful for the rest. I fully agree on the other hand with cutting the col/row and a 'natural pasting'. So when the clipboard contains structured data it should be added as this. Word extends the table if the cursor is not at the first col/row (e.g. at B2), which makes sense. Missing in Word is a way to simply copy the data and keep the structure. We could make this possible by keeping the current behavior when only cells are selected. But in case the full col/row is selected it should also use the table structure. Tried to illustrate this in the attachment. The proposal doesn't consider a selection within the table (e.g. A2:B3). In this case Word and Writer work the same way and keep the source structure intact and paste the content into the target cells (data are overridden without warning). Would keep this. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 104463] Remove text selection handles
https://bugs.documentfoundation.org/show_bug.cgi?id=104463 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com |.freedesktop.org| --- Comment #5 from Heiko Tietze --- Another issue with the handles is that you cannot extend the selection downward starting from top or upward starting at bottom. For example, C3:E6 is selected and you shrink the selection beginning at C3 it ends at E6 and becomes F7 going beyond. Starting at E6 you shrink to C3 and then B2, or the like. Using the conventional cell style selection (of course only at the initial state) it expands from the end point into E6:G8 or A1:C3. Removing needsUX. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 101731] Rename gradient 'border' label to something more meaningful
https://bugs.documentfoundation.org/show_bug.cgi?id=101731 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |gautier.sop...@gmail.com, |.freedesktop.org|olivier.hallot@documentfoun ||dation.org, ||tietze.he...@gmail.com --- Comment #1 from Heiko Tietze --- "Transition point" sounds good to me (not making it clearer to the user, though). Any objection from the l10n team, Sophie, or documentation, Olivier? If not I guess you can patch yourself :-). -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 99027] [FORMATTING] Default table border width is useless
https://bugs.documentfoundation.org/show_bug.cgi?id=99027 --- Comment #20 from sophie --- (In reply to Yousuf Philips (jay) from comment #19) > (In reply to Cor Nouws from comment #18) > > I would choose one that is visible with printing, and still nicely thin on > > the screen. Be it 0.5 or 1.0 pt - fine for me. > > So we are going with 0.5pt, as will be used it in the default table style > (bug 107554), common default width used in other word processors, and it was > the second listbox option found in LO 3.3. > > Use 0.5pt with the border toolbar control > https://gerrit.libreoffice.org/44369 +1 on my side too - Sophie -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 98728] Remember last saved location
https://bugs.documentfoundation.org/show_bug.cgi?id=98728 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Status|NEW |RESOLVED CC|libreoffice-ux-advise@lists | |.freedesktop.org| Resolution|--- |DUPLICATE --- Comment #5 from Heiko Tietze --- Let's keep things together -> dup of bug 89969 My take is to keep the last used directory on all systems. Not only for the actual document but also when exporting a graphic as PNG, for example. There is likely a ticket about this issue. *** This bug has been marked as a duplicate of bug 89969 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 98205] Text for limitation of auto filter items is not shown when the widget is opened again
https://bugs.documentfoundation.org/show_bug.cgi?id=98205 --- Comment #3 from Heiko Tietze --- Created attachment 137592 --> https://bugs.documentfoundation.org/attachment.cgi?id=137592&action=edit Example document for autosearch Document contains dummy text that has been auto filtered by the term "he". The list shows cells like "another" that contains the actual search term which is not shown when the auto filter is opened again. Please remember the search term in the respective field. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 98205] Text for limitation of auto filter items is not shown when the widget is opened again
https://bugs.documentfoundation.org/show_bug.cgi?id=98205 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists | |.freedesktop.org| Component|LibreOffice |Calc -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 113603] Enhancement: unified table management in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=113603 --- Comment #5 from Christian Lehmann --- Hi Heiko, not being a developer, I am, of course, in no position to fight for my proposal. Nevertheless, here are a few clarifications: - According to my proposal, a frame is drawn around a table if the user is editing the table. This would be as helpful in Writer as it is in Calc. - Doing anything with the table just only because the cursor is hovering over it does not seem a good idea to me; this might indeed be annoying to the user. - The point is not to give the user feedback on the state that Writer is currently in. The point is to render table management clear and simple. In my proposal, I had counted numbers of mouse clicks and keys pressed. None of the alternate proposals that have been mentioned fare better on this count. - My proposal is not restricted to operations of Copy/Cut/Paste (incl. Shift). It offers unified management of a whole set of further table operations. Moreover, is uniformity across different applications in LO not a virtue? - Is it an essential aspect of LO policy that it should imitate MS Word? Particularly in questions of table management, this would seem a bad idea to me. (There are, to be sure, features in which Word does fare better.) - When you write "The proposal doesn't consider a selection within the table (e.g. A2:B3)", you are not referring to my proposal, are you? Its entire section 2 is devoted to this problem. Cheers, Christian -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 113603] Enhancement: unified table management in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=113603 Heiko Tietze changed: What|Removed |Added Keywords||needsDevEval --- Comment #6 from Heiko Tietze --- (In reply to Christian Lehmann from comment #5) > ...I am, of course, in no position to fight for my proposal. As a user you are in the best position to fight. Don't hesitate to go ahead. > - When you write "The proposal doesn't consider a selection within the table > (e.g. A2:B3)", you are not referring to my proposal, are you? Its entire > section 2 is devoted to this problem. You talk about this use case in the first 2) but not further. Don't think anything is missing but wanted to add this for clarification- current behavior is good for cells only selections. Other than that I like how iWorks does the job (Jay's screencast). Looks like a lot of work, not really suited for GSoC. Any dev opinion about this? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 113129] DRAWING OBJECTS: rotate center of the previous object is kept when switching from one object to another
https://bugs.documentfoundation.org/show_bug.cgi?id=113129 Buovjaga changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||todven...@suomi24.fi --- Comment #1 from Buovjaga --- Ljiljan: what do you propose as the new workflow for using another object as rotation center, then? Or just drop it and stick with "drag the pivot point away from the center of selected object"? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 86404] use Ctrl+TAB to switch between tabs/sheets
https://bugs.documentfoundation.org/show_bug.cgi?id=86404 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |easyHack, needsDevEval CC|libreoffice-ux-advise@lists | |.freedesktop.org| Component|LibreOffice |Calc --- Comment #10 from Heiko Tietze --- The change request relevant without any doubt. Default shortcut to switch between tabs is ctr+tab. And users obviously comprehend sheets as tabs. Guess it's a very simple change in officecfg/registry/data/org/openoffice/Office/ Should work for JumpToPrevTable as well as JumpToNextTableSel (Edit > Select > Select to next/previous sheet)- including shift in this case. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 113603] Enhancement: unified table management in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=113603 --- Comment #7 from Christian Lehmann --- > - When you write "The proposal doesn't consider a selection within the table > (e.g. A2:B3)", you are not referring to my proposal, are you? Its entire > section 2 is devoted to this problem. You talk about this use case in the first 2) but not further. Don't think anything is missing but wanted to add this for clarification- current behavior is good for cells only selections. Please don't forget that my first proposal, of 2.11.17, has an attachment, called writer_tables.odt, which describes this and other aspects in detail. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 113603] Enhancement: unified table management in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=113603 --- Comment #8 from Christian Lehmann --- > Other than that I like how iWorks does the job (Jay's screencast). Indeed, pretty good. But how does one insert new or shifted columns/rows at a certain position? For shifting a column/row, you don't need my little triangles; a wandering arrow or red line, as in Thunderbird's bookmarks management, would be sufficient. But for inserting new columns/rows, I cannot think of a more user-friendly solution. (Consider that inserting in front of a certain position 1) is programmer's thinking and 2) does not work if you want to add them after the last column/row. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
