This might be by design - but if a drawing object is pasted while another one is still selected, the original one gets overwritten (disappears). While this behaviour is useful in the case of copying and pasting text - I can't really think of any advantages in duplicating it when copying and pasting objects. The other well known text editor (whose name I won't mention here) gets this right in my opinion - and executes a simple paste, even if another object is already selected - ignoring (not overwriting) the selected object. I think this is useful and desirable behaviour in the case of objects - as otherwise objects keep on being deleted while trying to do a quick copy-and-paste.
Confirmed with Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7). But this only happens in Writer. I've also tested with Draw and Impress where the behavior is like one expect (as done in the other text editor). I think this should be changes the way you described it should be. It's what the user expect and it should be the same in all LO-applications. I've also tested this use case in Calc. There you can't even past the object if you have selected another object (nothing happens). You can only past if you select a cell only.
Created attachment 71965 [details] Patch works, but just for writer.
OK, so far as Writer is concerned, I have found the solution. I just needed to teach writer that when the objects are selected AS SUCH, they are not to be overwritten. But what calc is concerned, It seems that the bug is hidden amongst the different input-shells in the depths of multi-threading. So far, I tracked the key-input until it reached a >>Post(0)<< command in vcl/source/helper/evntpost.cxx
OK, this seems fixed. https://gerrit.libreoffice.org/1524 An Alternative would have been to Insert in tabvwsh4.cxx a pCellShell into the Stack. diff --git a/sc/source/ui/view/tabvwsh4.cxx b/sc/source/ui/view/tabvwsh4.cxx index 799f953..eecbcfd 100644 --- a/sc/source/ui/view/tabvwsh4.cxx +++ b/sc/source/ui/view/tabvwsh4.cxx @@ -859,6 +859,7 @@ void ScTabViewShell::SetCurSubShell(ObjectSelectionType eOST, sal_Bool bForce) break; case OST_Drawing: { + AddSubShell(*pCellShell); if (svx::checkForSelectedCustomShapes( GetScDrawView(), true /* bOnlyExtruded */ )) { if (pExtrusionBarShell == 0) but that causes a second toolbar to show up, making the editing field move which can be annoying.
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9fa5c64eeb5d038a5fac25dfd80e72bd22b5ed18 fdo#55582 calc part The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi, Seeing this issue now... I remember there was quite an extensive discussion in OpenOffice.org some years ago to set the behaviour. Interested in that (could look it up maybe...) ? In any case: when a graphic is selected in Writer and then having a pasted one replace that, is useful, IMO
That is what Petr Mladek got confused by. Especially, since the size fitting works only from impress or something, not from writer itself. I wanted to leave it (when pasted from Impress) as is, but, hell, the testers got confused. Good, that is why I ceate another menu point, "Paste into" into writer, so anyone can choose - and also Paste into the frame when copying from writer to writer. At the moment, I am hanging only because the clipboard content seems to differ when copied from writer compared to that when copied from impress, so crashes occur.
(In reply to comment #7) > That is what Petr Mladek got confused by. Has there been discussion on the UX list (I fail to see everyting spontaneous - sorry)
No, just in the gerrit list, in the discussion on the other patch which is still waiting https://gerrit.libreoffice.org/1524
(In reply to comment #9) > No, just in the gerrit list, in the discussion on the other patch which is > still waiting > https://gerrit.libreoffice.org/1524 Oh gosh... Not meaning to be offensive against Sebastian his opinion or the nice description of the situation, but would it be possible to discuss something in some wider circle before we throw over existing behaviour :-) I really doubt that all people that know OpenOffice.org for a long time, and can sometimes have a valuable contribution on discussions, are able to check all bugs here. Following discuss@UX might even be a problem, but then there is at least the audience. (And of course I do not want to suggest that all that was is good and improvements are impossible.)
I didn't mean to bypass any established procedures for discussing or raising bugs in LibreOffice. I've hit a problem with LibreOffice, I searched for a similar bug report and didn't find any - and I assumed posting a new bug would be the best thing to do next. I also couldn't think of any usefulness in overwriting one object by pasting another - but that's just me. I can see the point in overwriting highlighted text by pasting over it - but with objects, I can't see the productivity advantage. I also find the current behaviour confusing - as selecting an object, then copy, then paste appears to do absolutely nothing at the moment (it actually copies and overwrites the object during the paste - but from a UI perspective, things stay unchanged). So it looks like the copy/paste is just not working. I spend time actively encouraging users of other commercial office suites to move to LibreOffice - and when LibreOffice differs in functionality from what they are used - but without any obvious benefits - people get frustrated and find it hard to accept the change. To them it feels like a step backwards, as they have to spend more time and effort in order to achieve the same as before. But that is only from my own perspective and based on my own experience with users. Others might come from different backgrounds or are used to different software - and might see things differently.
(In reply to comment #11) > I didn't mean to bypass any established procedures for discussing or raising > bugs in LibreOffice. I know you did not intend to do that. But when I read the comments here and with the patch, it's really a puzzle for me what is to be changed and what is to be preserved (or not). Could you / someone pls write a clear overview of different scenarios, current behaviour and proposed changes? thanks :)
The calc part is fixed now. It would be easy for me to solve this "bug" as described. However, in writer this bug has one little advantage: If you paste from impress, you can overwrite a single image with one of the same SIZE. So I tried to maintain it, but it MIGHT be confusing, as Petr Mladek showed, and: You might want the same when pasting from writer. And you might want to omit it at all. I thought, I could create a new menu point for this very reason, but I do not know how to set an Anchor to the Inserted object, since both the inserted one and the old one are no "fly" shapes. Thus, they have no anchor, although they oviously do. *confused*. What is the object-oriented path from a non-"fly" shape to its anchor?
*** Bug 49734 has been marked as a duplicate of this bug. ***
Damnit, Petr, why am I not allowed to just fix it so that it is fixed when it would be a problem? Who cares that the picture will be still be overwritten when pasting from Impress? This bug will little likely be a problem then. Just: dont remove the feature that keeps the frame when pasting from impress! I am in a mess in untangling the framing so that you can intentionally overwrite from-writer-to-writer frame-keepingly, which is necessary to justify the creation of the second menu item. Good, you may as well give me two more months and I may find out why I cannot take the positioning from the last frame. Then we have the two menu items you obviously desire.
@lennard, thanks for looking at this & all the complicated stuff behind. IMHO it's most important if you can make sure that behaviour when pasting from Draw/Impress remains. It's there by intention as I wrote before. If testers get confused.. that's part of their job, to learn what features really do ;) Cheers, Cor
A menu point would, at least, make sure that the user realizes that the feature is there.
(In reply to comment #15) > Damnit, Petr, why am I not allowed to just fix it so that it is fixed when > it would be a problem? Heh, I was not strictly against pushing it. It only saw that it did not work in Writer for me and asked about it. All your further comments were about the progress and about further plans. I though that it was work in progress and you had it under control. I personally thing that the new behavior is a step forward and could be accepted. Well, if Cor things that it might be controversial, it might be better to ask on the libreoffice-ux-advise@lists.freedesktop.org.
Hi Petr, * (In reply to comment #18) > I personally thing that the new behavior is a step forward Exactly _what_ is the new behaviour? As written in comment #12, I do not get the picture sharp, what is to be changed. And the especially in relation to the behaviour of pasting Draw/Impress to Writer with a graphic in Writer selected. If the new behaviour is what Lennard writes in comment #17, adding " a new menu point" , then of course I have no objection. Pls enlighten me, before that I will give further comment (if needed) ;) thanks, Cor
Petr Mladek means the behavior of my initial patch for writer. I will adapt that initial patch for the new trunk this weekend. Then you can submit that. Then I will see if i can make a new menu point, giving the user the choice - and the clue that the feature is present. Right now, I have got to do lots of work, I have to adapt a free software, "wkhtmltopdf" to my requirements at work (urgently), have to review a manuscript at work (very urgently), and currently also writing a cdx-file manipulation program, which could also be used as ole object drawer in libreoffice. I thought I would add the menu point rather soon, but each obstacle I encounter pertains into the depth of the inner guts of Libre Office. right now, I can't get the intentionally overwritten object placed correctly, despite the scaling is alright. Just wait until I adapted the abandoned patch (removing the calc part, which is present in 4.1 already)
And the behavior of my initial patch for writer was that the objects are not overwritten when pasting from writer to writer, but overwritten when pasting from impress, but keeping the outer rectangle of the old object. One drawback of this behavior is also, that pasting from a different instance of writer pastes as usual without any overwriting or frame adaption. It would be best to give the user a choice.
(In reply to comment #21) > And the behavior of my initial patch for writer was that the objects are not > overwritten when pasting from writer to writer, but overwritten when pasting > from impress, but keeping the outer rectangle of the old object. Fine! > One drawback of this behavior is also, that pasting from a different > instance of writer pastes as usual without any overwriting or frame adaption. > It would be best to give the user a choice. Would be best. But I think we can leave with the behaviour without overwriting too. thanks & good success with your other work too! Cor
*** Bug 70046 has been marked as a duplicate of this bug. ***
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b7cb2ae5026cfd3bb30f148ed40f244b5c128876 fdo#55582 Writer: Dont overwrite from even when selected, from writer. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I was involved in reviewing the last commit and I am afraid that it was not correct solutions. In fact, I am not sure how to solve this bug correctly. IMHO, the confusion is in the definition of selected object. If you select part of text in Writer and paste something, the selected text is overwritten, so Writer behaves the same way as Draw. The problem is that in Writer, if no text is selected, the cursor is somewhere between two characters and pasted text is added. No text is selected most of the time when you write a text. You need to do explict action (select the text) to overwrite it. In draw, the last added or edited object is always selected, so most of the time some object is selected. This causes that the last object is overwritten when pasting. You need to do explicit action (deselect the object) to avoid overwriting. I am not sure if there is any elegant and practical solution at all.
NO! Draw does not overwrite the currently selected graphic! Nor does spread-calc or impress! That problem was in calc, where it was solved. And with this patch, it is also solved in writer, making stuff MORE unified. The onliest point is that when you paste from draw to writer, you overwrite if selected, and that will be probably desired: When pasting from writer to writer, you most likely want to duplicate something, and then you do not want to overwrite the object you selected to copy it. But when pasting from draw to writer, you supposedly have nothing selected, and if, you may WANT to overwrite this keeping the placement. This is a good behavior, so I want to keep it. And if I apply a patch where this behavior is defeated, I need to add a new menu point which still maintains it. But that menu point should be able to overwrite in writer from writer, or it causes confusion, and that was the sole thing i could not do yet because copying a placement from one object to another object doesn't work, please tell me how!
(In reply to comment #26) > ... the currently selected graphic! Hi Lennard, There is a difference: - select a part of a document that includes a graphic - select only a graphic. From what I understand, Peter was referring to that difference :)
But he claimed >In draw, the last added or edited object is always selected, so most of the time >some object is selected. This causes that the last object is overwritten when >pasting. You need to do explicit action (deselect the object) to avoid >overwriting. >I am not sure if there is any elegant and practical solution at all. But that is not true
(In reply to comment #28) OK, fair enough. Again reading your comment 26, I think that is OK to commit. I agree that pasting to Writer from Draw when something selected >> overwrite nothing selected >> do not overwrite And from Draw to Draw never overwrite. Petr are you still involved enough or could we ask another developer to have this finished?
There was this commit: https://gerrit.libreoffice.org/#/c/5857/ and I think you can work with it. The last thing remaining would be the beautiful menu stuff, but right now, I am heavily involved into another project. And I had to see that when I do carelessly change something, a new bug would result, so the current behavior is better than a fix by a non-expert. So there is a note for the new expert what to do: Add a new menu point to all programs (sw, calc, draw, impress) Which is called: Paste into frame. This must have the effect to paste the clipboard into the frame of the selected object, overwriting it. THEN, remove this behavior from the ordinary paste command, but not earlier, or you will loose functionality.
(In reply to comment #29) > (In reply to comment #28) > > OK, fair enough. > Again reading your comment 26, I think that is OK to commit. > > I agree that pasting to Writer from Draw when > something selected >> overwrite > nothing selected >> do not overwrite > > And from Draw to Draw never overwrite. I personally think that the above mentioned behavior is inconsistent and might cause confusion. I think that the relation between the where-you-paste-from and the overwriting/non-overwriting is hard to understand and thus not user friendly. Also I think that the following assumption from the comment #26 is just speculation: --- cut --- "But when pasting from draw to writer, you supposedly have nothing selected, and if, you may WANT to overwrite this keeping the placement." --- cut --- I do not like that when applications tries to be clever and do surprising things. > Petr are you still involved enough or could we ask another developer to have > this finished? I am sorry. I do not have time to test the patch. To be honest. I have newer done huge documents or graphics in LibreOffice. I am not 100% sure what is the preferred behavior. I have got involved into this bug because it was my turn to take care of pending patches when the first patch was waiting in gerrit. All my comments are inspired just by my common sense.
(In reply to comment #31) Thanks for explaining Peter. I think that it's indeed good to take your remarks into account when working on a next step, the menu options that Lennard mentions. AFIACS, and understanding comments and the current/past way of working, the patch should be really fine for the moment. Cor