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.
