[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Henrik Fehlauer changed: What|Removed |Added Latest Commit||https://commits.kde.org/gwe ||nview/07a2e7f9eccd92c19da4e ||f269f453d61a44b6846 Resolution|--- |FIXED Version Fixed In||18.04.3 Status|UNCONFIRMED |RESOLVED --- Comment #15 from Henrik Fehlauer --- Git commit 07a2e7f9eccd92c19da4ef269f453d61a44b6846 by Henrik Fehlauer. Committed on 09/07/2018 at 19:50. Pushed by rkflx into branch 'Applications/18.04'. Fix external application menu occasionally slowing down startup Summary: If moving the menubar entries to a button in the window decoration is enabled, the bug reporter experiences delays of up to 25 seconds in the startup of Gwenview. Bisecting points to 9631043c1, which added MPRIS support through providing a D-Bus interface. While the exact nature of the problem remains unclear due to not being reproducible outside of the bug reporter's environment, moving the initialization of the MPRIS support after `createGUI` is reported to correct the issue. This may be due to avoiding conflicts or races with the D-Bus connection, which is used for the MPRIS service, the ScreenSaver service and the application menu integration. Thanks to Duncan for reporting the bug and coming up with a fix. FIXED-IN: 18.04.3 Test Plan: `dbus-send --session --dest=org.mpris.MediaPlayer2.Gwenview --type=method_call /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next` still moves to the next image in Gwenview. The external application menu is still working fine. Reviewers: #gwenview, kossebau Subscribers: broulik Differential Revision: https://phabricator.kde.org/D13995 M +6-6app/mainwindow.cpp https://commits.kde.org/gwenview/07a2e7f9eccd92c19da4ef269f453d61a44b6846 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #14 from Henrik Fehlauer --- Diff: https://phabricator.kde.org/D13995 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #13 from Henrik Fehlauer --- Thanks for the continued investigation, Duncan, that's really helpful. Awesome solution, I'll create a Diff on Phabricator tonight. Could you try one more thing, so we know a bit better whether the problem is a real fix or more of a workaround for another problem? As you have plenty of time on a slow/broken startup, please attach GDB to the process, interrupt execution and get a backtrace: $ gdb gwenview |& tee backtrace.log $ r - press Ctrl-C while Gwenview is stuck (but after loading debug symbols finished) $ thread apply all bt - attach the backtrace to the bug As for your patches, both are basically reverting the whole feature: - First patch: You don't set HAVE_QTDBUS in CMakeLists.txt anymore, so the rest of the MPRIS integration won't even get compiled. - Second patch: You skip creating Mpris2Service, which would otherwise be the main entry point for everything else of the MPRIS integration. Regarding MPRIS: That's a DBus service provided by Gwenview (org.mpris.MediaPlayer2.Gwenview), which other parts of the infrastructure can call into because it uses a standardized interface (org.mpris.MediaPlayer2). IOW it isn't a separate dependency to install. For example Plasma's mediaplayer applet can list all services providing that interface and call the forward/play/pause methods. Same thing for KDE Connect. I think even with the patch we should investigate why your media keys are not working: - Can you see Gwenview's DBus service in "qdbusviewer"? - Can you change to the next picture with "dbus-send --session --dest=org.mpris.MediaPlayer2.Gwenview --type=method_call /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next"? - Can you see other services in "qdbusviewer" implementing the interface, e.g. when running VLC? - Can you control VLC with Plasma's mediaplayer applet? - What does your global shortcut configuration in Systemsettings (Media Controller component) look like? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #12 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #3) > And based on the qdbus in the commit code, suspecting the version of it I'm > running might make a difference. It's qdbus-5.11.0_rc2 (qt 5.11-rc2 being > the latest available in the gentoo tree, satisfying the > 5.10 dep of parts > of plasma now, as there's no qt-5.10 in the gentoo tree). Updated to qt-5.11.1 now. Didn't change things. Further notes: Based on a the menu timeout stalling the creation of the window and a hunch I tried simply patch-moving the mpris setup call to /after/ the createGUI() and loadConfig() calls instead of deleting it as in the current hack-around patch... and gwenview loaded fine, its menu worked, etc, with no ill effects that I could see (tho the media keys didn't work in the slide-show, but then they never have for me so that's not a change). I see both the kipi and osx ifdefs are after createGUI and loadConfig too. If the mpris ifdef could likewise be moved lower in the function, and still work to setup mpris, that does seem to solve the menu problem I'm seeing too. mpris? Perhaps this requires a component that I don't have installed, that's not tested for and optionally required to enable this functionality, simply assumed to be installed? Dumb non-dev speculation, but maybe it's actually an mpris dbus call that's not getting a response, because whatever it's trying to call isn't installed, and that's blocking the menu setup dbus call so it doesn't get a response either? If so and you guys have that mystery mpris component installed, that could explain why you're not duplicating. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #11 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #8) > (In reply to Henrik Fehlauer from comment #6) > > @Duncan: Could you quantify how long regular and slow startup is taking for > > you each, i.e. barely noticable, seconds, or minutes? > > Regular startup: Under 1 second. > Slow startup: I've not timed it I've (rough-)timed it now. 25 seconds, +/-2, to window appearance. As I said I'm on ssd and used to near-instant, so it's definitely long enough to get bored and fire up a kpat or ksuduko to play while I wait, tho of course I don't /finish/ a game before it appears. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Attachment #113637|0 |1 is obsolete|| --- Comment #10 from Duncan <1i5t5.dun...@cox.net> --- Created attachment 113829 --> https://bugs.kde.org/attachment.cgi?id=113829=edit Updated hack-around partial-revert patch Only the mainwindow.cpp mainwindow::mainwindow chunk of the original commit/patch needs reverted -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #9 from Duncan <1i5t5.dun...@cox.net> --- Created attachment 113637 --> https://bugs.kde.org/attachment.cgi?id=113637=edit Hack-around partial-revert patch Once I bisected to a single commit I had a patch I could try to revert. But based on the error when I tried there were a couple files that have further changed in that area since then and the revert wouldn't cleanly apply. So I semi-blind (as I'm not a dev) deleted the chunks that added (and the revert would have deleted) the new files, along with the two conflicting chunks (lib/slideshow.(cpp|h)), and tried that, not even knowing whether gwenview at head would build then, let alone run, but it did. And it indeed did eliminate the problem -- I have my gwenview menus back, on (yesterday's) current gwenview, with the partial revert, of course. Here's that semi-blind hack-around partial revert patch. While I don't expect it to help much in getting a proper fix, it does confirm that commit as the culprit, and lets you see what I did to get a menu on otherwise-current gwenview back. I can test debugging or alternative patches too, if needed. Gwenview rebuilds fast, especially with a hot ccache. =:^) -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #8 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Henrik Fehlauer from comment #6) > > gwenview would take a long time to startup again > @Duncan: Could you quantify how long regular and slow startup is taking for > you each, i.e. barely noticable, seconds, or minutes? Note that I'm on (btrfs on) ssd, so even cold-cache startups /should/ be fast. Regular startup: Under 1 second. I suspect the kwin slide-in effect is actually delaying the window appearance. (I have gwenview's clear-thumbnails on exit option set, and actually have the thumbnails dir pointed to tmpfs, so from cold-cache it does take a slight bit of time to generate the thumbnails on the start-page's recent-folders tab, but the dir icons themselves show up effectively instantly and the thumbnails on them populate in under 10 seconds, I'd say.) Slow startup: I've not timed it and perception is notoriously unreliable, but the window doesn't show up for long enough I can launch say kpat and start playing a game, before it shows up. Stracing a slow-start it's quite clear there's some sort of timeout (later diagnosed as the menu load timeout) it waits for, as there's the usual rush of multiple pages of output as it reads all the libs/icons/fonts/config/etc, followed by a pause of I'd say at least 30 seconds, perhaps a minute or two (it was long enough I could select some strace output so I could scroll back to it after the window /did/ show to see where things stopped and notice it was menu related, the clue I needed to test and see that the menu button in the titlebar wasn't responsive), while nothing at all is printed, before it resumes printing more pages of output as the window appears and it regenerates thumbnails for the start page. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #7 from Nate Graham --- I can't reproduce, FWIW. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #6 from Henrik Fehlauer --- @Nate, @Friedrich: Are you able to reproduce, and if so, how? > gwenview would take a long time to startup again @Duncan: Could you quantify how long regular and slow startup is taking for you each, i.e. barely noticable, seconds, or minutes? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Friedrich W. H. Kossebau changed: What|Removed |Added CC||k...@privat.broulik.de --- Comment #5 from Friedrich W. H. Kossebau --- No instant clue. On first look seems somehow the D-Bus usage of the MPRIS service (together with the D-Bus connection to the ScreenSaver service) gets in conflict with the D-Bus connection used for the app main menu integration. Adding Kai: you might have the needed experience and thus idea here. Gwenview does any D-Bus registration at this point in the startup: #0 Gwenview::Mpris2Service::Mpris2Service (this=0xa673d0, slideShow=0x796310, contextManager=0x791940, toggleSlideShowAction=0xae8bb0, fullScreenAction=0xb04470, previousAction=0xbc7fc0, nextAction=0xc274f0, parent=0x844af0) at /home/koder/Kode/kdegit/kf5/kde/kdegraphics/gwenview/lib/mpris2/mpris2service.cpp:44 #1 0x00468feb in Gwenview::MainWindow::MainWindow (this=0x844af0, __in_chrg=, __vtt_parm=) at /home/koder/Kode/kdegit/kf5/kde/kdegraphics/gwenview/app/mainwindow.cpp:856 #2 0x00468324 in StartHelper::createMainWindow (this=0x7fffca70) at /home/koder/Kode/kdegit/kf5/kde/kdegraphics/gwenview/app/main.cpp:94 #3 0x00467da6 in main (argc=1, argv=0x7fffccd8) at /home/koder/Kode/kdegit/kf5/kde/kdegraphics/gwenview/app/main.cpp:159 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Nate Graham changed: What|Removed |Added CC||kosse...@kde.org, ||n...@kde.org --- Comment #4 from Nate Graham --- How odd, thanks for the bisecting! CC'ing Friedrich, who implemented this feature. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- FWIW... I'm not a dev, so while I can bisect and read the source of a culprit commit, it doesn't necessarily tell me what might be wrong like it might to a dev. But it may be worth noting that I have (gentoo/kde's) semantic-desktop USE flag turned off. That means no baloo or kfilemetadata here. Related? And based on the qdbus in the commit code, suspecting the version of it I'm running might make a difference. It's qdbus-5.11.0_rc2 (qt 5.11-rc2 being the latest available in the gentoo tree, satisfying the > 5.10 dep of parts of plasma now, as there's no qt-5.10 in the gentoo tree). -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- And the culprit is... 9631043c1 March 2, 2018 Expose slideshow to MPRIS controllers 8bd2f625c, the previous commit, is fine. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- e41d0a9b5, merge 17.12 on March 2, is good. 785281b76, March 19 and master side of merge c6e514eef branch 18.04 on March 20, is bad. So the culprit is in the series of master-side commits between e41d0a9b5 on March 2 and 785281b76 on March 19. -- You are receiving this mail because: You are watching all bug changes.
