After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 321355 - Multi level dialogs: z-order problems
Multi level dialogs: z-order problems
Status: RESOLVED DUPLICATE of bug 112404
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.8.x
Other All
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-11-13 11:10 UTC by Hans Oesterholt-Dijkema
Modified: 2007-07-03 02:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hans Oesterholt-Dijkema 2005-11-13 11:10:34 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.
Comment 1 Bogdan Nicula 2005-11-17 17:50:02 UTC
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).
Comment 2 Bogdan Nicula 2005-11-17 17:51:44 UTC
I'm tired: "After closing box" -> "After closing both boxes"
Comment 3 Nickolay V. Shmyrev 2006-09-21 21:28:20 UTC
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
Comment 4 Hans Oesterholt-Dijkema 2006-09-21 21:59:19 UTC
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

Comment 5 Hans Oesterholt-Dijkema 2006-09-21 22:00:36 UTC
Oh, and no, this is not a MetaCity specific problem.
It happens on Windows XP for me.

Comment 6 John Ehresman 2006-09-21 22:08:58 UTC
Is this win32 specific or does it occur with MetaCity? 
Comment 7 Hans Oesterholt-Dijkema 2006-09-21 23:23:09 UTC
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)
Comment 8 John Ehresman 2006-09-22 03:32:22 UTC
This is almost certainly a win32 specific issue, probably related to how set_transient_for is implemented.  I haven't looked into it though.
Comment 9 Tor Lillqvist 2006-09-22 07:32:09 UTC
> 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.
Comment 10 Hans Oesterholt-Dijkema 2006-09-22 16:47:29 UTC
> 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))
Comment 11 Cody Russell 2007-03-05 18:08:16 UTC
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 ?
Comment 12 Cody Russell 2007-07-03 02:26:30 UTC
I'm marking this as a duplicate of bug 112404.
Comment 13 Cody Russell 2007-07-03 02:27:09 UTC

*** This bug has been marked as a duplicate of 112404 ***