Description: Impress slides navigation seems to be broken Steps to Reproduce: This bug is 'floating', it can be diffucult to reproduce step-by-step 1. Open .odp (Impress presentation) 2. Go between slides up and down. Stop at the First or at the Last slide 3. Slide -> Navigate Actual Results: Submenu can works wrong: - variant 1. All submenu items are active (First, Previous, Next, Last). For First/Last slide it should be only two position available. - variant 2. All sumbenu items are disabled (???) Please look at the video attached Expected Results: Correct navigation Reproducible: Sometimes User Profile Reset: No Additional Info: Reproduced for Version: 6.2.0.0.alpha1+ Build ID: bc42b6bfa49cc2b58201a8f6177dd3b1a0c038d8 CPU threads: 4; OS: Linux 4.14; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-06_19:01:37 Locale: ru-RU (ru_RU.UTF-8); Calc: threaded Can't reproduce for GTK3
Created attachment 146440 [details] scr1
Created attachment 146441 [details] scr2
Created attachment 146442 [details] video
(In reply to Vera Blagoveschenskaya from comment #0) > [...] > This bug is 'floating', it can be diffucult to reproduce step-by-step Reproduced with Version: 6.2.0.0.alpha1+ Build ID: 2c614b4b2537997aece7ba0aa7ecd38e55fcffaa CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded For me, this was reliably reproducible using the following steps: 1) open a new Impress presentation 2) add two new slides by right-clicking in the "Slides" sidebar -> "New Slide" 3) left-click on slide 2 4) left-click on slide 1 5) open "Slide" -> "Navigate" menu entry Only "To First Slide" and "To previous slide" are active, while exactly the other two entries "To Next Slide" and "To Last Slide" should be. Using the gtk3 VCL plugin, this works correctly.
(In reply to Michael Weghorn from comment #4) > For me, this was reliably reproducible using the following steps: > Thanks Michael, I tried your steps, and bug is reproducible from my side, too.
On pc Debian x86-64 with master sources updated today + kde5 rendering, I don't reproduce this. Just to be sure, do you still reproduce this with master sources updated from 2018/12/20? If yes, there's something I must miss.
BTW, I noticed this on console too: Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. So I typed: export QT_QPA_PLATFORM=wayland Then I got: arning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. Using Wayland-EGL xkbcommon: ERROR: Couldn't read Compose file /usr/share/X11/locale/: Aucun périphérique de ce type (translation: no peripheral device of this type) Using the 'xdg-shell-v6' shell integration qt.qpa.wayland: Wayland does not support QWindow::requestActivate() qt.qpa.wayland: Wayland does not support QWindow::requestActivate() I don't know if for my tests concerning kde5 I should use or not QT_QPA_PLATFORM=wayland
(In reply to Julien Nabet from comment #6) > On pc Debian x86-64 with master sources updated today + kde5 rendering, I > don't reproduce this. I also can no longer reproduce with the steps from comment 4 and master build of today: Version: 6.3.0.0.alpha0+ Build ID: de3c85928c2df1347a93fc7051b73012f87c8bd6 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded Let's set to WORKSFORME then. @Vera: Please feel free to reopen if you're still experiencing this.
(In reply to Julien Nabet from comment #7) > [...] > > I don't know if for my tests concerning kde5 I should use or not > QT_QPA_PLATFORM=wayland The warnings look OK for me when using Wayland so far. Things should work basically work the same on Wayland as on X11. Since most other people are already using X11, I think it's great if you test using Wayland, so that is also covered. Should you find a new bug, it would be great of course if you could do a quick test whether it happens with X11 as well, and explicitly mention if it's Wayland-specific.
(In reply to Michael Weghorn from comment #9) > The warnings look OK for me when using Wayland so far. To clarify: I mean the output you posted doesn't look problematic, as long as everything works as intended. The X11-related things are not needed and if this is the same as https://bugreports.qt.io/browse/QTCREATORBUG-20400 , the latter warning might disappear with Qt 5.12 after all.
Version: 6.3.0.0.alpha0+ Build ID: 2ee85baac60dde5238e42483d610edf28fcffc6b CPU threads: 1; OS: Linux 4.14; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-12-22_16:58:18 Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded I've tested for the current build 6.3.0.0 Can't reproduce the behavior from Comment0 neither Comment4 Possibly it was fixed with another bug.