Red Hat Bugzilla – Bug 1059252
Edit chart window from pmchart not recognized as a separate window by gnome
Last modified: 2015-06-29 10:51:24 EDT
Description of problem: Running gnome, when one opens the "Edit Chart" window from pmchart, one can not wwitch between the two pmchart windows using the normal key combination (ALT and the key above tab) Version-Release number of selected component (if applicable): pcp-gui-1.5.11-1.fc20.x86_64 mutter-3.10.3-1.fc20.x86_64 gnome-shell-3.10.3-2.fc20.x86_64 How reproducible: Every time Steps to Reproduce: 1. pmchart 2. File -> New Chart 3. Note the pressing ALT-TAB only reports a single PCP charts window being available 4. Note that it's not possible to switch between the two pmcharts windows using ALT and the key above tab
Hmmm, not sure about this one. Can you open up the Gnome Keyboard Shortcut program and see what Ctrl+<key-above-tab> maps to? For me, thats via running the gnome-keybinding-properties tool, but newer Gnome versions don't seem to have that - all done via a global Gnome Settings tool. But if you search around a bit in the system settings, hopefully you'll find the keyboard shortcut list. On my system, there's two shortcuts either of which might be the one you're refering to - one described as "Move between windows of an application immediately", the other "Move between panels and the desktop, using a popup window". Both of these appear to function as I would expect, and correctly in pmchart AFAICT (we don't do anything special in pmchart - these are just "regular" modeless dialog boxes). In steps to reproduce you mention "Note the pressing ALT-TAB only reports a single PCP charts window being available" - this will because there is only one pmchart program running - the Edit Chart window is a child dialog, and not a separate program, hence only one pmchart entry should appear in that list. From my investigations so far, everything appears to be in order here, so I think I'm missing some information or the intent you're after here. Or, perhaps the intent you're after is from a different shortcut (navigation *within* the dialogs of an application, in this case, and not between different/separate applications). cheers.
I believe the shortcut I'm referring to is "Switch windows of an application" The gnome-shell keyboard shortcut utility claims it's disabled, but it's not (Bug 757446)
Created attachment 857434 [details] screenshot maybe the attached "screenshot" clarifies a bit. The firefox has two windows (these are two windows of the same process, opening e.g. the preferences window would also report it as a window) open, so gnome-shell reports it with the little white arrow. pmchart on the other hand does not display this white little arrow although there are two windows open.
Heh, thanks David - nice screenshot. Can you try something for me - if you pop up the "Open View" dialog, does that change the running-applications tab in the spot you've indicated with the black arrow? From looking in the code, these two windows are very similar, but Open View has an explicit call to set the modality, whereas Edit Charts does not. I guess it will not help but its worth a try anyway - if it does help, its an easy fix to make. The Open View dialog is accessible from the little blue folder icon just below the File menu item, in your screenshot. thanks.
> Heh, thanks David - nice screenshot. Creativity... (-: But no, the "Open View" dialogue has the same issue. Gnome doesn't recognize there is an additional window open.
OK, figured as much. :( So this tells us there's not likely to be a whole lot of action we can take here - both of these windows are simple dialog-style windows (via Qt QDialog class), and for whatever reason Gnome doesn't create its little drop-down-arrow-thing for this class of window. Perhaps its not meant to, and those are more intended for applications with multiple top level windows? Not sure. FWIW, I can add that we make no modification to any hotkeys or shortcut keys that the windowing environment might be applying to the top level windows - we just take it as it comes. And these are bog-standard dialog boxes, nothing fancy/special/likely-to-induce-failure going on from our end. So ... I don't think there's anything we *can* fix here, much as we might like to - how Gnome behaves in this area is up to Gnome (and seems to have changed from release to release), and there's not anything we can realistically tackle from within the pcp-gui tools to change the choices it makes.
please attach the output of xprop on both windows. That should give us a clue
Created attachment 859168 [details] xprop output on the main pcp charts window
Created attachment 859169 [details] xprop output from "new chart" dialogue
The second window is a) a dialog and b) marked as 'skip taskbar'.
| The second window is a) a dialog and b) marked as 'skip taskbar'. Thanks Matthias - so, given that New Charts and Edit Charts are indeed just regular dialogs, and the X properties appear to support that - is it the expected behaviour from Gnome that they not appear with the taskbar drop-down arrow that David seeks here? If so, then this appears to be not-a-bug (these are just dialogs, so I'm inclined to think Gnome is behaving as-designed here, at this stage). If not, then this would appear to be a core Qt library issue that would affect many applications...?
I can't say which behaviour is "correct" or not but from a usability perspective, at least when I use pmchart, I have the "New chart" window open for an extended period of time while I'm tweaking which metrics show me what I want to see. (I would even call it a "Tweak chart" dialogue). And then it's quite annoying loosing the window on my crowded laptop desktop. Could it be so that a different QT widget would be more suitable for this "dialogue" (which I argue isn't really a dialogue) Or am I just using it the wrong way?
| "dialogue" (which I argue isn't really a dialogue) Or am I just using it the | wrong way? Its a different model to the one I use, but certainly not wrong ... there are other options we can look into, in terms of setting flags on dialogs or perhaps creating them with no parent widget - I shall try 'em and follow up with my findings. It will be a little while though - I've got a few high priority issues in the queue. I do want to spend more time on the pcp-gui tools though, so I will be back here... stay tuned. cheers.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Move pcp-gui bugs into pcp, post-package-merge.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.