[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #9 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #4) > (In reply to Cor Nouws from comment #2) > > and the HUD is what for LibreOffice? > > Help > Search Command (Shift+Esc) You mean, a text box for search all possible commands? I think I'm against. Reporter - why not just add a HUD on your own? Why do you believe it needs to be there by default? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #8 from V Stuart Foote --- (In reply to V Stuart Foote from comment #7) > listbox or continue to use a dialog to hold for > I'll finish that thought ...to continue to use a dialog to hold and select the search result(s). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 V Stuart Foote changed: What|Removed |Added CC||vstuart.fo...@utsa.edu --- Comment #7 from V Stuart Foote --- We have no obligation to follow any particular Apple or Microsoft feature, or even this Unbutu like HUD implementation. This bug to provide --text entry into a new combobox on the Standard Toolbar-- is feature creep, where any solution would require either a listbox or continue to use a dialog to hold for The current and justifiable scope of the HUD is as a *command locator*, plain and *simple* see bug 91874 That said, rather than a hard WONTFIX for this, perhaps simply a Toolbar or NB button UNO action luanching the current HUD dialog, to supplement the + launch. Beyond that there is little justification for adding functions to the HUD. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #5 from John Mills --- It may not be possible to add functionality to the header bar currently however a new search icon could be added as an example to the @notebook bar tabbed' interface next to the name of the tabs: https://www.microsoft.com/en-us/videoplayer/embed/RE3sPA3?pid=ocpVideo1-innerdiv-oneplayer=true=20=en-us This could be achieved in a similar manner to Microsoft Outlook 'Tell me what you want to do' in the video above. Why would adding functionality like this necessitate 'removing a large part of interactions?' Prior to Microsoft Office 2019 the search functionality (HUD) was a feature of the standard toolbars and not included in the header bar. The HUD in LibreOffice is a brilliant feature and it should be as simple as possible to find and not 'hidden' behind an obscure shortcut key. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149010] "Previous Link" and "Next Link" should only appear on Frames Options tab
https://bugs.documentfoundation.org/show_bug.cgi?id=149010 sdc.bla...@youmail.dk changed: What|Removed |Added Summary|Can non-frame objects |"Previous Link" and "Next |and/or graphics be linked? |Link" should only appear on ||Frames Options tab CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #2 from sdc.bla...@youmail.dk --- (In reply to Regina Henschel from comment #1) > draw:chain-next-name attribute is ... only implemented for Frames in Writer. > would be possible for the shape "Text box" too, but ... not implemented. > not possible for images or OLE objects or media. ==> Help page must be revised -- to specify Frames only. ==> NeedsUXEval about whether to implement for "Text box" (no opinion from OP) > > Question 2: If only frames can be linked, then the "Previous Link" and > > "Next Link" should not appear at all when selected OLE Objects and Images ==> NeedsUXEval And given that these controls can only be used with Frames, but not with Images or OLE Objects, then they should only be shown in the Frames Option dialog, but not the Image or Object Option dialog ( code pointer: sw/source/ui/frmdlg/frmpage.cxx ) Changing bug summary... -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148740] UI Issue: In View->Styles, the `+` gets hidden when the cursor is on a parent style
https://bugs.documentfoundation.org/show_bug.cgi?id=148740 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needsUXEval | Blocks||107139, 142074, 103184 CC|libreoffice-ux-advise@lists |caol...@redhat.com, |.freedesktop.org|heiko.tietze@documentfounda ||tion.org Status|UNCONFIRMED |NEW --- Comment #9 from Heiko Tietze --- Confirming with SAL_USE_VCLPLUGIN=gen and Breeze icon theme on Linux. Possible solutions are a) to change the highlight color and b) use a different color on Breeze icons. Probably a) is the better option. Caolan, what do you think? Meanwhile you can use a different VCL and start the application with "SAL_USE_VCLPLUGIN=gtk3 /bin/soffice" (or kf5) or use a different icon theme. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103184 [Bug 103184] [META] UI theming bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=107139 [Bug 107139] [META] Breeze icons https://bugs.documentfoundation.org/show_bug.cgi?id=142074 [Bug 142074] [META] Application Colours settings bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148740] UI Issue: In View->Styles, the `+` gets hidden when the cursor is on a parent style
https://bugs.documentfoundation.org/show_bug.cgi?id=148740 --- Comment #8 from Heiko Tietze --- No issue right now on macOS and cannot remember seen it on Linux. I suspect the VCL=x11 to cause trouble or maybe the dark blue as highlight color. I guess the interaction works and the tree expands on click, does it? -- 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 #30 from Heiko Tietze --- (In reply to Cor Nouws from comment #27) >... the cursor is between the anchoring point and the paragraph marker? Comment 13 has some wisdom -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149000] PDF Accessibility: Checker dialog should have a "Print report" button
https://bugs.documentfoundation.org/show_bug.cgi?id=149000 --- Comment #4 from Heiko Tietze --- (In reply to Christophe Strobbe from comment #3) > The critical thing here is figuring out how to make such a report useful. A lot of very good ideas, in particular the help on each topic. As always, every single item needs a ticket. But what about a print-out? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #4 from Heiko Tietze --- (In reply to Cor Nouws from comment #2) > and the HUD is what for LibreOffice? Help > Search Command (Shift+Esc) (In reply to John Mills from comment #3) > @Heiko Regarding Mac and Windows users why do you think this would not be > wanted? If the HUD would not work like the search bar in MSO then that is a > different discussion. Making space by removing a large part of interactions from the Standard toolbar is unwanted. MSO has the search bar in the headerbar, which wont work (cross-platform) for us. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #3 from John Mills --- Hi all, If the HUD should function like the search bar in Microsoft Office then I absolutely think it should be there. It is such a useful feature for finding functionality, commands, help etc.as it is both used for finding words etc, (akin to Ctrl F) and these activities. You can see the emphasis placed on this due to it being so prominent in the application header. @Heiko Regarding Mac and Windows users why do you think this would not be wanted? If the HUD would not work like the search bar in MSO then that is a different discussion. In MSO the Search bar is located in the header bar, as this is not used in LibreOffice would there be an opportunity for this to be a potential placement for the future to make better use of available space? I will try and join the Design meeting tomorrow where this will be discussed. Kind regards, john -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148740] UI Issue: In View->Styles, the `+` gets hidden when the cursor is on a parent style
https://bugs.documentfoundation.org/show_bug.cgi?id=148740 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.
[Libreoffice-ux-advise] [Bug 143158] Alphabetical index field: allow "Edit Index Entry" to open on double-click
https://bugs.documentfoundation.org/show_bug.cgi?id=143158 Cor Nouws changed: What|Removed |Added CC||c...@nouenoff.nl --- Comment #3 from Cor Nouws --- (In reply to Heiko Tietze from comment #2) > Usually we don't respond to double click on fields. But that is not per se an argument against the change? > The context menu > (likewise the main menu Edit > Reference > Index Entry) offers "Index > Entry..." Which would lead to the conclusion that this is a WFM? What do you think, greenandpleasant2000-supp...@yahoo.co.uk? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149000] PDF Accessibility: Checker dialog should have a "Print report" button
https://bugs.documentfoundation.org/show_bug.cgi?id=149000 --- Comment #3 from Christophe Strobbe --- The critical thing here is figuring out how to make such a report useful. (The same applies to the current UI.) To users who are not accessibility experts, a text version of what the checker displays in its UI is of limited usefulness. (This comment applies to each of the issues in the screenshot uploaded by Heiko Tietze.) In order to be really helpful, we need: 1. Accurate and up-to-date information on how to fix accessibility issues in Libreoffice's online help. "How to Create Accessible LibreOffice files" at https://wiki.documentfoundation.org/Accessibility/Creating_Accessible_LibreOffice_Files is still based on LibreOffice 5.2 and needs to be checked for completeness, especially for people who want to create documents that meet the accessibility criteria in the European standard EN 301 549. 2. A mechanism to refer users from a specific issue to the appropriate section in the above documentation 2.a. both in the UI 2.b. and in the exported accessibility report. 3. A concept for organizing the accessibility issues in the report: should the issues be listed in the order they occur in the source document, by type of content (images, tables, headings, ...) or by a specific set of accessibility criteria from a standards such as EN 301 549? (Or all of them in specific sections of the report? Or provide a setting that allows the user what type of structure to use?) 4. Above all, the checker should not be limited to a function that is invoked by the PDF export function but one that is available at any moment, so authors can check the accessibility of a document while writing it. (AccessODF, an extension for OpenOffice.org and LibreOffice 3.3, worked in this way. The extension still exists - see http://accessodf.sourceforge.net/ - but became incompatible with OOo and LibO when the side panel was introduced.) I realise that some if the above issues need to be relegated to separate issues. P.S.: Rich text (Microsoft's RTF format) would be a bad choice from an accessibility point of view due to its limited accessibility features. An accessible ODT file would be a much better choice. (AccessODF did not export a report but saved checking results in EARL Schema: https://www.w3.org/TR/EARL10-Schema/ ) P.P.S.: The usefulness of a report is limited by the fact that automated accessibility checks can catch less than a third of all types of accessibility issues. Authors may erroneously think they have solved all accessibility issues when they have addressed those that have been reported by the tool. An exported report would not to point out that this is not the case. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 Cor Nouws changed: What|Removed |Added CC||c...@nouenoff.nl --- Comment #2 from Cor Nouws --- and the HUD is what for LibreOffice? -- 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 #29 from Cor Nouws --- the behavior is odd - I do recognize it - but I see no sensible, always logic, way to improve that..? -- 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 #28 from Cor Nouws --- (In reply to Cor Nouws from comment #27) > I didn't follow all comments - sorry - but has it been discussed that maybe > a possible change is that the cursor is between the anchoring point and the > paragraph marker? > Then pressing Enter would not move the anchor. Ah, but that is ~opposite to the behavior introduced in bug 120469 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148712] Show the count of hidden sheets in the Calc spreadsheets statusbar
https://bugs.documentfoundation.org/show_bug.cgi?id=148712 Cor Nouws changed: What|Removed |Added Version|7.2.5.2 release |Inherited From OOo CC||c...@nouenoff.nl --- Comment #2 from Cor Nouws --- (In reply to Regina Henschel from comment #1) > With menu Sheet > Show sheet or with item 'Show sheet' from context menu, > you get a list of all hidden sheets. I think, we should not use further > space in the status bar for this info. > > Sheets are usually hidden from ordinary users on purpose. It is > counterproductive to make them explicitly aware of hidden spreadsheets. I appreciate this view. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149000] PDF Accessibility: Checker dialog should have a "Print report" button
https://bugs.documentfoundation.org/show_bug.cgi?id=149000 Cor Nouws changed: What|Removed |Added CC||c...@nouenoff.nl --- Comment #2 from Cor Nouws --- (In reply to Heiko Tietze from comment #1) > Created attachment 180033 [details] > Example done with Dummy Text Formatted > > How about Copy rather than Print? And I wonder if users really want a copy > whether printed or not of the issues. Report may be rich text. And could help for review in a later stage (just thinking ..). > Re-running is cheap and you get the "Go to Issue" interaction. True. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149000] PDF Accessibility: Checker dialog should have a "Print report" button
https://bugs.documentfoundation.org/show_bug.cgi?id=149000 --- Comment #1 from Heiko Tietze --- Created attachment 180033 --> https://bugs.documentfoundation.org/attachment.cgi?id=180033=edit Example done with Dummy Text Formatted How about Copy rather than Print? And I wonder if users really want a copy whether printed or not of the issues. Re-running is cheap and you get the "Go to Issue" interaction. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149000] PDF Accessibility: Checker dialog should have a "Print report" button
https://bugs.documentfoundation.org/show_bug.cgi?id=149000 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 148979] Field context menu should have "Update Field" item
https://bugs.documentfoundation.org/show_bug.cgi?id=148979 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needsUXEval |difficultyInteresting, ||easyHack, skillCpp, topicUI Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mentoring@documentfoundatio ||n.org --- Comment #6 from Heiko Tietze --- So let's make it an interesting easyhack, guess the prototype would be ImpEditEngine::UpdateFields(). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148979] Field context menu should have "Update Field" item
https://bugs.documentfoundation.org/show_bug.cgi?id=148979 --- Comment #5 from Miklos Vajna --- Not updating all fields automatically has a few benefits: 1) updating all these fields can take a bit of time for large documents, so doing it on every keypress would be seen as a problem by some users (Writer could be too slow to be usable) 2) we could also have code to track the dependencies of all fields (similar to e.g. what Calc does), not having that code makes the codebase simpler 3) there is not much pressure on us to do such auto-updates in all cases, e.g. Word doesn't update fields even on file load So given that users learned to live with not auto-updating fields, this allows a bit simpler and faster code. That being said, we do auto-update a few fields, e.g. moving a page number field to a next page auto-updates it. On the other hand, users learned that hand-editing a generated ToC is possible, and if we take that away, they can see that as a regression. With these in mind, completely eliminating the explicit field update doesn't sound good. Adding a possibly to explicitly update an individual field makes sense to me. -- You are receiving this mail because: You are on the CC list for the bug.
