[Libreoffice-ux-advise] [Bug 157039] Method to clear search text drop down list in Base form
https://bugs.documentfoundation.org/show_bug.cgi?id=157039 Stéphane Guillou (stragu) changed: What|Removed |Added Whiteboard| QA:needsComment| Blocks||108440, 116885 Summary|Method to clear search text |Method to clear search text |drop down list in Base |drop down list in Base form |form. | Status|UNCONFIRMED |NEW Keywords||needsUXEval See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||2311 Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org --- Comment #1 from Stéphane Guillou (stragu) --- That's a good point. I can confirm that I can see previous searches from a different database in a form's Record Search dialog. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2902ab24ecc5ffbf4907ea83b2028508b9de6364 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: es-MX (en_AU.UTF-8); UI: en-US Calc: threaded As a comparison, the Find and Replace dialog in Calc and Writer only saves searches per session. Close and reopen LO, the list is cleared. Maybe instead of adding a way to clear the search, it should just do like Calc and Writer and not save anything between sessions? Although there is a request to go the opposite way and make Find and Replace _remember_ searched terms between sessions: Bug 122311 So a design decision should be consistent across these dialogs. In my opinion, if search terms as saved, there should absolutely be an option to clear the list. And possibly, a setting to opt into it. (Thinking of shared computers on which one user might not like discovering that another user is able to see logged search terms they have used previously.) Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108440 [Bug 108440] [META] Database form bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=116885 [Bug 116885] [META] Privacy and data security issues -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 118866] Notify when hyperlink to hidden sheet is not possible
https://bugs.documentfoundation.org/show_bug.cgi?id=118866 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Summary|EDITING Hyperlink to hidden |Notify when hyperlink to |sheet navigates to wrong|hidden sheet is not |sheet |possible --- Comment #9 from Heiko Tietze --- We discussed the topic in the design meeting. Feasible options to solve the reasonable issue are a) switch anyway (and show the hidden sheet, maybe only temporarily) alternatively unhide the hidden sheet permanently, since the temporary action might be surprising b) show some info bar, message box, balloon tip c) disable the link and change the appearance accordingly We have to consider protected sheets where switching is not an option, so a) is not applicable in all situations. The idea of c) to disable the link was rejected since it might be hard to understand for users. So what remains is b). We suggest to go with a balloon tip since an infobar would move the sheet content downward and be rather a global information anyway than related to the actual cell/action. And the message box is too interruptive. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157276] [UI] Presenter mode does not use system font
https://bugs.documentfoundation.org/show_bug.cgi?id=157276
Heiko Tietze changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
OS|Linux (All) |All
Ever confirmed|0 |1
CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda
|.freedesktop.org|tion.org
Keywords|needsUXEval |
--- Comment #4 from Heiko Tietze ---
We discussed the topic in the design meeting.
Looking into the code it seems the presenter console has a lot of room for
customization. It should be possible to set background image/color, font size,
name, color etc. via registry - and consequently allowing to set a theme per
extension.
The fallback is however to use Tahoma.
PresenterTheme::FontDescriptor::CreateFont() {
...
if (msFamilyName.isEmpty())
aFontRequest.FontDescription.FamilyName = "Tahoma";
And the majority of participants agree on the request to use the system font as
long nothing is defined per theme.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157104] Support partial visibility of tracked changes for formatting and/or content (addition/deletion)
https://bugs.documentfoundation.org/show_bug.cgi?id=157104 Heiko Tietze changed: What|Removed |Added Summary|Support partial visibility |Support partial visibility |of tracked changes (at |of tracked changes for |least like MS Word) |formatting and/or content ||(addition/deletion) Status|UNCONFIRMED |NEW Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||nem...@numbertext.org Ever confirmed|0 |1 --- Comment #5 from Heiko Tietze --- We discussed the topic in the design meeting. The use case is clear, a reviewer caring about content not formatting. And while tools > options > writer > changes allows to set every type to [None] the change is highlighted anyway. We should add controls in the sidebar and UNO commands for the main menu to hide track changes fine-grained, maybe replacing the current entire show/hide function. In addition, the margin information needs to be clearly separated (and improved) so this information could be shown too optionally. -- You are receiving this mail because: You are on the CC list for the bug.
