[Libreoffice-ux-advise] [Bug 138786] PS formatting gets lost, if you paste text into an new document with same name of PS, but different settings (see comment 5)
https://bugs.documentfoundation.org/show_bug.cgi?id=138786 --- Comment #9 from Dieter --- I agree with your reasoning, Mike. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 138786] PS formatting gets lost, if you paste text into an new document with same name of PS, but different settings (see comment 5)
https://bugs.documentfoundation.org/show_bug.cgi?id=138786
--- Comment #8 from Mike Kaganski ---
(In reply to Heiko Tietze from comment #6)
> We can
> a) silently apply the target style (current situation)
> b) silently copy/rename of source style ("Caption_1", for example)
> c) show a dialog to resolve the conflict
(In reply to Dieter from comment #7)
> So in the case you paste text from another document I would at least expect
> a message like: "You paste content from another document. Copied style
> formatting will be overwritten by styles with the same name." OK | Cancel |
> Don't show message again (Of course you can use a better English)
There are three actual cases usability-wise:
1. The user pastes as plain text - i.e., the current Ctrl+Alt+Shift+V behavior;
2. The user would want the pasted rich text to follow the styling of target
document (i.e., the same-name styles get the meaning they have in the target
document; absent styles are added; direct formatting is applied as in the
source) - i.e., the current Ctrl+V behavior;
3. The user wants the pasted text to look as it looked in the source. This is
what this issue is about.
The #3 indeed must *not* be implemented by modifying the existing styles
(because that would re-format existing text); and I would tell that renaming
styles would also be poor, because it would proliferate automatically generated
styles - consider a document, into which you copy some text from other source
many times - will it generate new style_1, style_2, ... style_N each time?
The reasonable implementation of "keep source formatting" paste option would be
to use the target styles, *but* additionally apply direct formatting atop, to
override any formatting in the target document which does not match what was in
the source. The "I want the text to look the same as in the source" case is a
clear sign of unstructured approach (at least locally), and DF is IMO
absolutely fine.
And IMO, some improvement of the paste process would be nice. A dialog is a
no-go; but we already have a drop-down paste toolbar button; and we could try
to implement more convenience tools - see e.g. how MS Word does that, by
displaying a floating toolbar on paste, with buttons allowing to change the
formatting of the pasted text *retroactively*. I don't suggest to copy that
approach, but I suppose that some improvement is possible without intrusive
(blocking) UI (which is a dialog).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152851] MathML import should work even when no xmlns attribute is present
https://bugs.documentfoundation.org/show_bug.cgi?id=152851 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=98 ||827 Blocks||118765 Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=118765 [Bug 118765] [META] MathML bugs -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152851] MathML import should work even when no xmlns attribute is present
https://bugs.documentfoundation.org/show_bug.cgi?id=152851 --- Comment #4 from Regina Henschel --- I think, it is a valid enhancement request. It might be duplicate to bug 98827, at least strong related. From a user point of view such feature is important as it would allow to import fragments. I would restrict the request to texts, which have root element and start with . The result might not be as expected because LibreOffice's MathML support is at version 2.0. But getting something the user then can edit is better than getting nothing. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152851] MathML import should work even when no xmlns attribute is present
https://bugs.documentfoundation.org/show_bug.cgi?id=152851 --- Comment #3 from V Stuart Foote --- (In reply to Heiko Tietze from comment #2) > The RELAX NG schema, and I believe we are talking about this, has been > introduced a while ago and we should support it. What do you think, Regina? Looks to me that RELAX NG still requires a DTD of the xmlns: tag for the content. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 135474] Insert image location points to AppData\Roaming\LibreOfficeDev\4\user\gallery with a fresh profile
https://bugs.documentfoundation.org/show_bug.cgi?id=135474 --- Comment #5 from Stéphane Guillou (stragu) --- *** This bug has been marked as a duplicate of bug 129564 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 138786] PS formatting gets lost, if you paste text into an new document with same name of PS, but different settings (see comment 5)
https://bugs.documentfoundation.org/show_bug.cgi?id=138786 --- Comment #7 from Dieter --- (In reply to Heiko Tietze from comment #6) > In the case of Writer, the goal of styles is to create a consistent > document. Therefore b) makes no sense to me. Showing a dialog would be a > major nuisance for most users, so maybe some kind of paste special option > where all attributes are taken from the source. In fact pasting as RTF does > not work, likely since we do not copy every single attribute. > > My take: NAB, aka a). Heiko, I understand your arguments, but I don't agree with the conclusion. Original bug report shows, that it isn't always easy to figure out, why a pasted text doesn't look as expected. So in the case you paste text from another document I would at least expect a message like: "You paste content from another document. Copied style formatting will be overwritten by styles with the same name." OK | Cancel | Don't show message again (Of course you can use a better English) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 138786] PS formatting gets lost, if you paste text into an new document with same name of PS, but different settings (see comment 5)
https://bugs.documentfoundation.org/show_bug.cgi?id=138786
Heiko Tietze changed:
What|Removed |Added
CC||mikekagan...@hotmail.com
--- Comment #6 from Heiko Tietze ---
Similar topic in bug 112697 for Impress.
We can
a) silently apply the target style (current situation)
b) silently copy/rename of source style ("Caption_1", for example)
c) show a dialog to resolve the conflict
In the case of Writer, the goal of styles is to create a consistent document.
Therefore b) makes no sense to me. Showing a dialog would be a major nuisance
for most users, so maybe some kind of paste special option where all attributes
are taken from the source. In fact pasting as RTF does not work, likely since
we do not copy every single attribute.
My take: NAB, aka a).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147776] Add option to export slides from Impress as SVG without JavaScript
https://bugs.documentfoundation.org/show_bug.cgi?id=147776 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=11 ||7708 Status|UNCONFIRMED |NEW Keywords|needsUXEval |needsDevAdvice CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Blocks||111450 Ever confirmed|0 |1 --- Comment #5 from Heiko Tietze --- (In reply to skierpage from comment #0) > The SVG should Just Work. There's no animation, there is only a single > slide, so there's no reason to require JavaScript. The behavior is > counterintuitive. All the visual elements you see in Impress are in the SVG, > they're just hidden and nested. My first thought was to make it optional, which seems to be a fact according comment 4. But actually I don't see such an option in ooO.Common.Filter.Graphic.Export.SVG. => needsDevAdvice See also the potential duplicate bug 105641 "export of single objects should produce SVG without javascript" with a preliminary patch. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=111450 [Bug 111450] [META] SVG fileSave filter (Draw/Impress) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151541] Provide "Edit filter settings" checkbox in File Open dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=151541 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #2 from Heiko Tietze --- Not a fan of adding options to system dialogs in general but since we manage saving by this it's reasonable for open as well. The alternative to checkboxes is to have different dialogs, one with options the other "direct" as known from printing. Or to provide options in an extra dialog, document properties come in mind, which wouldn't solve the loading at all. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148164] Calc - Not so obvious to apply multiple borderstyles to a group of cells
https://bugs.documentfoundation.org/show_bug.cgi?id=148164 Heiko Tietze changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Heiko Tietze --- The widget has a triple state / overloaded functionality: you select one or more borders to manipulate the attributes at once. And you can quickly change it on/off. I voted for simplification in bug 143249. *** This bug has been marked as a duplicate of bug 143249 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151541] Provide "Edit filter settings" checkbox in File Open dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=151541 Stéphane Guillou (stragu) changed: What|Removed |Added Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151541] Provide "Edit filter settings" checkbox in File Open dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=151541 Stéphane Guillou (stragu) changed: What|Removed |Added Keywords||needsUXEval Status|UNCONFIRMED |NEW Blocks||102732 Version|unspecified |Inherited From OOo CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org Ever confirmed|0 |1 Whiteboard| QA:needsComment| --- Comment #1 from Stéphane Guillou (stragu) --- Sounds sensible to me, but copying in UX. Discrepancy inherited from OOo: OpenOffice.org 3.3.0 OOO330m20 (Build:9567) Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=102732 [Bug 102732] [META] OS file dialog bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 126074] Icon styles should not modify official application icons in start center (and other relevant places)
https://bugs.documentfoundation.org/show_bug.cgi?id=126074 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2842 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152842] Colibre application icons in start center isn't match application icon in taskbar & or title bar
https://bugs.documentfoundation.org/show_bug.cgi?id=152842 Heiko Tietze changed: What|Removed |Added Resolution|--- |NOTABUG See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||6074 Status|UNCONFIRMED |RESOLVED Blocks||103184 Depends on||132398 Keywords||needsUXEval CC|heiko.tietze@documentfounda |libreoffice-ux-advise@lists |tion.org|.freedesktop.org --- Comment #2 from Heiko Tietze --- It was decided in bug 126074 to not have a unique branding but theme-able icons. It has been like this before the latest icon update for bug 132398 if you switch from Colibre to any other icon theme. Now the main icon does not follow Colibre anymore on Windows and you see the difference. Tagging UX for information but resolving as NAB. 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=132398 [Bug 132398] Adopt new main application icons -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 142801] Support partial transparency in table cell backgrounds
https://bugs.documentfoundation.org/show_bug.cgi?id=142801 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval |needsDevAdvice Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Heiko Tietze --- You can achieve transparency with an extra shape layer between the background image and the foreground table. The table needs to have no filling in this case. However, this approach fails if the table should have a highlighted row, for example. The question is whether tables (or rather any object) can have a transparency attribute likewise shapes. If so I'd agree with the requirement. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147783] Cannot undo typing in Hyperlink dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=147783 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 CC|libreoffice-ux-advise@lists | |.freedesktop.org| Status|UNCONFIRMED |NEW --- Comment #10 from Heiko Tietze --- In addition to my comment 5 (not worth much effort, though nice to have), it's clear that adding undo/redo in dialogs must not spoil the application's undo stack (ie. undoing the last action after the hyperlink dialog is closed should not consider every single key stroke). Added needsDevAdvice to understand if a) undo/redo in RichTextBox would be a separate function and b) the effort is acceptable low (easyhackable). No need for further input from UX. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152860] Find toolbar's "placeholder for message" (.uno:SearchLabel tooltip / label) makes it sound like something is missing
https://bugs.documentfoundation.org/show_bug.cgi?id=152860 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=81 ||925 CC||tima...@gmail.com --- Comment #1 from Heiko Tietze --- Yes, the tooltip on empty search results is awkward. Yet we need the label for the customization dialog. Maybe adding an empty tooltip to the command attributes solves the problem. Challenge for l10n though. Andras, what do you think? Alternatively I could imagine something more descriptive like "Search results" or "Search information". Code pointer: in officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu -- You are receiving this mail because: You are on the CC list for the bug.
