[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 --- Comment #13 from sdc.bla...@youmail.dk --- (In reply to sdc.blanco from comment #12) > no way to see if an OLE object is linked or not. At least for linked images, it is possible to see in Navigator. But presumably there has not been any confusion (bug reports) about the Image Properties dialog being the same for both embedded and linked images (i.e., no need to change Image title, e.g., to "Linked or Embedded Image"). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018
--- Comment #12 from sdc.bla...@youmail.dk ---
(In reply to Mike Kaganski from comment #8)
> the distinction between linking and embedding will be really crucial to the
> usage for some people; and when they will be confused, unsure if the term
> means that what they thing "linked" is termed "embedded", they would be
> really lost
Ok -- will assume that this hypothesis is valid for now
---but a few questions and comments to clarify the situation.
1. Afaict, only one small corner of Insert -> OLE Object involves an external
link, where all other uses of Insert > OLE Object result in what we are
presently calling an "embedded object". Right?
Even when an external file is chosen ("Create from file"), it is only "linked"
if "Link to file" is chosen.
The proposal in comment 11 to make a "Linked Object" dialog was motivated by my
misunderstanding that all OLE objects were a "Linked Object".
It seems inappropriate to make a special dialog for OLE Objects, when most of
the uses are embedding.
2. This (potential) confusion or uncertainty about linked/embedded is already
addressed in the documentation. See "Link to file"
https://help.libreoffice.org/7.4/en-US/text/shared/01/04150100.html
If there are other places where it would be appropriate to mention, then I can
add them.
3. Meanwhile, as a different issue, there is no way afaict (e.g, in Properties
dialog or Navigator) to see if an OLE object is linked or not. (and Edit >
External Links does not identify the object name). (not a complaint, just an
observation, and a thought that this might be a bigger problem for users than
the "embedded" label in the Properties dialog.)
4. The proposal in comment 11 might still be usable (if it seems an
improvement), but now with "OLE Object" included in the Embedded Objects
submenu, otherwise, comment 5 still seems valid.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 --- Comment #11 from sdc.bla...@youmail.dk --- (In reply to Mike Kaganski from comment #10) Thanks. Got it. if "Embedded" label with OLE Objects is expected to be problematic... then -- first speculation about possible response: Make a "Linked Object" label dialog (just as Frame and Image have their own), modify toolbar to show Ole Object or Embedded Object as title, and reconfigure Insert Menu as follows: Image Chart Embedded Object Formula Object QR and Barcode Scan > Audio or Video Gallery Shape OLE Object Main changes: (a) Rename "Object" to "Embedded Object" (b) move entries in "Media" to "Embedded Object" submenu, (c) Ole Object at top level. Additional Comments 1. Have (almost) followed existing menu ordering -- other orderings are fine with me. 2. Initial ordering/organization is a modifiable default, because users can reconfigure in Customize. 3. Embedded objects submenu now includes commands that can be understood from user POV as "embedded" (even though QR and Audio do not get Properties dialog, and Gallery is actually Image). Another possible response: decide that Eve users who link files are familiar with the chaotic labelling in LO and will just ignore the fact that it is now called embedded. (-: -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 --- Comment #10 from Mike Kaganski --- Insert->Object->OLE Object; use (*) Create from file, check [x] Link to file, and select e.g. an ODS or an ODT or an ODG (or whatever). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 --- Comment #9 from sdc.bla...@youmail.dk --- (In reply to Mike Kaganski from comment #8) > distinction between linking and embedding will be really crucial Skipping over the general point of linking v. embedding -- -- the focus here is on "objects" (in whatever sense) that use sw/uiconfig/swriter/ui/objectdialog.ui Could not find examples of "links" in Writer that use this Properties dialog. Is this in Calc? Are you referring to sections with links to external files? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149050] .uno:Gallery should open the Gallery deck
https://bugs.documentfoundation.org/show_bug.cgi?id=149050 V Stuart Foote changed: What|Removed |Added CC||rayk...@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from V Stuart Foote --- Yes, the command resident on the View -> Gallery is somehow incorrect. Assigning the .uno:Gallery to keyboard shortcut it behaves as I'd expect--refocusing an open (collapsed or expanded) SB onto the Gallery Deck The menu entry for the command will open and close the SB, but it does not open to the expanded Gallery deck, just the collapsed SB. And then it is not clear the SB Gallery deck is getting focus in response to the .uno launch from menu. Not clear that the toggle is behaving either. It will toggle open the SB Style deck from closed SB, and it will close SB when again used. But if the SB is opened to Gallery from menu or if .uno:Gallery is assigned to shortcut--the Style shortcut is non-functional and SB remains on Gallery. Jim R. had done the set of shortcuts ( 1-9) for the SB deck Tabs for bug 84502, and those only function when the SB is active. Did the SB Tab behavior from other UNO get crossed up there? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149052] Change internal spacing of formulas to Zero for better MS Word compatibility
https://bugs.documentfoundation.org/show_bug.cgi?id=149052 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Regina Henschel --- *** This bug has been marked as a duplicate of bug 65067 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 135501] Change the default UI (see comment 67)
https://bugs.documentfoundation.org/show_bug.cgi?id=135501 --- Comment #92 from Eyal Rozenberg --- (In reply to Justin L from comment #90) > If TDF considers the ribbon UI to be a strategic benefit I would actually be interested in links to minutes of such discussions in the past (in the ESC? Design team?) ; and if one is coming up, a notification here or at whatever meta-bug is opened about this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149052] Change internal spacing of formulas to Zero for better MS Word compatibility
https://bugs.documentfoundation.org/show_bug.cgi?id=149052 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 149010] "Previous Link" and "Next Link" should only appear on Frames Options tab
https://bugs.documentfoundation.org/show_bug.cgi?id=149010 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||michael.st...@allotropia.de Keywords|needsUXEval | Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #7 from Heiko Tietze --- There was a GSoC project to enabled chaining for text boxes. http://gsoc15-draw.logdown.com/posts/276831-text-chaining-in-draw-an-attempt-to-specifications http://gsoc15-draw.logdown.com/posts/283339-text-chaining-in-draw-results-at-midterm https://matteocam.github.io/output/announcing-chained-text-in-draw-a-prototype-implementation.html But the next/previous link entries are shown for other objects as well, like images, that clearly need these entries to be disabled. So we have to do it anyway. => disable controls conditionally, rename the "Names" section to "Accessibiliy" and put "Next/Previous" into an extra frame labeled "Sequences" (sounds more user-friendly to me than Chain). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 --- Comment #8 from Mike Kaganski --- (In reply to sdc.blanco from comment #7) > (In reply to Mike Kaganski from comment #6) > > is it consistent to call a linked object "embedded"? > Naive user POV. Sure! > > As a naive user, I would just accept that some objects (including "external > links") are called "embedded" in LO, and not think further about it. ... > > To some extent these distinctions are arbitrary* from UI pov (even if not > arbitrary from technical implementation pov). Oh, I would love to quote you to Eyal in tdf#141452, who insists that "What we should do is *simultaneously* become consistent with "dictionary meaning" _and_ self-consistent", and "dictionary meaning is not a "personal preference", it is the preference of essentially everyone". They insist that the terms used in the program have no right to mean something specific, defined in the program: they require that every word used in the term be exact to the *dictionary* meaning. === rant end === I would say, I agree with you; but in this specific case, the distinction between linking and embedding will be really crucial to the usage for some people; and when they will be confused, unsure if the term means that what they thing "linked" is termed "embedded", they would be really lost, and will have all the reasons to complain (unlike Eyal's case mentioned above). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 --- Comment #7 from sdc.bla...@youmail.dk --- (In reply to Mike Kaganski from comment #6) > is it consistent to call a linked object "embedded"? Naive user POV. Sure! As a naive user, I would just accept that some objects (including "external links") are called "embedded" in LO, and not think further about it. (And from an everyday pov, "external links" sound "embedded") To some extent these distinctions are arbitrary* from UI pov (even if not arbitrary from technical implementation pov). Given that "frame" and "image" get their own labels in the Properties dialog, then it appears that the word "Object" was used as the leftover "Other" category for other objects that have a properties dialog. => any chosen adjective before "object" (even if not a perfect fit) would at least limit the scope of that group of "objects" and allow differentiation from Shape and Textbox, which are also called "objects" (in the generic meaning). * To elaborate this point about a certain amount of arbitrariness, from a user/UI POV -- as noted "frame" and "image" get their own labels in the properties dialog, but in principle, they could be considered as "embedded objects" as well, no? Understandably, "frame" and "image" are used more frequently (and in different ways), so they get their own individual labels, which makes it easier to refer to them in help, etc. No problem (imo). But why (as a rhetorical question) are QR code and media files treated as "Drawing objects" (in Navigator, and do not have an Object Properties dialog), even though, in everyday meaning, they are embedded? And why shouldn't textboxes and shapes also (from user pov) be considered "embedded objects"? As user, it is easy to accept that QR code is listed under Insert > Object (even if technically in LO, it is not), and I accept that QR codes and media files are treated as "drawing objects" -- which primes expectations about which dialogs to use for positioning, formatting these objects. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149013] Description of images, OLE objects and shapes is not exported to HTML
https://bugs.documentfoundation.org/show_bug.cgi?id=149013 --- Comment #5 from Heiko Tietze --- So I misinterpreted your "the long description is available through a disclosure widgets" with my reply "we do the required minimum"? Ultimately not a topic for UX since exporting the description is done in the background. My comment was just about balancing effort vs. need with the idea that HTML is not a native format for text processors. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149013] Description of images, OLE objects and shapes is not exported to HTML
https://bugs.documentfoundation.org/show_bug.cgi?id=149013 --- Comment #4 from Christophe Strobbe --- @Heiko If LibreOffice is not an HTML editor, the proper response is to remove its HTML editing capabilities, not to declare this issue "not a bug". An accessible authoring tool is required to preserve accessibility features when exporting to or saving in other formats where corresponding features are available. Each accessibility issue we ignore will increase the irrelevance of LibreOffice on the European market in 2025, when the European Accessibility Act comes into force. After 2025, LibreOffice will either (mostly) meet standard EN 301 549 or be replaced by a different product (most likely Microsoft Office) in both public administrations and companies in the European Union. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 135501] Change the default UI (see comment 67)
https://bugs.documentfoundation.org/show_bug.cgi?id=135501 --- Comment #91 from Justin L --- Created attachment 180077 --> https://bugs.documentfoundation.org/attachment.cgi?id=180077=edit defaultToRibbonUI.oxt: extension that sets the default UI to notebookbar Like all of my extension configurations, this was based on trial and error, not on intimate knowledge of the correct way to do things. It works - that's all I can say. Any feedback is welcome. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149050] .uno:Gallery should open the Gallery deck
https://bugs.documentfoundation.org/show_bug.cgi?id=149050 Heiko Tietze changed: What|Removed |Added CC||vstuart.fo...@utsa.edu --- Comment #1 from Heiko Tietze --- Maybe we better remove View Gallery / .uno:Gallery. Along with View > Sidebar toggling the sidebar with all tabs and View > Navigator showing an extra window (and the other options there) this command seems to be alien. Stuart, what do you think? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149047] Should .uno:ObjectMenue be shown in the Customize dialog?
https://bugs.documentfoundation.org/show_bug.cgi?id=149047 Heiko Tietze changed: What|Removed |Added Keywords||needsDevAdvice CC||vmik...@collabora.com --- Comment #3 from Heiko Tietze --- The "Object" submenu is not a command (similar File > Recent Documents) but a customizable menu structure. The command uno:ObjectMenue is filled with content in ObjectMenuController::fillPopupMenu using MS_VERBATTR_ONCONTAINERMENU. But no idea what that is, the command remains disabled for me. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149047] Should .uno:ObjectMenue be shown in the Customize dialog?
https://bugs.documentfoundation.org/show_bug.cgi?id=149047 --- Comment #2 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #1) > If you want to customize the menu this command is relevant, isn't it? Is it? Insert | Object is already provided as a submenu. Adding this command to the Insert menu simply gives an inactive command. Insert > Insert Submenu provides a way to add submenus. What am I missing? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 84973] "Date (fix)" fields updated when copy of document opened
https://bugs.documentfoundation.org/show_bug.cgi?id=84973 Heiko Tietze changed: What|Removed |Added Keywords||needsUXEval CC|heiko.tietze@documentfounda |libreoffice-ux-advise@lists |tion.org|.freedesktop.org --- Comment #13 from Heiko Tietze --- "Fix" fields are expected to show the same value on templates as well. At least the help does not state otherwise: "Inserts the current date into your slide as a fixed field. The date is not automatically updated." https://help.libreoffice.org/7.3/en-US/text/simpress/01/04990100.html -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 135501] Change the default UI (see comment 67)
https://bugs.documentfoundation.org/show_bug.cgi?id=135501 --- Comment #90 from Justin L --- If TDF considers the ribbon UI to be a strategic benefit they should: 1.) Have a meta bug that is collecting issues about it. (I assume one doesn't exist since it isn't attached to this issue) 2.) Then keep putting out tenders to fix these issues 3.) Then strongly encourage all the beta testers for the next release to switch to notebook bar and do their testing that way. It should also be a focus of a year of internal QA testing. This isn't an issue that you want to rely on volunteers to handle. It is way too important. The user experience must be excellent as soon as it becomes the default, and issues related to it must be fixed quickly. After notebookbar is deemed ready, it should also wait until an X.0 release to debut as default. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 --- Comment #6 from Mike Kaganski --- (In reply to sdc.blanco from comment #5) I like the direction very much! However, the OLE wrong term has one advantage. The "embedded objects" (using the proposal terminology) may be both linked or embedded. So while distinguishing the embedded objects from MS OLE technology, it introduces another confusion: is it consistent to call a linked object "embedded"? I realize that I myself raised the topic of "OLE is not OLE", but I must confess that I myself don't have a specific proposal how to solve that. Likely the OLE term was chosen by ex-SUN back then because of the same terminology difficulties ... -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149018] "Object" property dialog (and Navigator and UI elements) should be titled "Embedded Object"
https://bugs.documentfoundation.org/show_bug.cgi?id=149018 sdc.bla...@youmail.dk changed: What|Removed |Added Summary|"Object" dialog should be |"Object" property dialog |titled "OLE Object" |(and Navigator and UI ||elements) should be titled ||"Embedded Object" CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #5 from sdc.bla...@youmail.dk --- (In reply to Mike Kaganski from comment #4) > use of generic term in case of embedded objects is inconsistent. For Insert menu: Object -> Embedded Object For Properties dialog title (for embedded objects, e.g, Formula, chart, OLE Object) Object -> Embedded Object In Navigator OLE objects -> Embedded Objects For Title of "OLE-Object" toolbar "OLE-Object" --> Embedded Object Would make it easier in online help to use "object" as generic term and "embedded object" for QR code, formula, chart, OLE object, etc. Better consistency across UI elements. Reduce ambiguity about scope of "Align Objects" (for users who do not read documentation or understand technical differences between Images, Shapes, Formula...) Remove ambiguity that OLE-Object (in Navigator and Toolbar) is not just for OLE Objects. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 141452] Rename Tools > Chapter Numbering back to Outline Numbering
https://bugs.documentfoundation.org/show_bug.cgi?id=141452 --- Comment #29 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #27) > OMG. Are you trying to make just anything that *you personally* touch in the > bug tracker to become completely unmanageable? Thank you for that lovely ad-hominem attack, I'm sure it greatly strengthens your argument. > Users having problems with any term because of inconsistent use inside the > program is a real bug. You claiming that users have problems with a term > because it doesn't fit the dictionary meaning is just words, until we made > the original term *self-consistent*, and *only after that* any *following* > user confusion could be treated as the term being poor itself. That might sound reasonable on first reading, but it's actually the wrong way to go about it. Suppose that in 75% of the places we refer to paragraphs in LO we would call them "puppies". It is _not_ right to aim for consistently referring to paragraphs as "puppies", and to habituate users to that term, only to later consider whether or not change it into "paragraphs". What we should do is *simultaneously* become consistent with "dictionary meaning" _and_ self-consistent. > The only proper order is as I described ... (sigh...) > So each time you mention a term used inconsistently inside a program, and > try to push your vision of dictionary-based approach, you just do it wrong > personally. It is as if you were to say: "each time you try to push your vision of a dictionary-based approach in which paragraphs are not puppies, you're just wrong personally" > I can imagine that there might be a couple of users who would not recognize > Chapter Numbering as related to their task at first You imagine wrong. Chapter Numbering is about Chapters. If you're writing a document without chapters you are quite likely to assume it is irrelevant to you. I would even guess people are more likely than not to fail to recognize it as relevant, although that's more debatable. > No, not that fact, but your personal preference to do it in the wrong order > (see above). You can keep saying "personal" as many times as you like, but dictionary meaning is not a "personal preference", it is the preference of essentially everyone. Diverging from it always needs special justification. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149050] .uno:Gallery should open the Gallery deck
https://bugs.documentfoundation.org/show_bug.cgi?id=149050 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||103459, 99671 Keywords||needsUXEval See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||8125 CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=99671 [Bug 99671] [META] Gallery bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=103459 [Bug 103459] [META] Sidebar UI and UX bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 135501] Change the default UI (see comment 67)
https://bugs.documentfoundation.org/show_bug.cgi?id=135501 --- Comment #89 from Heiko Tietze --- Tagged the clear opinions about making the Tabbed UI the default with minus (9, would include myself here but didn't do so as OP) and plus (4). Considering also some plus from Twitter, comment 72). The experts arguments weight a lot, meaning bad accessibility, customizability, and missing maintenance. OTOH, without bringing this to attention we don't get volunteers to fix the issues. So this remains on hold. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149047] Should .uno:ObjectMenue be shown in the Customize dialog?
https://bugs.documentfoundation.org/show_bug.cgi?id=149047 --- Comment #1 from Heiko Tietze --- If you want to customize the menu this command is relevant, isn't it? -- 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 --- Comment #6 from Heiko Tietze --- (In reply to sdc.blanco from comment #5) > But original question remains... where the "main" content is more about > accessibility Description is exported in case of PDF. Accessibility sounds good to me, even considering Name to be relevant on the Navigator. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149047] Should .uno:ObjectMenue be shown in the Customize dialog?
https://bugs.documentfoundation.org/show_bug.cgi?id=149047 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||103238 CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103238 [Bug 103238] [META] Customize dialog bugs and enhancements -- 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 --- Comment #5 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #4) > could separate these two controls from the Names frame and have an extra > Sequence frame. +1 But original question remainsthe current dialog appears as follows Names Name Text Alternative Description -- where the "main" content is more about accessibility (or if "Description" is not going to be exported, then "documentation"). otoh, section label is not a big deal. On the other, many Eve users want the UI to be "intuitive"/"transparent" without having to read documentation -- perhaps a better descriptor than "Names" can be found. (maybe "Object Description"? ) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 143693] LO should be able to load files from HTTP
https://bugs.documentfoundation.org/show_bug.cgi?id=143693 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #3 from Heiko Tietze --- Usually you do Insert > Text from Document or open a local document via File > Open (and filter for HTML). In general I think these functionality should not be in focus since Writer is not an HTML editor. Talking about import from other sources than locally it bears a security risk. But in fact I can just copy this URL and paste into the open dialog (at least on KDE using kf5 VCL) and get the bug loaded into Writer. => NAB (for Linux/KDE) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 143197] Writer: hidden link between list and chapter numbering
https://bugs.documentfoundation.org/show_bug.cgi?id=143197 Heiko Tietze changed: What|Removed |Added CC||vmik...@collabora.com --- Comment #5 from Heiko Tietze --- I miss the expectation. You have H1 with a latin numbers, H2 uses lower case arabic characters as numbering with only 1 sublevel, and H3, H4 none. Changing via Tools > Chapter Numbering (CN) or Format > B is not different unless you apply an unordered list (bullets), which can't be used in CN. If I use bullets on H3 it's not taken into the ToC, however MSO does that. The round-trip shows both bullet on the heading and in the ToC after updating the ToC the whole entry is missing! No question that this function is difficult in general. But we don't make it easier to access if we remove a shortcut. So how about bending the B function to CN in case of a heading? We could keep the buttons and show some kind of familiar dialog (ideally the dialog still shows list of presets filtered for CN, see bug 120905). The user expectation is to click a button and the software handles the internals. Meaning B is done as list style for ordinary paragraphs and as CN in case of headings. So UX-wise we rather remove the CN dialog than B -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 143693] LO should be able to load files from HTTP
https://bugs.documentfoundation.org/show_bug.cgi?id=143693 Buovjaga changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- 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 Heiko Tietze changed: What|Removed |Added CC||vmik...@collabora.com --- Comment #4 from Heiko Tietze --- (In reply to sdc.blanco from comment #2) > ==> NeedsUXEval about whether to implement for "Text box" My take: keep text boxes simple. Will bring this to the attention of the ESC. (In reply to Regina Henschel from comment #1) > I think, they should be hidden when not applicable. (In reply to sdc.blanco from comment #2) > > > 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 Yes, rather hide in this case than disable. (In reply to sdc.blanco from comment #3) > Can the heading be improved for the section where Previous Link and Next > Link appear? We could separate these two controls from the Names frame and have an extra Sequence frame. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149013] Description of images, OLE objects and shapes is not exported to HTML
https://bugs.documentfoundation.org/show_bug.cgi?id=149013 Heiko Tietze changed: What|Removed |Added CC||m.wegh...@posteo.de --- Comment #3 from Heiko Tietze --- My take: LibreOffice is not an HTML editor and we do the required minimum. Wouldn't invest effort for the description. => NAB -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 124649] Menubar: Show icons for the most important items
https://bugs.documentfoundation.org/show_bug.cgi?id=124649 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||9037 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149037] Should "Name" and "Description" have icons in the Format menu?
https://bugs.documentfoundation.org/show_bug.cgi?id=149037 Heiko Tietze changed: What|Removed |Added Resolution|--- |NOTABUG CC||kain...@gmail.com See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||4649 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Heiko Tietze --- It was introduced for bug 124649 by Andreas. Point is that only the most important functions should have an icon so it's easier to spot them. => NAB -- 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 Keywords|needsUXEval | Status|UNCONFIRMED |NEEDINFO CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Ever confirmed|0 |1 --- Comment #5 from Heiko Tietze --- The topic was on the agenda of the design meeting. The intended workflow is unclear. Why should you want to print issues rather than fixing it? With external tools this might be different but running the check again is cheap and simple. One alternative is to have the issues in a dedicated sidebar tab along with interactions to fix and tips why this is needed (MSO did a great job here). And we could also insert annotations like comments into the document that could be resolved when done. Since the list of issues might be long we would also need a function to remove these annotation, in case the user decides to not make the document fully accessible. So the decision is WF/NAB unless the request is not to print the findings but, for example, to export the inaccessible parts of the documents together with the issue - and to fix it externally. But in this case it needs to be merged back, which is a tricky task. => NEEDINFO -- 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 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |er...@redhat.com |.freedesktop.org| Keywords|needsUXEval | Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Heiko Tietze --- The topic was on the agenda of the design meeting. While such a string in the status bar takes some space which many users probably prefer to have for sheet tabs the idea is to place an icon-only info button next to the "add sheet" button that shows some information about the document in a tooltip-like / balloon. It has the charme that we can give more feedback on the current document in the future such as size on hard-disk, number of rows/cells, or whatever users are interested in. -- 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 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #31 from Heiko Tietze --- The topic was on the agenda of the design meeting. The current situation can be explained (comment 13) and is straightforward. Some may expect the object to move some want it to remain. And ultimately the discussion is somewhat academic anyway. So the recommendation is to keep the current behavior. => WF -- 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 as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #40 from Heiko Tietze --- The topic was on the agenda of the design meeting. Tagged the opinions of individuals here with plus/minus and we have a tie. Having means to directly add the search term would be a great benefit (although I remember Tomaz commenting somewhere else that this modification requires some effort). But it comes on cost of space and we either accept the field to be hidden on small screens or remove many commands to make space. Placing the search field into the header bar as done by MSO is not possible. So we better create a dedicated search tab at the sidebar where a) commands are listed in respect to the position at the main menu (as of today), b) the commands are shown associated with the term whether in the label or the tooltip, and c) the search returns occurences in the document where the word is being used (the quick search function). This will effectively take the quick find into the sidebar. In request in this ticket, asking for a search field in the Standard toolbar, the recommendation is to close WF. -- 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 Heiko Tietze changed: What|Removed |Added Blocks||114039, 108018 Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #4 from Heiko Tietze --- The topic was on the agenda of the design meeting. And in contrast to my comment 2 it is possible to double click fields to get the edit dialog. So we should do the same for index entries. Also since the command state, which defines whether it is shown, depends on how you focus the index entry. So it won't be shown if the cursor is at the end (but the begin works) nor if a multi-selection of two or all characters is done. I assume this to be a different bug - and a challenge for implementation the double-click. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108018 [Bug 108018] [META] Writer UX bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=114039 [Bug 114039] [META] Field dialog bugs and enhancements -- 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 as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #39 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #38) AFAICT the OP opened a bug report *about that*, asking to have a *text field* tor the HUD instead of the button *that is only possible now* (mentioned in the bug report title since comment 11); and then you recommend the OP to file a bug report about that? If you imply that *originally* the bug was worded in a different way, that's what bug tracker is: people with different ideas and different understanding file what they want, and then the discussion transforms it into a reasonable shape, which is now exactly "about it". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 135501] Change the default UI (see comment 67)
https://bugs.documentfoundation.org/show_bug.cgi?id=135501 --- Comment #88 from V Stuart Foote --- (In reply to Mike Kaganski from comment #85) Comment 3, OK--but I'd think my concers in comment 33 (regards bug 109425 and bug 107343) or in comment 53 (illusion of any similarity between NB Glade assemblages and the full API of the MS Ribbon Class) were more substantive in any decision of moving to a MUFFIN NB default UI. -- 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 as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #38 from Eyal Rozenberg --- (In reply to Roman Kuznetsov from comment #11) > Because the UNO for it adds the button to the toolbar, but I would prefer > the text field Ok, well - why not open a bug about that? i.e. having a separate UNO command, or some kind of variant/option to the same UNO command, add the text field? That would be less controvertial... -- You are receiving this mail because: You are on the CC list for the bug.
