Created attachment 114753 [details] example file When entering into edit mode in OLE objects like charts or equation, all the content of the document moves. In general it seems that this movement is related with the existence of different quantity of toolbars on top, plus docks at left like page navigator. Exiting the edit mode leaves all in its position. However, I have found this movement quite annoying. It's drastic. IMHO the content of the document shouldn't change its position when selecting objects or entering into edit mode, and if it does, the change should be smooth. Moreover, sometimes when entering into the edit mode, not only the content of the document is not in the same position on screen, but also the relative position of the object is wrong! I'm attaching the file "movement_of_objects.odp" to show what I mean. I'll also attach some screenshots if what I mean can't be understood. Steps: 1) Open ODP file attached 2) Double click on the chart at left to activate the edit mode Expected result: 1) The content of the document remains in the same position, on screen. 2) The relative position of the object, with respect to the content of the document, remains constant Actual result: 1) None of the expected. a) When editing the chart, the slide is moved a little to the right, and the chart appears outside the slide!! b) When editing the equation, the slide is moved upwards because the equation code dock appears. But also, the equation itself is moved into the middle! It's even a little scary, even for me. Notice that the symbols (squares) which shows the position of the object in the slide (or spreadsheet, or doc page) shows the correct position, which will be restored when exiting the edit mode. Notice that this bug is different from bug 90515, though maybe they are related.
Hi Francisco, This movement is due to edit mode launching the internal chart app which has a different set of toolbars than the app the chart is included in. It is hoped that in the future, the app toolbars of the app that includes the chart can remain and just the chart toolbar appear when going into edit mode.
Created attachment 114764 [details] sceenshot 1 (In reply to Jay Philips from comment #1) > Hi Francisco, > > This movement is due to edit mode launching the internal chart app which has > a different set of toolbars than the app the chart is included in. It is > hoped that in the future, the app toolbars of the app that includes the > chart can remain and just the chart toolbar appear when going into edit mode. Hi, Jay. Yes, I know that: it also happens when editing file inserted in a document, like a Draw file in Writer. But, see screenshot 1: the chart is positioned inside the slide, becuase I putted there. Ok, now lets launch the edit mode (screenshot 2): the content has been moved to the right. Ok, I don't like it personally and we all hope that toolbars in a future won't be a problem Ok, but notice that also that the chart is located in a complete different position, relative to the slide content. It's outside the slide! Put this in a context of a novice user... he/she puts it there, try to edit, and suddenly, that chart was outside the slide. The user sees that the content of his document has suddenly changed, and not that the edit mode has been launched. So, even if the content moves in one direction because of toolbars and docks or not, care should be taken in the fact that the object that the user sees should be in the same position relative to the content.
Created attachment 114765 [details] screenshot 2
(In reply to Francisco from comment #3) > Created attachment 114765 [details] > screenshot 2 That seems like a bug to me, as the chart should be in the exact same place in the document as it is when entering edit mode. I just tested it now in impress and it worked fine. What is that fourth toolbar i'm seeing in the screenshot outside of the standard, formatting and drawing toolbars, as those are the only ones that should be accessible in edit mode. See that your on plasma 5. Which distro you running?
Hi, Jay > That seems like a bug to me, as the chart should be in the exact same place > in the document as it is when entering edit mode. I just tested it now in > impress and it worked fine. What is that fourth toolbar i'm seeing in the > screenshot outside of the standard, formatting and drawing toolbars, as > those are the only ones that should be accessible in edit mode. It's a custom toolbar I created, for being able to edit shapes drawn in charts. (Necessary workaround for bug 39052). It has "character", "line", "fill" and "size and position" options. That's because the options for shapes drawn in charts are more "limited" that the ones in Writer (see bug 58038), and have also its particular bugs (see bug 58027). > See that your on plasma 5. Which distro you running? Ha! It's just a plasma 4, with a "Brezze theme" I found in kde-look.org. Anyway, I'm running Kubuntu 14.04.
Hi Francisco, (In reply to Francisco from comment #5) > Hi, Jay > > It's a custom toolbar I created, for being able to edit shapes drawn in > charts. (Necessary workaround for bug 39052). It has "character", "line", > "fill" and "size and position" options. That's because the options for > shapes drawn in charts are more "limited" that the ones in Writer (see bug > 58038), and have also its particular bugs (see bug 58027). I had noticed the same problem as bug 58038, when i was working on improving the chart toolbars and thought to file a bug for it, but glad to see that you have already done so. I believe the best solution is to not allow drawing capabilities in chart edit mode and have users do drawing over the chart object in the document, as i dont see why it needs to be embedding into the chart other than so that it remains in place when a chart is moved around. I believe we can get those buttons you have into the formatting and shapes toolbar, so people can easily enable them rather than create a new toolbar. > Ha! It's just a plasma 4, with a "Brezze theme" I found in kde-look.org. > Anyway, I'm running Kubuntu 14.04. Well LO 4.5 will be coming with breeze icons, so hopefully it will all blend well on your setup. :D
Regarding this bug, I'll test in my house with LibO 4.5 if the problem is still there (now I'm at work) ------------------------------------------------------------------------ (In reply to Jay Philips from comment #6) > I had noticed the same problem as bug 58038, when i was working on improving > the chart toolbars and thought to file a bug for it, but glad to see that > you have already done so. > > I believe the best solution is to not allow drawing capabilities in chart > edit mode and have users do drawing over the chart object in the document, > as i dont see why it needs to be embedding into the chart other than so that > it remains in place when a chart is moved around. You are right, they are useful for fixing shapes in a chart. For example, a chart may have a "call" shape for indicating something of a specific point. Or a line could be drawn to separate two regions, etc, etc. And charts in spreadsheets are continuously moved around. I find this feature useful. It was introduced with LibO 3.3, imported from OOo. (https://wiki.documentfoundation.org/Marketing/LibOReleaseEvents/LOPressKit/FeatureList3.3#Productivity_Enhancements) (Also, those shapes should also be useful as workaround for bug 39052, but not at the end because of bug 58027.) > I believe we can get those buttons you have into the formatting and shapes > toolbar, so people can easily enable them rather than create a new toolbar. Indeed. > Well LO 4.5 will be coming with breeze icons, so hopefully it will all blend > well on your setup. :D Yeap, I know! I was using it on LibO 4.4... but bug 90581 took me back into Libo 4.3. :-P
Created attachment 114844 [details] the attached opened with LibO 4.5 alpha 0 I've just tested the attached ODP file with LibO 4.5, and the bug is there Version: 4.5.0.0.alpha0+ Build ID: 09a1e4f36128f64029d45a38d9b059bf11ea0821 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-15_23:39:39 Locale: es_AR
@Heiko: Does this happen to you on your KDE desktop?
I can confirm with Version: 4.5.0.0.alpha0+ Build ID: 51e0d789c344547956764c3b5f0ef5a304f4e0aa TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-13_16:58:45
@raal: which version of ubuntu are you running?
(In reply to Jay Philips from comment #11) > @raal: which version of ubuntu are you running? 14.10, Unity
Created attachment 114891 [details] the same bug in LibO 4.3.6 under Windows 7 I can reproduce this bug also under with LibO 4.3.6 under Windows 7.
Okay i see where i was going wrong. I was zooming out to fit slide in windows before double clicking. So the problem seems to arise when the slide is zoomed in more than what can fit in the viewable area. This seems to be a refresh issue, as when the chart is in its moved position, if you scroll up or down, it will refresh to its correct position.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Tested again in the following version: Versión: 5.2.1.2 Id. de compilación: 1:5.2.1~rc2-0ubuntu1~trusty0 Subprocesos de CPU: 4; Versión de SO: Linux 3.13; Renderizado de IU: predeterminado; Configuración regional: en-US (es_AR.UTF-8); Calc: group Situation has been really improved since now at least, the chart isn't moved to the left, outside the slide. Moreover, it remains in the same relative place _if_ there are the same amount of toolbars in the Impress and Chart apps. If, however, there are different number of toolbars, the chart is moved as shown in the screenshots. Moreover, the problem is _still_ present in the Math app. Steps: 0) Set different amount of toolbars in Chart and Impress 1) Open the new example file: it's actually the same as the original, but now it has a black line drawn to show the position. (screenshot 3) 2) Enter in the edit mode for the chart: Result: the chart is shown in a different position regarding the original relative position in the slide. (Again, it remains perfectly in the same place if there are the same number of toolbars). This is screenshot 4. 3) Enter in the edit mode for the equation in the file Result: the relative position changes completely: the slide it self moves around, and the formula appears in the middle of the screen. (However, the selection marks are in the correct place, see screenshot 5)
> Result: the chart is shown in a different position regarding the original > relative position in the slide. (Again, it remains perfectly in the same > place if there are the same number of toolbars). > This is screenshot 4. Sorry, I made a mistake: even if there are the same amount of toolbars, the relative position of the chart with respect to the slide changes. What doesn't change is the position of the chart with respect to the LibreOffice window. This is what screehshot 4 shows.
Created attachment 127462 [details] new example file This is the new example file. It's barely the same except for a line above the only 2 objects on the slide.
Created attachment 127463 [details] Screenshot 3: File opened with Impress 5.2.1 This is the what I see when opening the file.
Created attachment 127464 [details] Screenshot 4: edit mode for the chart.
Created attachment 127465 [details] Screenshot 5: edit mode for the equation.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Dear Francisco, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #23) > Dear Francisco, > > [...] Dear QA admins, The bug seems solved in LibO 6.3 under Kubuntu 18.04. Versión: 6.3.3.2 Id. de compilación: 1:6.3.3-0ubuntu0.18.04.1~lo1 Subprocs. CPU: 4; SO: Linux 4.15; Repres. IU: predet.; VCL: kde5; Configuración regional: en-US (es_AR.UTF-8); Idioma de IU: es-ES Calc: threaded Thank you all for your efforts.
Created attachment 156319 [details] The bug is solved for charts, but not for equations Dear all, Sorry, but I mistakenly only checked for charts: the chart remains in the same relative position in the slide. However, the equation still moves when entering into edit mode. Again, sorry for my mistake, and thank you for solving the "chart part".
(In reply to Francisco from comment #25) > Sorry, but I mistakenly only checked for charts: the chart remains in the > same relative position in the slide. Tested in Versión: 6.3.3.2 Id. de compilación: 1:6.3.3-0ubuntu0.18.04.1~lo1 Subprocs. CPU: 4; SO: Linux 4.15; Repres. IU: predet.; VCL: kde5; Configuración regional: en-US (es_AR.UTF-8); Idioma de IU: es-ES Calc: threaded
(In reply to Francisco from comment #18) > Created attachment 127462 [details] > new example file Still repro with equation in this file Arch Linux 64-bit Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 48570b9b5e4939069f8a1a2541fd4efe6f2bb0aa CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 18 March 2021
Well, this bug was filled because the issue was present when editing both, charts and formulaes. Charts aren't a problem anymore; and for formulaes, there's bug 37754, which is older. I'm closing this one *** This bug has been marked as a duplicate of bug 37754 ***