Description of problem: just does not group in but instead multiplies Version-Release number of selected component (if applicable): okular-4.14.1-1.fc22.x86_64 gnome-desktop3-3.13.91-1.fc22.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
How is this an okular bug? (shouldn't this be against gnome-shell?)
It may help to diagnose this if you could say how you are launching okular when you experience it multiplying (instead of grouping as expected).
well, I do open epub docs from nautilus (Files), right click open, and usual double click. Say.. I do the same with Evince on pdfs - behaves as expected - and other usual suspects.
Reassigning to gnome-shell, for feedback/advice. I'm not privy to how shell implements application grouping.
also okular has recently started to misbehave, became slow to respond to user actions, even scrolling, in my case epub files. I you use j k keys to scrolling it jitters a lot, I saw it after some time of okular being up-running j key was scrolling up, or could have been a buffer had stored "k"es, lots of them, or something else gets messed up. BTW. it would be nice to have j & k scroll like when pulled with a mice - think of all the user without a mouse nor touchpad but with track-point stick.
(In reply to Rex Dieter from comment #4) > I'm not privy to how shell implements application grouping. Windows that map to the same application (e.g. .desktop file) are grouped. The primary way to identify the .desktop file is via the window's WM_CLASS, see [0] for details. [0] https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased
okular does include multiple .desktop files, sometimes one per mimetype, i wonder if that may be contributing to the problem here. Reporter, is shell not grouping items of the same type?
yes, I'm was using okular only for epub docs and it did not group.
Created attachment 945965 [details] contents of /usr/share/applications/kde4/okularApplication_epub.desktop okular's .desktop file for epub documents, in case it helps debugging.
Assuming that Ocular's WM_CLASS is more generic than OkularApplication_epub, that's where the heuristic to match window and application fails. Does it work when you add an appropriate StartupWMClass property to the .desktop file?
(The output of "xprop | grep WM_CLASS" for the window would be helpful here!)
WM_CLASS(STRING) = "okular", "Okular"
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.