Community
Participate
Working Groups
On the Mac the child shell is treated by the window manager as some peculiar extension of the parent shell. This behaviour is unprecedented and by my experience is specific only to swt-based applications. Movement of the children Shells (shells with a parent Shell) very oddly copies movement of the parent Shell. One other peculiar effect is that both shells are even shown in the Spaces & Exposé as it were just one window. This behaviour is apparent in normal usage of SWT applications – for example see the common usage in the Eclipse IDE: modeless search&replace dialog moves with the main window; even the detached TOOL styled views (e.g. detached Outline, Javadoc, Package Explorer views…) do copy the parent shell movement! This behaviour is unprecedented for any window-style Shell. The only legitimate usage I see is the creation of some pop-up shells for enabling enhanced ToolTip capabilities (e.g. JavaDoc/Declaration 'tooltip') or custom 'menus' for editing and data manipulation (Eclipse text editor ContentAssist). Problems that come with this issue: 1) User has a hard time rearranging windows on his screen 2) Developer has to work around the issue and make compromises in order to provide (approximation of) the desired interface to the users 3) This is just wrong How I have come to filing this bug report: I'm trying to create a proper customizable MessageBox with greater capabilities than the built-in one. And this issue bogged me to the ground as there is currently no way (I could find) to completely simulate the behaviour of the built-in MessageBox. Imagine the classic APPLICATION_MODAL MessageBox: • It is created in the center (X/2 and Y/4 to be exact) of the monitor, where the parent Shell currently resides in. • It is indifferent to the moves of the parent shell. • It is NOT ON_TOP of the other application windows, but always ON_TOP of the Shell(s) that it is blocking with its modality. • It is present on all Spaces (virtual Desktops). (the parent Shell resides in its original Space of course) • Exposé does not display the MessageBox, just the parent. • It leaves the parent shell somewhat focused (the titlebar is not grayed like it would be if it were an inactive window). • Parent of a PRIMARY_MODAL dialog can be minimized / when APPLICATION_MODAL dialog is shown none of the application Shells can be minimized. Workaround: I have found no way to completely approximate the (correct) bahaviour of the built-in MessageBox with Shells – with or without a parent. In PRIMARY_MODAL dialogs this issue can be worked around with using the SWT.SHEET hint to the 'MessageBox' shell. MODELESS dialogs could be created without a parent. However some nice features will be lost: namely the ability of the child dialog to remain on top of its parent and that the parent shell is active if the child is active. APPLICATION_MODAL dialogs can created without a parent shell as well. However such implementation hugely lack the features of a shell with parent: ON_TOP hint has to be set, but the implication is that the child shell is (incorrectly) on top of all of the OS windows; such shell is still NOT visible on all spaces; but it is (incorrectly) visible in Expose as a standalone window. In this instance I have decided to use the default parented implementation, because this workaround IMHO introduces more issues than it solves. Solution IMHO: • implementing children shells that are independent on moves of the parent shells in JNI • introducing new HINT constant that would be applicable to the Shell (e.g. SWT.WINDOW_SHELL – name chosen to differentiate from the current only legitimate usage) OR creating a property of the shell 'private boolean shellMovementIndependent' with setter 'setShellMovementIndependent(boolean val)' and getter 'isShellMovementIndependent()' Thank you very much for reading this report. I hope it makes sense. Best regards, Thomas
SWT Shells are NSWindows, and that's the just the way child NSWindows behave on Cocoa. MessageBox, on the other hand, is implemented as an NSAlert.
Abhishek Kishore: And still, no other Cocoa application does it this way ever, so what is the catch?
(In reply to Tom Brblal from comment #2) > Abhishek Kishore: And still, no other Cocoa application does it this way > ever, so what is the catch? Hard to say. Maybe the applications you've seen don't use child windows at all? The documentation on NSWindow.addChildWindow:ordered says(among other things): "After the childWindow is added as a child of the window, it is maintained in relative position indicated by orderingMode for subsequent ordering operations involving either window. While this attachment is active, moving childWindow will not cause the window to move (as in sliding a drawer in or out), but moving the window will cause childWindow to move." After searching the internet, I don't see that Cocoa provides a way to do what you're asking for. People have tried hacky things like removing the child before drag, and then putting it back. - http://stackoverflow.com/questions/7657132/how-to-move-an-nswindow-without-moving-child-nswindows I would agree with some kind of API in SWT Shell to implement what you're requesting, but as far as I can see, Cocoa simply doesn't support this behavior.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWindow/addChildWindow:ordered: You are right, it seems that this is how children windows work in Cocoa. From the documentation it is clear that: - A NSWindow is first created without a parent and later on can be added as child window via the addChildWindow method. - creating children windows in Cocoa is reserved for special needs like e.g. creating custom menus (https://developer.apple.com/library/mac/samplecode/CustomMenus/) and maybe some drawers under the window as well. From this it seems that frequent usage of children shells under SWT is not in accordance with the spirit of Cocoa. (By frequent usage I mean the Find&Replace dialog, etc.) If would be interesting how other platforms natively use children windows and it could also help us develop an approach that would unify the SWT approach to children shells with the platform. p.s. not only that there is a NSAlert class for various alert dialogs, but there is also a NSPanel class for windows with auxillary functions that could prove usefull in some situations: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSPanel_Class/Reference/Reference.html
Closing this defect. The behavior is as implemented by the Cocoa platform itself.
