There is no way to get the Edit item for an OLE object (chart or Math formula), neither by Edit menu nor by contect menu. You can switch to edit mode only via mouse double click. The error is not in LO 3.3.2, but in LO3.4.0.
NOT Reproducible with "LibreOffice 3.4.1RC1 – WIN7 Home Premium (64bit) English UI [OOO340m1 (Build:101)]". I created some lorem ipsum text with a Math formula in it, then I clicked somewhere into the text. Proceeding to get edit access to Formula: 1. <f5> Navigator opes 2. Arrow down until Ole Object is highlighted 3. <enter> Selects Formula 4. <enter> Edit mode for Formula starts Also worked for me with Spreadsheet objekt. @Regina Can you please contribute exact information what proceeding worked for you with 3.2 and no longer with 3.4?
(1) Start with new spreadsheet. (2) Enter some data, for example x y 1 1 2 4 3 9 4 16 (3) Mark the data and generate an XY-chart. (4) Leave edit mode by clicking outside chart. (5) Click on chart, so that you get green handles (for non mouse: open navigator and select 'Ole-Object' and therein 'object1') (6) Open menu Edit. Notice, that the item 'Object' is disabled. (7) Still with green handles for chart. Open context menu (for non mouse: use context key or Shift F10). Notice that the item 'Edit' is missing. It should be the last one in the context menu. Same, if you try to edit a formula. It is no problem in Writer, but in Calc.
Yes, I was too quick, did not regard component "Spreadsheet" and tested the only LibO application where it works? In CALC I did not find any possibility to get access to the edit mode for an OLE object, because focus of the arrow and <enter> keys does not change to Navigator after <f5>. Function of menu 'Edit > Object' is broken, remains greyed even when object has been selected. In DRAW I can unfold sheet contents in navigator with <enter>, but then function of arrow up/down will be broken. With collapsed sheet contents in Navigator I can move selection in Navigator. Function of menu 'Edit > Object' is correct, greyed out if no object has been selected. Selecting objects in the sheet will work with <tab>, so the accessibility problem does not exist, only Navigator behavior inconsistence. In Presentation we have different Navigator access with <alt+shift+f5>, historical reasons? All the rest as in DRAW. In Writer access via Navigator works, but function of menu 'Edit - Object' seems to be broken. IMHO that is only to get edit access for a selected object, so it should be greyed out if no object has been selected I think in a first step inconsistences will have to be eliminated (or at least to be cleared up), then the access problem has to be solved. I currently have no LibO 3.3.2 available, but I see the same behavior like LibO 3.4 in CALC OOo 3.1.1 and 3.4-dev, so I hesitate to set "Regression" keyword for the particular CALC access problem. @Regina: you are sure that that WORKED in LibO 3.3.2 and not only menu 'Edit Object' remained "not greyed out" although no object has been selected? @Christoph: Can you please bring some order into the jigsaw puzzle i left, check the inconsistency problem (may be additional Bug reports should be filed) and then reassign to Kohei?
Same problem with Chart objects. right click > Edit and menu Edit > Object > Edit work as expected in LibO 3.3.3. Additionally this bug is an accessibility issue because it impossible to edit an object using only the keyboard. Best regards. JBF
@Jean-Baptiste Faure: Do we have ACCESSIBILITY defined as Whiteboard key word somewhere in the Wiki (or: your recommendation where it should be?)
@Rainer: In "LibreOffice 3.3.2 OOO330m19 (Build:202) tag libreoffice-3.3.2.2" I get this behavior: When the object is selected (=green handles), then Edit > Object is enabled. When the object is no longer selected, the item Edit > Object does not reset but is still active, but -of cause- does nothing. Entering and leaving edit mode will reset the item to the true state. The behavior, that the item is not disabled, when no object is selected, is an error in LO3.3.2. But it is not severe, because you do not loose functionality. If an object is selected and you use the item Edit > Object > Edit, the object is indeed set to edit mode. In LO3.4.1 the item Edit > Object is never enabled.
(In reply to comment #3) Testing with LibO 3.3.2 on Ubuntu with LibO application OLE-objects... > In CALC I did not find any possibility to get access to the edit mode for an > OLE object, because focus of the arrow and <enter> keys does not change to > Navigator after <f5>. > Function of menu 'Edit > Object' is broken, remains greyed even when object has > been selected. Works for me, entering the navigator requires tabbing until the navigator list is active. Jumping to the object and entering Edit mode works via "Edit > Object" (tested with a Writer object). The two issues I found: * The context menu in the Navigator doesn't provide "Edit Object" functionality * Shift+F10 opens the context menu in the middle of the Navigator instead of next to the selected item > In DRAW I can unfold sheet contents in navigator with <enter>, but then > function of arrow up/down will be broken. With collapsed sheet contents in > Navigator I can move selection in Navigator. Works for me. > Function of menu 'Edit > Object' is correct, greyed out if no object has been > selected. > Selecting objects in the sheet will work with <tab>, so the accessibility > problem does not exist, only Navigator behavior inconsistence. > > In Presentation we have different Navigator access with <alt+shift+f5>, > historical reasons? All the rest as in DRAW. F5 and Shift+F5 are used for starting presentations - similar to PowerPoint. This is a "compatibility issue", since both users and hardware (Logitech Presenter, emulates a keyboard) rely on some keybindings. Selection of OLE-Objects in Navigator works correctly via ENTER. > In Writer access via Navigator works, but function of menu 'Edit - Object' > seems to be broken. IMHO that is only to get edit access for a selected object, > so it should be greyed out if no object has been selected Correct, it is broken, since it is kept active once an OLE object has been selected (no need to edit it). Concerning the navigator, the "UX related" issue is the weird naming of the context menu "OLE-Object > Edit ...", because it opens the Object Properties Dialog instead of behaving like the menu item "Edit > Object > Edit ...". > I think in a first step inconsistences will have to be eliminated (or at least > to be cleared up), then the access problem has to be solved. > > I currently have no LibO 3.3.2 available, but I see the same behavior like LibO > 3.4 in CALC OOo 3.1.1 and 3.4-dev, so I hesitate to set "Regression" keyword > for the particular CALC access problem. > > @Regina: > you are sure that that WORKED in LibO 3.3.2 and not only menu 'Edit Object' > remained "not greyed out" although no object has been selected? > > @Christoph: > Can you please bring some order into the jigsaw puzzle i left, check the > inconsistency problem (may be additional Bug reports should be filed) and then > reassign to Kohei? Well, did that help anyhow? I think most of the real bad issues are caused by bugs introduced in 3.4.x. The remaining behavior isn't sane as well (and existing since years), but nothing that blocks productive work. At the very moment, I keep the issue as it is - I'm too tired to make any (good) decisions, so I'll probably have a look at it next week. If possible, it would be great (Rainer), if you could highlight and assign the Calc issue for Kohei. For the navigator menu behavior, I can prepare an Easy Hack like "Enable OLE object editing via context menu".
(In reply to comment #5) > @Jean-Baptiste Faure: > Do we have ACCESSIBILITY defined as Whiteboard key word somewhere in the Wiki > (or: your recommendation where it should be?) Yes we should have ACCESSIBILITY keyword. Best regards. JBF
http://cgit.freedesktop.org/libreoffice/calc/commit/?id=89462758bfcaaec34c508f2afe08eacb759c7093 fixes the main issue here, e.g. not possible to edit ( from keyboard ) the chart object. The non-resetting of the Edit/Object remains I don't see immediately how to fix that ( seems to me from the code that it is getting disabled ) but also that looks like an old problem Now what to do with this bug, there seems to be reported here many sub issues ( some ux related ) I am not a fan of the habit of reporting multiple bugs in one. I think these should be separated into individual issues by those that understand them best ( which is not me ) I am closing this bug, please ( those that understand the sub issues ) if necessary separate them out
(In reply to comment #9) > http://cgit.freedesktop.org/libreoffice/calc/commit/?id=89462758bfcaaec34c508f2afe08eacb759c7093 This commit has not been pushed to libreoffice-3.4 branch so the bug is still there in 3.4.1 rc3 :-( Did something prevent from backporting this fix to 3.4.1 ? Best regards. JBF
reportedly: The fix is available in 3.4.3 rc1 (probably in 3.4.2 too, forgot to check).