GNOME Bugzilla – Bug 321355
Multi level dialogs: z-order problems
Last modified: 2007-07-03 02:27:09 UTC
Please describe the problem: I'm running an application (name=main-window) that opens a dialog box to do something. The given dialog box (name=color-dialog) (parent=main-window) itself (recursively) opens a dialog box to do something. The given dialog box (name=color-picker) (parent=color-dialog) is destroyed, and the dialog-box (name=color-dialog) is presented again. Now, the dialog box (name=color-dialog) is destroyed and something strange happens: The top level window (name=main-window) *hides* behind the window that has been active before the application main-window was activated. This only happens in the given case (I didn't test an other recursion). If I only create the (name=color-dialog) and destoy it, all works fine. Steps to reproduce: 1. Create a top level window (name=main-window) 2. Run a dialog box (name=dlg1, parent=main-window) 3. Run an other dialog box (name=dlg2, parent=dlg1) 4. Destroy dlg2 5. Destroy dlg1 Actual results: The Z-order of the main-window becomes problematic. It hides behind the last active window before the main-window was activated. Expected results: I'd expect the main-window to stay put. Does this happen every time? Yes. Other information: No.
I can confirm this. I see it in an application with an AboutBox. If I click Credits it opens an additional dialog box. After closing box, the main application window hides behind what happened to be the last active window (e.g. Explorer).
I'm tired: "After closing box" -> "After closing both boxes"
Probably I am too lazy to read such a big report, sorry. Can you attach small code that illustrates the problem? It also might be metacity bug
As I have resolved this problem in my mzgtk2 code by doing the following when destroying a gtk-dialog: ;;; GTK+ BUG FIX ;;; To prevent the Z-order of the parent from changing (define (destroy) (if parent (-> parent present)) (-> supers destroy)) This always presents the parent of a dialog and resolves the z-order problem. However, I'd expect Gtk+ to keep the z-order put for me. Steps to reproduce: 1. Create a top level window (name=main-window) 2. Run a dialog box (name=dlg1, parent=main-window) 3. Run an other dialog box (name=dlg2, parent=dlg1) 4. Destroy dlg2 5. Destroy dlg1
Oh, and no, this is not a MetaCity specific problem. It happens on Windows XP for me.
Is this win32 specific or does it occur with MetaCity?
This is a sample in mzgtk2 (i.e. in PLT Scheme). With Windows XP This gives the z-order problem, unless I present the main window (see below: (gtk-window-present w) ). With Linux (GNOME Window manager), it works flawlessly. I don't know about the MetaCity window manager. I think the example beneath should be transcoded to C very easily. ;*************************************************************************** (require (lib "mzgtk2.scm" "mzgtk2")) (define (display-dialog parent) (let ((dlg (gtk-dialog-new-with-buttons "test" parent (+ (GTK-DIALOG-MODAL) (GTK-DIALOG-DESTROY-WITH-PARENT)) #f))) (gtk-dialog-add-button dlg "_Close" 101) (gtk-dialog-add-button dlg "_Open" 100) (letrec ((runner (lambda () (let ((id (gtk-dialog-run dlg))) (cond ((= id 100) (begin (display-dialog dlg) (runner))) ((= id 101) (begin (gtk-widget-destroy dlg) ;;;;;;;;(gtk-window-present w) #t))))))) (runner)))) (define w (gtk-window-new 'toplevel)) (define b (gtk-button-new)) (gtk-button-set-label b "B") (mzgtk2-connect (MZGTK2-CONNECT-BEFORE) b 'clicked (lambda args (display-dialog w))) (gtk-container-add w b) (mzgtk2-connect (MZGTK2-CONNECT-BEFORE) w 'delete-event (lambda args (begin (gtk-widget-destroy w) (gtk-main-quit)))) (gtk-widget-show-all w) (gtk-main)
This is almost certainly a win32 specific issue, probably related to how set_transient_for is implemented. I haven't looked into it though.
> I think the example beneath should be transcoded to C very easily. Well, why didn't you do it then? You don't seriously think any of the very few gtk+/win32 developers (who work on it in their copious spare time) would bother? When attaching sample code that exhibit bugs, the samples should be in C (or Python maybe), a single source file, complete, and minimal. Otherwise the chance anybody will bother trying to run them is mostly nonexistent. But anyway, the issues with transient windows and z-order in gtk+/win32 are known, there are at least two other bug reports about it unless I'm mistaken.
> Well, why didn't you do it then? You don't seriously think any of the very few > gtk+/win32 developers (who work on it in their copious spare time) would > bother? I don't want to be rude or anything, but how much time do you think does it take for me to create a language binding on Gtk+ with mzscheme, while developing an application in it *and* maintaining the SWIG mzscheme module, in my spare time? I understand your viewpoint, but I've already reduced the scheme sample to almost C. Want to know how it really looks like in my mzscheme binding? (require (lib "mzgtk2.scm" "mzgtk2")) (define (display-dialog parent) (let ((dlg (gtk-dialog 'parent widget 'buttons (list (list "_Open" (lambda () (display-dialog dlg))) (list "_Close" (lambda () 'ok)))))) (-> dlg run) (-> dlg destroy))) (let* ((w (gtk-window 'widgets (gtk-button 'label "_B" 'closure (lambda a (display-dialog w)))))) (-> w show-all) (gtk-main))
Is this still a problem? And is there any chance that this is a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=112404 ?
I'm marking this as a duplicate of bug 112404.
*** This bug has been marked as a duplicate of 112404 ***