[Libreoffice-ux-advise] [Bug 147837] When merging cells, it is not good that 'Keep the contents of the hidden cell' is the default
https://bugs.documentfoundation.org/show_bug.cgi?id=147837 --- Comment #9 from JO3EMC --- I missed talking. Not all Microsoft behavior is better in this issue. There are some bad points, and I think it has advantages and disadvantages compared to LibreOffice. The best answer has not been determined. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147837] When merging cells, it is not good that 'Keep the contents of the hidden cell' is the default
https://bugs.documentfoundation.org/show_bug.cgi?id=147837 --- Comment #8 from JO3EMC --- Dialogs are certainly one approach, and I think it's not a bad way at this point for picking up all the requests. However, what is proposed here is the selection of the initial value there. My opinion is that "Empty the contents of the hidden cells" is better. Many of the people around me have similar ideas, and so far no one has any other ideas. Opinions are also exchanged in the Japanese category of Ask, and it is such a situation. https://ask.libreoffice.org/t/topic/74933 Although it deviates a little from the proposal of this issue. >From the perspective of not breaking existing data or formulas, "Keep the contents of the hidden cells" is certainly "safer". But I think that kind of safety is not necessary. Cell merging changes the appearance and structure of the "visible sheet". If the structure of the sheet changes, I think it may be natural that the written content is damaged, in a sense. Similar things usually happen with other cell operations. Rather, it is more dangerous that information that is difficult for the user to know is left in the "invisible place". It is difficult to follow the behavior of formulas, and also there is the risk of information leakage. "Safe" depends on the point of view. It seems more dangerous to me that it is harder to detect invisible data. The introduction of the "Hidden Row / Column Indicator" feature in LibreOffice 7.4 may also be from a similar perspective. I think the Bug 137780 introduced in Comment 5 is standing on this view. Data loss is usually visible. We can notice. If the data is promised not to be hidden, the awareness is even more certain. Microsoft doesn't always do the right thing, but it can be right. To me, Microsoft's judgment seems to be better on this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148357] When deleting a comment in Navigator, it changes position needlessly
https://bugs.documentfoundation.org/show_bug.cgi?id=148357 --- Comment #7 from Jim Raykowski --- (In reply to Eyal Rozenberg from comment #6) > Are there nightly Qt builds for Linux? For me, nightly builds are put in /usr/local/bin. Command line 'SAL_USE_VCLPLUGIN=gen /usr/local/bin/' will use VCL: x11 In order to test using qt5 backend you will need to install the libreoffice-qt5 package, for kf5 install libreoffice-kf5 package. SAL_USE_VCLPLUGIN=qt5 or SAL_USE_VCLPLUGIN=kf5 in place of SAL_USE_VCLPLUGIN=gen above. > Ok, but... I don't build my own version, I'm just a QA monkey, using > releases and nightlies. Patch should be in today's nightly. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148357] When deleting a comment in Navigator, it changes position needlessly
https://bugs.documentfoundation.org/show_bug.cgi?id=148357 --- Comment #6 from Eyal Rozenberg --- (In reply to Jim Raykowski from comment #5) > Eyal, I'm guessing you are using gtk3? Unfortunately, yes: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: fb9270b238cba4f36e595c5d7f4d85f6f3f18e1c CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Are there nightly Qt builds for Linux? > Here is one way to make the position not scroll after delete: > https://gerrit.libreoffice.org/c/core/+/132691 Ok, but... I don't build my own version, I'm just a QA monkey, using releases and nightlies. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148357] When deleting a comment in Navigator, it changes position needlessly
https://bugs.documentfoundation.org/show_bug.cgi?id=148357 Jim Raykowski changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |rayk...@gmail.com |desktop.org | Status|NEEDINFO|NEW --- Comment #5 from Jim Raykowski --- I've notice this also. It seems to be vcl backend dependent. Eyal, I'm guessing you are using gtk3? SAL_USE_VCLPLUGIN gen and qt5/kf5 don't scroll the next entry to the top after delete like gtk3 although there is also disruptive movement for them as well. Here is one way to make the position not scroll after delete: https://gerrit.libreoffice.org/c/core/+/132691 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148407] Need ability to cancel an ongoing paste action
https://bugs.documentfoundation.org/show_bug.cgi?id=148407 --- Comment #5 from Eyal Rozenberg --- (In reply to Telesto from comment #4) > I dislike a UI button, but simply press 'ESC' to kill the paste (simply > paste keep what's already pasted) That is fine with me. But - I remember that when we open a docx there someplace where we get a progress bar. Perhaps if there was a progress bar for pasting (under certain circumstances, e.g. shown after at least X seconds have passed etc.) then the text on the scroll bar could also say "(Esc to abort)" or something. > And this is yet again problematic, because there was no intention to have > 'link to images' but intended embedded images (when I opt for copy/paste). > Else you might lose images (link died) and well it makes files slow to open > > In general some could argue that a warning dialog would be appropriate > (infobar?). The file contains linked files to the internet, do you want to > download That sounds like a separate bug. Would you like to file it, or shall I? I have some stuff to say about these points, but I would like to say it on the separate bug rather than here. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148357] When deleting a comment in Navigator, it changes position needlessly
https://bugs.documentfoundation.org/show_bug.cgi?id=148357 --- Comment #4 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #3) > Nothing happens on right click. Indeed. > But if you delete an entry, comment here, > the tree is rebuilt. What exactly is scrolling in your case? Like I said: Before deleting, comment 2 was the first one visible (because we scrolled manually to that position); after deleting, scroll-down happens so that comment 7 is the first visible. Just to clarify: I'm referring to numbered comments in the attached document, not on this bug page. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148450] How is "Jump to Specific Page" supposed to work in Print Preview?
https://bugs.documentfoundation.org/show_bug.cgi?id=148450 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||108804 Summary|How is "Jump to Specific|How is "Jump to Specific |Page" supposed to work in |Page" supposed to work in |Print Preview |Print Preview? Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108804 [Bug 108804] [META] Print preview bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 139875] Page preview, need toggle button for system colours <> real colours
https://bugs.documentfoundation.org/show_bug.cgi?id=139875 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords||accessibility Blocks||103184, 101912, 102187 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=101912 [Bug 101912] [META] Accessibility (a11y) bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=102187 [Bug 102187] [META] Options dialog bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=103184 [Bug 103184] [META] UI theming bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 139875] Page preview, need toggle button for system colours <> real colours
https://bugs.documentfoundation.org/show_bug.cgi?id=139875 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|needsUXEval | Ever confirmed|0 |1 --- Comment #4 from Heiko Tietze --- Cannot understand why Cor and Stuart agree with the request. But anyway, let's accept then. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148282] Make sure thumbnails in start center are readable
https://bugs.documentfoundation.org/show_bug.cgi?id=148282 Heiko Tietze changed: What|Removed |Added Summary|Page Area in Start Center |Make sure thumbnails in |Does Not Respect|start center are readable |Application Colors Scheme | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Depends on||99116 --- Comment #5 from Heiko Tietze --- Rather than using an arbitrary hard-coded color for the dialog we should prefer the system theme, which should also fit with what was used to generate thumbnails in most cases. Suggestion is to not redraw thumbnails (on what basis?). Could imagine making this a DUP to bug 99116 but in the end it's another aspect: "Make sure thumnails are readable". Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=99116 [Bug 99116] StartCenter’s hardcoded color scheme doesn’t work for high-contrast mode users -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148257] Missing/unexposed ability to explicitly set the "language group" of a piece of text
https://bugs.documentfoundation.org/show_bug.cgi?id=148257 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval |needsDevAdvice --- Comment #10 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #6) > It's more than about a use-case, it's a matter of principle: > > * It does not make sense that setting a direction also sets the language. > * It does not make sense, and is not tolerable, that changing the direction > of a run of text changes its font. What bothers me in general on the ticket is using the language group for layouting. But I cannot judge on this topic since it affects basic development aspects. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148236] Allow reorder of Sections using the Navigator
https://bugs.documentfoundation.org/show_bug.cgi?id=148236 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #3 from Heiko Tietze --- (In reply to Cor Nouws from comment #2) > Sounds like fun to have. The opposite to usability... but anyway, let's keep the ticket alive if you see potential. I recommend to not implement features without clear use cases. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148128] Mark page center on horizontal and vertical rulers
https://bugs.documentfoundation.org/show_bug.cgi?id=148128 --- Comment #4 from Heiko Tietze --- Good idea to snap but I'm afraid it's a bit more difficult. First of all, the helplines are "volatile" in Writer - precise positioning is meant for Draw/Impress anyway. And if an object is selected the ruler measure the object in Writer while Draw only shows unobtrusive indicators. So these snap points would be for Draw/Impress. However, setting a precise value for helplines is possible right now per right click and I'm afraid of overloading the rulers. So my take is WF. Will leave this open for a while to get more input. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown
https://bugs.documentfoundation.org/show_bug.cgi?id=140900 --- Comment #11 from Heiko Tietze --- (In reply to chameleonscales from comment #10) > Created attachment 179372 [details] And what exactly would you like to change? Is it too large? Do you mean the collapsed drodpown or the expanded list? (In reply to chameleonscales from comment #0) > I would suggest providing a Preview size parameter in Tools > Options > > LibreOffice > View > Font Lists, right under Show preview of fonts. To enter a value for the size of one UI is probably not a solution to any problem. But if some adjustments are needed for high resolution I'm all in. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown
https://bugs.documentfoundation.org/show_bug.cgi?id=140900 --- Comment #10 from chameleonsca...@protonmail.com --- Created attachment 179372 --> https://bugs.documentfoundation.org/attachment.cgi?id=179372=edit Fonts dropdown list My screenshot -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148441] Should the view layout icons in the status bar be active when in Print Preview Mode, plus the blue highlighting does not match preview layout
https://bugs.documentfoundation.org/show_bug.cgi?id=148441 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||86066, 108804 Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=86066 [Bug 86066] [META] Bugs and improvements to the status bar https://bugs.documentfoundation.org/show_bug.cgi?id=108804 [Bug 108804] [META] Print preview bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148407] Need ability to cancel an ongoing paste action
https://bugs.documentfoundation.org/show_bug.cgi?id=148407 --- Comment #4 from Telesto --- Well I surely have had few freezes of up to 120 seconds.. Sometimes I even kill soffice.bin.. And in general I avoid webpastes to LibreOfffice (because of possible freezes) In cases of high bandwidth and proper internet connection it should freeze at all (it does). And in cases where of low bandwidth (and say large images) or bad internet connection there are merits for 'abort' I dislike a UI button, but simply press 'ESC' to kill the paste (simply paste keep what's already pasted) - Few other remarks.. However I speculate that failure of downloading the image (there is apparently a time-out at some point), well end up link to the image instead of embedding the image.. See bug 148027. And that stupid link gets accessed on every file-open (and if the linked domain being slow, it entails slow file opening.. waiting a minute for 50 kb file to open) because some 7 megabit file on some webserver at the other side of the world with small upload And this is yet again problematic, because there was no intention to have 'link to images' but intended embedded images (when I opt for copy/paste). Else you might lose images (link died) and well it makes files slow to open --- In general some could argue that a warning dialog would be appropriate (infobar?). The file contains linked files to the internet, do you want to download And the lovely is that those image which do refuse to be downloaded are mostly stuff of unimportance.. Facebook, Whatsapp buttons -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 144211] implement option to remember window size on a per document basis
https://bugs.documentfoundation.org/show_bug.cgi?id=144211 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=41 ||777 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 87542] Closing a component should not revert to start center
https://bugs.documentfoundation.org/show_bug.cgi?id=87542 --- Comment #4 from Heiko Tietze --- *** This bug has been marked as a duplicate of bug 41777 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 87465] Libreoffice does'nt remember its window state
https://bugs.documentfoundation.org/show_bug.cgi?id=87465 --- Comment #7 from Heiko Tietze --- *** This bug has been marked as a duplicate of bug 41777 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147837] When merging cells, it is not good that 'Keep the contents of the hidden cell' is the default
https://bugs.documentfoundation.org/show_bug.cgi?id=147837 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added CC||79045_79...@mail.ru --- Comment #7 from Roman Kuznetsov <79045_79...@mail.ru> --- Current behaviour is the best solution for this case I don't think it's the problem for anyone, because we have the excellent dialog with illustrations and nice labels -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147837] When merging cells, it is not good that 'Keep the contents of the hidden cell' is the default
https://bugs.documentfoundation.org/show_bug.cgi?id=147837 Heiko Tietze changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org OS|Windows (All) |All --- Comment #6 from Heiko Tietze --- Quite the opposite, keeping all data on merge is safer than cleaning up. Microsoft is not always doing the right things. Ultimately it's a conscious decision and the dialog shows clearly what happens. Other opinions? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148357] When deleting a comment in Navigator, it changes position needlessly
https://bugs.documentfoundation.org/show_bug.cgi?id=148357 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148357] When deleting a comment in Navigator, it changes position needlessly
https://bugs.documentfoundation.org/show_bug.cgi?id=148357 --- Comment #3 from Heiko Tietze --- Created attachment 179367 --> https://bugs.documentfoundation.org/attachment.cgi?id=179367=edit Screencast Nothing happens on right click. But if you delete an entry, comment here, the tree is rebuilt. What exactly is scrolling in your case? Version: 7.3.2.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.3.2-1 Calc: threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148357] When deleting a comment in Navigator, it changes position needlessly
https://bugs.documentfoundation.org/show_bug.cgi?id=148357 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 148407] Need ability to cancel an ongoing paste action
https://bugs.documentfoundation.org/show_bug.cgi?id=148407 --- Comment #3 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #2) > What use case would you cover with cancel? You changed your mind, That's it. > long-processing makes text irrelevant, you drink too much coffee since the > operation takes literally minutes (the whole page from the referenced bug is > pasted in ~10s here)? 10s is already enough to let me change my mind. But - that's a 20-line piece of a webpage with a few small images. Now suppose I pasted something that's 100x larger, by mistake. Am I supposed to wait 1000 seconds ? And if you sped it up by 10x - to wait 100 seconds? No. > Rather than aborting the operation we should speed-up the paste procedure. That would not solve the problem. LO still would needs this for large pasted content. > And the same cancel mechanism would be required for open or save (IIRC we > discussed this before but cannot find a ticket). Not sure about "Save", but for open - yes, it should definitely be possible to cancel an Open. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 141625] Calc Chart x-Axis Formatting
https://bugs.documentfoundation.org/show_bug.cgi?id=141625 --- Comment #4 from Heiko Tietze --- Created attachment 179366 --> https://bugs.documentfoundation.org/attachment.cgi?id=179366=edit Screenshot Situation with kf5 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 141625] Calc Chart x-Axis Formatting
https://bugs.documentfoundation.org/show_bug.cgi?id=141625 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||caol...@redhat.com Ever confirmed|0 |1 Blocks||103182 --- Comment #3 from Heiko Tietze --- Caolan, the large gtk3 controls spoil the size calculation here. Do you think a size_request() works well or should this be handled somewhere else, more generic? Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103182 [Bug 103182] [META] GTK3-specific bugs -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148407] Need ability to cancel an ongoing paste action
https://bugs.documentfoundation.org/show_bug.cgi?id=148407 Heiko Tietze changed: What|Removed |Added Keywords||perf CC||michael.st...@allotropia.de --- Comment #2 from Heiko Tietze --- What use case would you cover with cancel? You changed your mind, long-processing makes text irrelevant, you drink too much coffee since the operation takes literally minutes (the whole page from the referenced bug is pasted in ~10s here)? Rather than aborting the operation we should speed-up the paste procedure. And the same cancel mechanism would be required for open or save (IIRC we discussed this before but cannot find a ticket). My take: DUP 148408 Michael, what do you think? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown
https://bugs.documentfoundation.org/show_bug.cgi?id=140900 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Blocks||90796 Ever confirmed|0 |1 --- Comment #9 from Heiko Tietze --- (In reply to chameleonscales from comment #5) > it would be interesting to know what your screen's size and resolution are... Sure, high resolutions are always a source of trouble. Still waiting for a screenshot to judge... xdpyinfo | grep -B 2 resolution screen #0: dimensions:3440x1440 pixels (802x333 millimeters) resolution:109x110 dots per inch Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=90796 [Bug 90796] [META] HiDPI / Retina bugs -- You are receiving this mail because: You are on the CC list for the bug.
