[Libreoffice-ux-advise] [Bug 157006] UX review needed for Options - Writer - Compatibility dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=157006 --- Comment #6 from Heiko Tietze --- (In reply to sdc.blanco from comment #4) > (In reply to Heiko Tietze from comment #2) > > "Microsoft compatible Form menu" maybe. But I'd rather omit this option as a > > corner case and to clean up the dialog. > Does "clean up..." mean a different design/layout for the entire dialog? I mean to remove the GtkFrame "Global Compatibility Options" with the single checkbox (and have this one available only as advanced option). Leaving the other aspects for the design meeting. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157081] Tabs in Ruler not showing correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=157081
--- Comment #4 from Heiko Tietze ---
Created attachment 189357
--> https://bugs.documentfoundation.org/attachment.cgi?id=189357&action=edit
Ruler with center tab and default tab
(In reply to Stéphane Guillou (stragu) from comment #3)
> The default marker (when no discrete tab stops have been defined) is the
> smaller inverted T ("up tack").
The screenshot illustrates the situation.
> I don't think it's possible to change the default tab type...
Different question but possible per default template.
> If the default, small up tack marker is changed to reflect the default left
> Type, we'd have to make sure it also works for when using complex text
> layout like RTL (automatically changed to right Type).
The 'up tack' marker should probably not get mixed up with the 'tab' marker.
The latter tab stop as inserted via paragraph attribute defines where the tab
ends (and how the text flows at this stop) while the first shows the position
where every single tab character ends up.
We could change the up tack into a vertical ruler, for example. But I like the
current design (and if we follow MSO and introduce a bar tab stop this would be
wrong anyway). And RTL/LTR definitely needs to be considered.
MSO does not show any symbol for the default tab stop.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157052] When showing a changes bar for style changes, list them in a popup when hovering over it
https://bugs.documentfoundation.org/show_bug.cgi?id=157052 Eyal Rozenberg changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157052] When showing a changes bar for style changes, list them in a popup when hovering over it
https://bugs.documentfoundation.org/show_bug.cgi?id=157052 --- Comment #2 from Eyal Rozenberg --- Created attachment 189352 --> https://bugs.documentfoundation.org/attachment.cgi?id=189352&action=edit screenshot of change bar Well, here it is, but - as I was making this screenshot, I realized that we don't actually get change bars unless at least some characters get visually marked as changes. So my suggestion is invalid. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157006] UX review needed for Options - Writer - Compatibility dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=157006 --- Comment #5 from sdc.bla...@youmail.dk --- (In reply to sdc.blanco from comment #0) > * better sequencing of options? Is is possible to put the more common/more important options first (and least important/common last)? For less common, guessing that "Use OpenOffice.org..." items could/should be grouped toward bottom, with the specialized cases (form, database, PDF) just before the "Use OpenOffice.." For importance, the "paragraph and table spacing" items at the top, followed by spacing options. Does anyone have enough knowledge to make an informed proposal? Otherwise, I could propose a patch centered around these ideas. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157006] UX review needed for Options - Writer - Compatibility dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=157006 --- Comment #4 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #2) > "Microsoft compatible Form menu" maybe. But I'd rather omit this option as a > corner case and to clean up the dialog. Does "clean up..." mean a different design/layout for the entire dialog? But doesn't the label deserve to be changed in either case (i.e., cleaned-up or not)? > I'd keep the burden low for l10n. Agreed. Also agree that studying help is usually needed (i.e., no expectation that each option is transparent, only sufficiently meaningful to remind about the function (if you already know the meaning) or to indicate enough about the likely function, to decide whether worth looking further at the help). Most options seems to have an action verb. Propose the following changes: A. "Consider wrapping styles when positioning objects" Two issues here. First, according to help [1], it seems like it would usually be preferred to have this option ON, but afaict, the default is that this option is OFF. Is the help wrong? or maybe the default should be changed? If I understand the idea here, then it seems better to change the label to "Use OpenOffice 1.1 wrapping style to position objects" (and to change the backend so that when it is ON, then the "old" behavior is used). (would make it more consistent with the other "Use OpenOffice.org 1.1..." B. Protect form Help is missing. (I do not know what what this function does, but given that it is not documented, then seems better to make a reasonable label, and then add appropriate help.) The "No longer protects whole document" seems irrelevant (or is trying to move the help/tooltip function into the UI). C. Word-compatible - (bug Bug 104668) Also missing help. I could not understand the discussion in bug 104668) Is this another case of "Use OpenOffice.org 1.1..."? (if enabled)? (maybe do not need to mention Word-compatible at all) D. "Render non-breaking spaces (NBSP) as standard-space-width (off for fixed size)" Also missing help. This is bug 41652. If I understand correctly then isn't it: Do not render non-breaking spaces as fixed-width space The "off for fixed size" seems like it should be in the help, not the UI. E. "Expand word space on lines with manual line breaks in justified paragraphs" > "Justify lines with manual line breaks (in justified paragraphs)" (could skip this change if too many changes already, but I believe the meaning of the proposal is easier to guess, while the current version is tough to follow) [1] https://help.libreoffice.org/24.2/en-US/text/shared/optionen/01041000.html?DbPAR=WRITER -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157006] UX review needed for Options - Writer - Compatibility dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=157006 --- Comment #3 from sdc.bla...@youmail.dk --- Created attachment 189341 --> https://bugs.documentfoundation.org/attachment.cgi?id=189341&action=edit screenshot of Windows dialog for Compatibility options (In reply to Heiko Tietze from comment #2) > (In reply to sdc.blanco from comment #0) > > * is the scroll box really needed? (i.e., general design/layout of dialog > > can probably be simplified) > > Nothing bad with it on macOS. Attachment has screenshot for Windows. Two differences with macOS 1. Some options (toward bottom) do not fit fully in horizontal direction in Windows. 2. Top 3 options are missing in Windows, but not macOS. OP was imagining something like macOS. A Windows problem? Linux? Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 218a7650a5cf03f895bed19c68d6f02daec536e9 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157081] Tabs in Ruler not showing correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=157081
Stéphane Guillou (stragu) changed:
What|Removed |Added
CC||libreoffice-ux-advise@lists
||.freedesktop.org,
||stephane.guillou@libreoffic
||e.org
Version|24.2.0.0 alpha0+ Master |Inherited From OOo
Keywords||needsUXEval
Priority|medium |low
Severity|normal |minor
--- Comment #3 from Stéphane Guillou (stragu)
---
The default marker (when no discrete tab stops have been defined) is the
smaller inverted T ("up tack"). Once you define discrete tab stops at various
positions with various Types, you will see bigger markers used instead, which
allows us to tell them apart.
This was the same in OOo 3.3.
I don't think it's possible to change the default tab type for the whole
document / the whole of Writer, there is no option in Tools > Options >
LibreOffice Writer > General.
If the default, small up tack marker is changed to reflect the default left
Type, we'd have to make sure it also works for when using complex text layout
like RTL (automatically changed to right Type).
UX/Design team, what do you think?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156549] New CAD features for cable design
https://bugs.documentfoundation.org/show_bug.cgi?id=156549 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #3 from Regina Henschel --- There exist the methods getLength() and getEdgeLength() for our internal B2DPolygon class. I think, Enrico wants such tool in the UI. The list of points is available in the API for all polyline, polygon and curve objects. The total edge length can be determined using macros. If you only want to get the length in an info box, that is simple. More difficult and complex would be to produce an object in the drawing, that adapt itself to changes in the drawing. I don't know whether that is possible with macros. https://opengrok.libreoffice.org/xref/core/basegfx/source/polygon/b2dpolygontools.cxx https://opengrok.libreoffice.org/xref/core/include/basegfx/polygon/b2dpolygontools.hxx -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156549] New CAD features for cable design
https://bugs.documentfoundation.org/show_bug.cgi?id=156549 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #2 from Heiko Tietze --- In addition to comment 1: "Position & Size" in the Properties sidebar shows the dimension of the surrounding box if you select multiple objects or for the group. What exactly is missing? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157006] UX review needed for Options - Writer - Compatibility dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=157006 --- Comment #2 from Heiko Tietze --- Created attachment 189339 --> https://bugs.documentfoundation.org/attachment.cgi?id=189339&action=edit Dialog (In reply to sdc.blanco from comment #0) > * better sequencing of options? > >e.g., all "paragraph and table" spacing options together? > all the 1.1 options together? Sounds good to me (and has no consequences for the l10n team) > * maybe separate heading is unnecessary for "Form menu" if there is only > going to be one change like this. (see also bug 126375, comment 2) This one is a global option while all other are saved per document. There are a few more yet not exposed at the UI, see https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Compatibility.xcs?r=28675af8#168 >"Reorganize" is not a good word for the label. > Better label might be "Form dropdown menu like Microsoft". "Microsoft compatible Form menu" maybe. But I'd rather omit this option as a corner case and to clean up the dialog. > * general review of option labels for possible improvements/corrections > (e.g., bug 141676) As a rule of thumb we could start the entries with an action. Like "Add.." , "Use..." etc. "Word-compatible trailing blanks" could become "Use...". I don't like "Protect form (..." but ultimately all these options requires to study the help. And I'd keep the burden low for l10n. > * is the scroll box really needed? (i.e., general design/layout of dialog > can probably be simplified) Nothing bad with it on macOS. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 134980] Compare documents should recognize change of an image
https://bugs.documentfoundation.org/show_bug.cgi?id=134980 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #11 from Heiko Tietze --- (In reply to Michael Stahl (allotropia) from comment #8) >> Is Tracking Changes in theory - able to detect replaced images? > probably not. => WF Assuming it is possible with some effort I still think an office suite is not an image processing tool. What should be working though is to detect if the source/link URL has changed. So if the request is not to compare two raster graphics please reopen with more details. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157052] When showing a changes bar for style changes, list them in a popup when hovering over it
https://bugs.documentfoundation.org/show_bug.cgi?id=157052 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #1 from Heiko Tietze --- Please add a screenshot for the "change bar". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156804] Text inserted from autotext doesn't show the set number of paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=156804 --- Comment #8 from Davide --- Created attachment 189338 --> https://bugs.documentfoundation.org/attachment.cgi?id=189338&action=edit Edit style window to assign a 123 numbering style -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156804] Text inserted from autotext doesn't show the set number of paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=156804 --- Comment #7 from Davide --- Thank you Heiko. If I assign a title style to a level of structure, I can't modify that style assigning a numbering style. This option appears in grey in edit style window. See screenshot enclosed. 123 are assigned in Tools>Heading_Numbering to the styles you can see in the sample document. Please let me know if I correctly understand your comment. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156804] Text inserted from autotext doesn't show the set number of paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=156804 --- Comment #6 from Heiko Tietze --- OTOH, if the list style is applied as a style (edit style > outline & list > list style, eg. set to "Numbering 123") it will be accepted as expected. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156804] Text inserted from autotext doesn't show the set number of paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=156804 Heiko Tietze changed: What|Removed |Added CC||mikekagan...@hotmail.com --- Comment #5 from Heiko Tietze --- I can follow the expectation that attaching a list style / heading numbering scheme to the paragraph should be taken into autotext and copy/paste actions. Mike, any blocker? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149478] Separate Default Page Size from Language Locale
https://bugs.documentfoundation.org/show_bug.cgi?id=149478 --- Comment #2 from Heiko Tietze --- Tend to agree with Damon but can follow Dieter's argument too. If the default page size should be made optional the best place seems to be next to T > O > Writer > Settings where the measurement units are located (and need to be adjusted likewise the page size). -- You are receiving this mail because: You are on the CC list for the bug.
