[Libreoffice-ux-advise] [Bug 63967] Ability to Quickly Get Word Count of Sections Using Navigator
https://bugs.documentfoundation.org/show_bug.cgi?id=63967 --- Comment #5 from Jim Raykowski --- Here is a patch that displays word and character count in a tool tip for Sections in Writer Navigator. https://gerrit.libreoffice.org/c/core/+/91268 -- 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 92406] STATUSBAR: Making the statusbar configurable in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=92406 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #15 from Regina Henschel --- In case you will not wait, till something is implemented, you can already tweak the status bar by editing its xml-file: Copy the file statusbar.xml from \share\config\soffice.cfg\modules\swriter\statusbar to \config\soffice.cfg\modules\swriter\statusbar. (I suggest to copy it, because then you can simple delete the copied file, in case it does not work for you.) Open the file in an editor and change values and/or order. Some information about the status bar can be found in https://wiki.openoffice.org/wiki/Framework/Tutorial/Statusbar_Controller. Although for an old version of OpenOffice.org, most parts are still valid for LibreOffice. -- 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 92406] STATUSBAR: Making the statusbar configurable in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=92406 --- Comment #14 from Stephen Meatheringham --- I would find a configurable status bar incredibly useful. I often have two windows open on a quite high resolution monitor. I do not want them overlapping. When I make the Writer window narrower I lose the language field. That is one I use very often as I write documents in multiple languages. -- 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 129749] Index: Allow use of "n" to specify entries in footnotes and endnotes
https://bugs.documentfoundation.org/show_bug.cgi?id=129749 Dieter changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Blocks||89606 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=89606 [Bug 89606] [META] Table of Contents and Indexes bugs and enhancements -- 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 130778] Branding for 7.0
https://bugs.documentfoundation.org/show_bug.cgi?id=130778 --- Comment #9 from Heiko Tietze --- jackandmixers: Please share the raw content so we can implement your artwork perhaps at the Windows installer. Extracted from the PDF it would be bad quality. -- 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 131556] STYLES SIDEBAR: Checkbutton for styles filter
https://bugs.documentfoundation.org/show_bug.cgi?id=131556 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #2 from Heiko Tietze --- And if you talk about templates, we have the template manager that serves the selection purpose very well. -- 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 131529] Cannot modify preinstalled galleries
https://bugs.documentfoundation.org/show_bug.cgi?id=131529 Heiko Tietze changed: What|Removed |Added Keywords||needsDevEval --- Comment #6 from Heiko Tietze --- All galleries as extension leads to no gallery when build is done without it. And that might feel as broken app. If we store the shipped extensions at the user space it has the same effect but circumvents the extension management. Let's see if we get more opinions on that. -- 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 131315] Index: Implement letter by letter alphabetising
https://bugs.documentfoundation.org/show_bug.cgi?id=131315 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|UNCONFIRMED |NEW Keywords|needsUXEval | Ever confirmed|0 |1 --- Comment #3 from Heiko Tietze --- UX-wise the sorting would go into the "key type" dropdown as an alternative to alphanumeric. So introducing another algorithm wouldnt be a problem at all and is welcome. -- 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 125268] Wrong text highlight color when export document to doc/docx
https://bugs.documentfoundation.org/show_bug.cgi?id=125268 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #41 from Heiko Tietze --- We discussed the topic in the design meeting. While introducing a color palette is the easiest solution it cripples our features for no good reason. MSO might change the behavior at any time. The better approach is to warn in detail what attribute in the current document might not work when saved as docx (or other formats). That means to analyze the document, compare against a list of incompatibilities, and show it to the user. The newly introduced mso-highlight.soc palette is questionable. -- 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 125268] Wrong text highlight color when export document to doc/docx
https://bugs.documentfoundation.org/show_bug.cgi?id=125268 --- Comment #40 from Mike Kaganski --- (In reply to Michael Meeks from comment #38) > As an example: if you load a DOCX file - then we can safely assume you will > save as DOCX (this covers some vast proportion of the use cases) - and so we > can hide the UI options associated with doing more powerful ODF supported > things =) On ODF export to DOCX people expect some format shifting problems, > so we select the nearest feature, and the nearest matching hue for this case. Let me provide an example of a (different) problem that this would bring. In Writer, there's a concept of page styles, which is totally absent in Word. Trying to "hide" this functionality from users opening DOCX would simply disable any means of manipulating pages in Writer (there's nothing except of page styles for that in Writer, and that is its strength). So that would result in need of spending so little developer effort implementing an alternative machinery - UI, but also internal stuff. Of course, that won't bring any maintenance costs with it, and no problems with interoperability of stuff created by the same Writer when in different modes. -- 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 131418] Musical notes as a gallery
https://bugs.documentfoundation.org/show_bug.cgi?id=131418 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #5 from Heiko Tietze --- We discussed the idea in the design meeting and decided to not do it. There are better suited tools and the use case is out of scope. -- 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 131369] Unify terms in dialog to search text
https://bugs.documentfoundation.org/show_bug.cgi?id=131369 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |difficultyBeginner, ||easyHack, skillDesign, ||topicDesign Ever confirmed|0 |1 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|UNCONFIRMED |NEW --- Comment #3 from Heiko Tietze --- We discussed the topic in the design meeting. a) Use "Match case" instead of "Case Sensitive" b) Use title style capitalization in AutoRedaction dialog c) Use "Regular expression" in singular Terminology is easyhacking, happy to supply code pointers. -- 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 130995] Introduce UNO command and dialog to quickly set grid properties
https://bugs.documentfoundation.org/show_bug.cgi?id=130995 Heiko Tietze changed: What|Removed |Added Summary|Possibility to have several |Introduce UNO command and |grids activable and |dialog to quickly set grid |deactivable easily (as in |properties |Inkscape for instance) | Blocks||86899 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Ever confirmed|0 |1 Keywords|needsUXEval | Status|UNCONFIRMED |NEW Component|Impress |UI --- Comment #2 from Heiko Tietze --- We discussed the topic in the design meeting. While different grids are not easy to customize the use case is clear and affects probably many people. So the suggestion is to make it easier to change the values by introducing a UNO command that opens a dedicated grid property dialog replicating what's available at the sidebar. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=86899 [Bug 86899] [META] Requests for the addition of UNO commands -- 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 92657] Questionable Default for Bullet Sizing
https://bugs.documentfoundation.org/show_bug.cgi?id=92657 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #35 from Heiko Tietze --- Summarizing from the UX perspective: a) => wfm (cannot confirm the issue) b) => nab (if there is a difference in descenders it's up to the font designer; OTOH it's unclear which to keep), c) => wf (smaller bullet size is not a solution) The only solution is to use the actual paragraph font for the bullets; and to accept if the font has no bullet defined. The problem here might be that the bullet character is not easy to find. An alternative is maybe to cut the bullet at the baseline of the paragraph. -- 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 125268] Wrong text highlight color when export document to doc/docx
https://bugs.documentfoundation.org/show_bug.cgi?id=125268
--- Comment #39 from Mike Kaganski ---
(In reply to Michael Meeks from comment #38)
> This is an old-chestnut. There is a very significant cost in code
> complexity, maintenance and CPU time of walking the entire LibreOffice
> document model before starting to serialize it. Worse - whatever output we
> produce is never going to be completely accurate anyway.
I don't think it's that complex. Just moving the warning dialog from beginning
of the export into "in the middle", when an export model was created, but not
yet written t the file, would allow each export function to output its warnings
to a provided logger. No need to create a dedicated step.
> Worse - this will inevitably produce a long, and impenetrable series of
> highly technical 'stuff' as text (if we had even more infinite resource we
> could link each item to the document somehow) - that is going to be
> frightening and/or not interesting to all of our end-users who just want to
> understand:
> "why does it not work?",
> "Why did you let me get into this situation I don't understand !?" - etc.
Believing that you may always come with an "elegant" solution to problems
caused externally is daydreaming IMO. The list might be collapsed by default,
but not providing it because many wouldn't understand it is demeaning users. In
fact, currently many users just disable the warning that has no value at all,
because it seems to be wrong ("I saved my simple document to DOCX many times,
and never got any problems - it must be a joke!") only to later stumble upon a
problem with a thing that they never used before, and come here or to AskLibO
with "you ruined my many hours of work without warning!". If instead we only
output the dialog when there's actual dataloss, like here, or at least make it
"we didn't identified specific issues, but still there might be some problems"
when nothing specific was identified, it would provide value to people.
> I'm not in the UX team; but I would be staggered if this was thought to be a
> good idea. Almost certainly it is far easier to solve the problem in a more
> elegant way.
>
> As an example: if you load a DOCX file - then we can safely assume you will
> save as DOCX (this covers some vast proportion of the use cases) - and so we
> can hide the UI options associated with doing more powerful ODF supported
> things =) On ODF export to DOCX people expect some format shifting problems,
> so we select the nearest feature, and the nearest matching hue for this case.
Which would effectively mean "let's implement MS Word for those who load DOCX;
Pages for those who load .pages, etc.". That would become a nightmare of
multiple inconsistent UIs, each trying to satisfy some subset of users, and at
the same time dissatisfy e.g. users who receive a DOCX and are editing it to
save as ODT.
--
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 125268] Wrong text highlight color when export document to doc/docx
https://bugs.documentfoundation.org/show_bug.cgi?id=125268 --- Comment #38 from Michael Meeks --- > Better we would fix a different issue, which is unclear set of what is broken > on export. The warning user gets when saving to an external format doesn't > list specifics what will break; This is an old-chestnut. There is a very significant cost in code complexity, maintenance and CPU time of walking the entire LibreOffice document model before starting to serialize it. Worse - whatever output we produce is never going to be completely accurate anyway. Worse - this will inevitably produce a long, and impenetrable series of highly technical 'stuff' as text (if we had even more infinite resource we could link each item to the document somehow) - that is going to be frightening and/or not interesting to all of our end-users who just want to understand: "why does it not work?", "Why did you let me get into this situation I don't understand !?" - etc. Any good UX should not be spending lots of time, developer work, debugging etc. to do an imperfect job of providing extremely dense and unhelpful information. No matter how satisfying that is to developers who can say "I told you so in a footnote on page 135 of that dialog you clicked through" ;-) Microsoft of course were leaned on by their customers to try to do this for their ODF export filter. They produced 900+ pages of documentation - you can read it here: https://docs.microsoft.com/en-us/openspecs/office_standards/ms-oodf/68b99f79-842f-4db2-9249-0f71b611712b in a 10Mb PDF download. I'm not in the UX team; but I would be staggered if this was thought to be a good idea. Almost certainly it is far easier to solve the problem in a more elegant way. As an example: if you load a DOCX file - then we can safely assume you will save as DOCX (this covers some vast proportion of the use cases) - and so we can hide the UI options associated with doing more powerful ODF supported things =) On ODF export to DOCX people expect some format shifting problems, so we select the nearest feature, and the nearest matching hue for this case. At least, that's my 2 cents. -- 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 129160] Too narrow margin around icons on high DPI screen
https://bugs.documentfoundation.org/show_bug.cgi?id=129160 --- Comment #13 from Tomaz Vajngerl --- Well in windows we use to manually change the UI elements depending on the scale factor. This approach means we would need to take everywhere the scaling factor into account (for all the margins and whatever). Compared to HiDPI scaling in GTK3, where this is all done in the lower levels so there it looks mostly the same as without HiDPI scaling. We decided some time ago that we would do the same for other backends or generally for VCL, but nobody worked on it yet. -- 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 125268] Wrong text highlight color when export document to doc/docx
https://bugs.documentfoundation.org/show_bug.cgi?id=125268 --- Comment #37 from Mike Kaganski --- I don't think we should fix this by itself. Better we would fix a different issue, which is unclear set of what is broken on export. The warning user gets when saving to an external format doesn't list specifics what will break; and e.g. in this case, it could have an item for "A character background cannot be represented using MSO's highlighting and will be approximated to [this color]. Alternatively, you may select character backgrounds to be exported as shading, which is less-known MSO feature and may cause UX issues..." with possible links to descriptions, etc. That is a big task, but you just cannot hope to solve problems like this one, where there's a feature set mismatch (and even inherent other program's UX problem!), to fit all. -- 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
