Description: Description: Some objects (Formulas, QR-Codes and general OLE Object) can be inserted via the Insert/OLE-Menu point. Steps to Reproduce: Visit in Menu: Insert/OLE-Object Actual Results: "OLE Object" is a technical term that probably many users are not familiar with Expected Results: Do not expose names of internally used technologies to users if they are not familiar with the terms. Possible Solutions: Dissolve the OLE-Menu point and pull the items in the main insert menu. Reproducible: Always User Profile Reset: No Additional Info: Context: OLE means "Object Linking and Embedding" and is the name of a technology that Microsoft developed to allow the integration of both display- and editing capabilities into different programs. The term is technical jargon, describing an underlying technology rather than what users can do. The Insert/OLE Object/Formula shows the typical behavior for OLE: When editing an OLE object, another program is basically overlayed over the main (embedding) application. I could not find out if QR-Code actually uses OLE, since there is no editing capability exposed and the result seems to be handeled as an image, which is what OLE actually should overcome.
In essence, I agree that users might not use that submenu because of how obscure the name is to them. But if we go further and actually rename from "OLE object" to something else, there are many places where the term is used, including the Navigator. And then there's hundreds of updates for help pages and guides. How would one differentiate OLE objects from others then? It would have to be more verbose, like "Linked or Embedded Objects". So I guess my opinion is: OK to not use "OLE" in the menu, but against changing it to something else elsewhere. (In reply to jan d from comment #0) > I could not find out if QR-Code actually uses OLE, > since there is no editing capability exposed and the result seems to be > handeled as an image, which is what OLE actually should overcome. I was actually wondering about that. Seems like QR/Barcode shouldn't be in there anyway. And when the feature was recently shared on social media, users were surprised it was so hidden away. +1 to pull those out of the OLE submenu if possible, or use a more intuitive categorisation so it doesn't get too big. (It's already the biggest menu in Writer with View and Format.) Also: chart is not in the OLE submenu, but it is an OLE object!
(changed component to "UI" because it would have to be changed outside of Writer too, e.g. in Calc)
OLE based or some "simple" COM Component Object Model, it is still an Object being linked and embedded ;-) The ZXING based QrCodeGenDialog.cxx isn't an OLE, but we do use IOleObject notation extensively cross platform so not incorrect to label the menu entry "Insert OLE Object". Personally I have no issue with leaving menu entry OLE or truncating to Insert -> Object, but is that really any more descriptive for users? Or an improvement for l10n?
@Stuart: I don't think that "Object" is much better, since an image or chart is – from the perspective of a not-knowing-the-internals person - probably also an "object". Thus the suggestion to not nest the menu based on these being (OLE) Objects and the others not.
(In reply to jan d from comment #0) > Possible Solutions: Dissolve the OLE-Menu point and pull the items in the > main insert menu. That makes the Insert menu too large; keep in mind that we have to support small screens. It might work if we use just "Object" and hide all less frequently used items there, including what is now under "OLE Objects". But that brings us to the question which ones are less frequently used. And we have to consider the sub item "OLE Object...". (In reply to Stéphane Guillou (stragu) from comment #1) > "Linked or Embedded Objects" +1
Thanks Ilmari for pointing that one out. Better go through the whole conversation in bug 149018 before deciding anything.
OLE term usage as resolved on dupe, but the 'QR and Barcode...' dialog needs to be repositioned up a level on the main Insert menu. *** This bug has been marked as a duplicate of bug 149018 ***