I cannot change the order of slides in the slide sorter. If I click on a slide, my cursor becomes the circle-with-a-line-through-it "not allowed" icon, and I cannot slide the slide anywhere.
NOT reproduced with LO 3.4.3 OOO340m1 (Build:302) Ubuntu 10.04.3 x86 Linux 2.6.32-34-generic Russian UI Phil Evans, what is your OS and LO versions? Please write it like in my comment.
I believe this to be a duplicate of my bug report https://bugs.freedesktop.org/show_bug.cgi?id=41910 I experience the same "circle-with-line" icon until changing the sorter configuration to single column (one slide per row). can you confirm this Phil?
My version are: LO: 3.4.3 OOO340m1 (Build:201) Kubuntu 11.10 x86_64 Linux 3.0.0-12-generic And I can confirm that it DOES work in single line layout, and I think I know why, as the problem is more subtle than I realised. Actually, in any layout of the slide sorter, when I click and hold on a slide I first get the "circle with a line, however, if I click on the slide and drag the cursor to the start of the row (i.e. to the left of the first slide in the row) suddenly I get the option to slide it there, and thereafter, I can (as long as I don't release the mouse button) put the slide anywhere. i.e. I *can* move slides in the slide sorter, but only "pretending" I want to put it at the start of the row, waiting for the slide icon to appear, and then moving it to where I want. Which is somewhat bizarre!
It works for me with LibO3.4.3 on WinXP. If you click on the slide, you will get the "circle with a line". But that only means, that you cannot drop it there. Drag to a position between two slides and there the "circle with a line" disappears and you can drop the slide.
@Regina -- no, that's not the problem I have. No matter where I slide the cursor, it remains with the "invalid" icon. Unless, as in my previous comment, I first move the cursor to the start of the row and wait a moment. But it's not just a case of me holding the mouse still and seeing the problem!
I can definitely confirm this problem with LO 3.4.2 in openSUSE 12.1. My observation is that the slide cannot be moved to the actual location (e.g. when I try to move slide 12 to the location between slide 20 and 21) but instead it is moved towards lower slide numbers (not where my mouse pointer is at this time). For instance, it then appears between slide 5 and 6. With a second try, it jumps up between slide 2 and 3. Also, I have the same problem with the slide overview in the normal screen. Same effect, the slide leaps upward, not where I intend to move it. Even worse, after some desperate attempts trying to get the slide at the right position, LO crashed completely (starting with document recovery). I suspect that the forbidden symbol appears because there is already some miscalculation of the mouse pointer position. Michael
Another addition which may be important: I just noticed that the slide sorter works correctly for me with the following procedure: - Grab the slide to be moved - Drag it out of the slide area, e.g. down to the lower border of the LO program window or beyond it, don't release the button - re-enter the slide area; now the slide sorter works for me as intended. However, I also managed to crash LO by this procedure, but not reproducibly. This issue re-appears for each slide, i.e. for each slide I have to drag it first out of the program window, then I can put it between the target slides. Michael (openSUSE 12.1 x86_64, LO 3.4.2)
Confirmed with Debian Lenny (32-bit), LibreOffice 3.4.4
Moving slide work sine on the development branch. I use Archlinux 64bits.
Moving slides works fine on the development branch. I use Archlinux 64bits. (sorry... I didn't checked my last comment)
It has been fixed since 3.5 beta 0, then? Because for me, 3.4.4 and 3.5 beta 0 behave exactly the same in this regard.
Just works fine for me on 3.4.4 on Ubuntu and 3.5.0(pre)beta1 . Independent of number of slides on the row. Have used it regularly over the past months is all kind of versions too.
Can’t reproduce the problem with LibreOffice 3.5.0 [beta 0] Build-ID: ef91e38-b1d4df6-090bcba-45cf606-05891e7 German langpack installed running on MacOS X 10.6.8 German: played around alot with the slide sorter, but everything seems to work fine. -- A Linux-only problem? Looks like ... -- Could someone who sees the bug give a step-by-step description of how to reproduce it? I know this is difficult and maybe not possible, but it would help a lot ...
"-- Could someone who sees the bug give a step-by-step description of how to reproduce it? I know this is difficult and maybe not possible, but it would help a lot ..." c.f. "Comment 3" at the top. However, in as much detail as I can: * Load the presentation. * Go to slide sorter. * Move the mouse over any slide, and press and hold the (left) mouse button. * Move the mouse anywhere within the slide sorter, the cursor will remain the "circle with a line" icon. Additionally: * Still holding the mouse button, move the cursor outside the slide sorter 'window' (i.e. to any other part of the LO window). * Move the mouse back into the slide sorter window. Now, when you move the cursor to a valid place to put the slide, the cursor changes to a thumbnail of the slde and lets you place it as want to. Hope this helps. Incidentally, since I filed the original report I've been updated to LO 3.4.4 (OOO340m1, build 402) and the problem persists. Phil
@Phil Evans: thank you very much for yor step-by-step description! Using the steps given in Comment #14, I can’t reproduce the problem on MacOS X 10.6.8 German, with no one of the LibreOffice versions: -- 3.4.4 with German langpack installed -- 3.5.0 beta 0, Build-ID: ef91e38-b1d4df6-090bcba-45cf606-05891e7 -- current Master (LOdev 3.6.0, Build ID: bedebfc-b204871-3e50423-4c1bcb5 Build date: 2011-12-13) So this really looks like a Linux-only problem.
(In reply to comment #15) > So this really looks like a Linux-only problem. Not really. I work on Linux and don't have the problem (see my previous comment)
(In reply to comment #11) > It has been fixed since 3.5 beta 0, then? Because for me, 3.4.4 and 3.5 beta 0 > behave exactly the same in this regard. Nope, just tried 3.5 beta 1 and the behaviour is exactly the same. It worked correctly in 3.3.3, btw.
3.5.0 Beta1 works fine on my machine, both on Ubuntu and Arch Linux
Created attachment 55349 [details] Cannot move this way. This video example shows how to reproduce the problem. Slide move simply does not work.
Confirmed with Debian Squeeze 6.0.3 (32-bit), LibreOffice 3.4.3 OOO340m1 (Build:302). But I found a workaround. Moving a slide to a new position works when I do the drag through the "slide" area (I have to pass the slide editor area during the move). I will try to attach two video examples, one shows the problem, one shows the workaround.
Created attachment 55350 [details] Workaround I can make it work if I drag a slide through the "Slide Editor" area. The attached video shows how I should drag a slide to a new position: one has to pass the slide editor area.
You are not using the "Slide Sorter" but the "Slide Pane". Look in the middle of the screen, there is a tab "Slide Sorter".
(In reply to comment #22) > You are not using the "Slide Sorter" but the "Slide Pane". Look in the middle > of the screen, there is a tab "Slide Sorter". It does not work in the "Slide Sorter" either. I found a solution in the tab "Normal", therefore I am posting. Probably the problems I have in tabs "Normal" and "Slide Sorter" have the same origin.
> It does not work in the "Slide Sorter" either. I found a solution in the tab > "Normal", therefore I am posting. Probably the problems I have in tabs "Normal" > and "Slide Sorter" have the same origin. And I have a similar solution for the "Slide Sorter" window: One has to drag a slide outside the "Slide Sorter" window and back during the move.
*** Bug 45591 has been marked as a duplicate of this bug. ***
Looks like this bug is UI dependend, e.g. sorting slides works with the GNOME UI but not with the KDE UI...
(In reply to comment #14) > "-- Could someone who sees the bug give a step-by-step description of how to > reproduce it? I know this is difficult and maybe not possible, but it would > help a lot ..." > > c.f. "Comment 3" at the top. > > However, in as much detail as I can: > > * Load the presentation. > * Go to slide sorter. > * Move the mouse over any slide, and press and hold the (left) mouse button. > * Move the mouse anywhere within the slide sorter, the cursor will remain the > "circle with a line" icon. > > Additionally: > > * Still holding the mouse button, move the cursor outside the slide sorter > 'window' (i.e. to any other part of the LO window). > * Move the mouse back into the slide sorter window. Now, when you move the > cursor to a valid place to put the slide, the cursor changes to a thumbnail of > the slde and lets you place it as want to. > > Hope this helps. > > Incidentally, since I filed the original report I've been updated to LO 3.4.4 > (OOO340m1, build 402) and the problem persists. > > Phil Still the same bug in: LibreOffice 3.5.0 Build ID: 350m1(Build:13) in Kubuntu 10.04
Not reproduced with LibreOffice 3.6.0alpha0+ Build ID: ee4bfba-8a74106-c695ec Kubuntu 11.04 32 bit Tested both slide sorter and slide pane with a mini presentation consisting of four slides.
NOT reproducible with "LibreOffice 3.5.2.2 German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit) NOT reproducible with LibO 3.4.4 on Ubuntu / Unity 3.4 lifecycle is terminated, so I remove this dependency Restored most early Version where observed <http://wiki.documentfoundation.org/BugReport_Details#Version> Due Comment 17 this one seems to be a regression Can someone please summary current state of research in Summary (for example KDE dependency or what ever) @Phil Evans a) do you also observe that problem in DRAW? b) has that ever worked for you under same OS with older LibO (or OOo) Version?
@Phil Evans: Please attach a sample document and please answer to my questions in Comment 29?
KDE due to DUP and comments
Created attachment 60720 [details] Simple presentation to demonstrate the issue Apologies for the delay, I missed the comment 28. Here is a simple presentation for which I see this bug. I'm currently on LO 3.5.2.2 - although I'll be upgrading to Precise Pangolin in a day or two which may change my LO version. The same problem exists in Draw I have definitely had versions of OO which worked fine, although I couldn't swear as to when it last worked, or what flavour of Linux I was running at the time.
NOT reproducible with reporter's sample document and "LibreOffice 3.5.3.2 (RC2) German UI/Locale [Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80] on German WIN7 Home Premium (64bit), what underpins KDE suspect. @Lubos: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
I see this problem with "LibreOffice 3.5.2.2 Build ID: 350m1(Build:202)" but it's on KUbuntu Oneiric.
3.4.4 / Unix - Unity on VirtualBox Ubuntu 64 is not affected. @Jon Piesing AFAIK KUbuntu - Oneiric uses some kind fo KDE?!
@Rainer Bielefeld Kubuntu is the KDE flavour of Ubuntu. In case it helps your KDE specialist, I'm using KDE 4.8.2 from (I believe) the Kubuntu backports PPA.
LuboÅ¡ LuÅak committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4450c54aee85b295b933e91d207fd8220c01107 avoid recursion that can mess up DND setup (fdo#41996)
Fixed, closing.
LuboÅ¡ LuÅak committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2742842e3bd77d7572e8b9cdc9d83fa8701c3b33&g=libreoffice-3-5 avoid recursion that can mess up DND setup (fdo#41996) It will be available in LibreOffice 3.5.4.
New to LibreOffice (OpenOffice user for many years) I first posted this the other day in Ask LibreOffice. "Using Version 3.6.2.2 (Build ID: da8c1e6) on a MacAir running Mac OS X Lion 10.7.5 I cannot re-organize Impress slides by any method described in Help: Slide Sorter, Slide pane in Outline, etc. Occasionally a slide will move but only to the front of the slide deck. Occasionally the moved slide will replace another one. Usually after enough attempts LibreOffice crashes." I have now discovered the workaround posted with this bug: attempting to move a slide beyond the active window, then bringing it back into the window produces the thumbnail (which previously did not render). With the thumbnail visible I can drop the slide into position. This appears to work in Slide Sorter, or the Normal view also. Given the dates I see in the comments - latest is 2012-05-14 - it appears the patch for LO 3.5 did not work. I don't know the protocol here. I have changed the status of this bug to Reopened. If you need more info I'm csettpiper@gmail.com
Have since discovered bug 51023 and have copied my last comments to that bug since it appears current. Best wishes and good luck to anyone trying to link and prioritize the bug list! Seems like Mission Impossible.
(In reply to comment #41) > Have since discovered bug 51023 and have copied my last comments to that bug > since it appears current. ... and belongs there, because the present bug report talks about a problem specific to the *KDE* (K Desktop Environment), while your report is about LibreOffice on Mac OS X, just like bug 51023 (mostly) is ;-) So we can set the present bug report back to RESOLVED/FIXED.