Does X have the notion of non-clipped child windows? The behavior in
Windows and OSX for these is:
the parent always stays behind its children
the children are closed automatically when the parent is closed
the children follow the parent when moving
If the answer is no, then I can emulate 2 and 3 but how about 1?
Thanks,
Cosmin.
The closest thing to overlapped non-clipped child windows in X is the window property WM_TRANSIENT_FOR. This will create a window that:
will not appear on the taskbar
will not have minimize and maximize buttons
will be minimized along with its transient-for window
will always stay on top of its transient-for window (most important)
Yes ( you can override this if you implement your own composite manager )
Yes, unless window is added to a "save set".
Yes ( but again with your own composite manager you can change visual mapping of [content of all windows hierarchy] -> [screen] any way you want )
Related
As the title says, I found difference between windows and mac os.On windows, the child window is always on top of its parent like this QWidget *child = new QWidget(parent);. But the difference on mac os, when I clicked the parent window, it raise to the top, and it cover the child window.
So, I want to keep the child window always on top of the parent window, and the effect like windows.
I have tried to set the child windowflag to "Qt::tool","Qt::WindowStaysOnTopHint",but it's not I wanted. It prevents me from clicking other windows or dialogs.
Forgive my poor English.Thanks.
I read this about stack order / z order of windows on X11:
To obtain good interoperability between different Desktop Environments, the following layered stacking order is recommended, from the bottom:
windows of type _NET_WM_TYPE_DESKTOP
windows having state _NET_WM_STATE_BELOW
windows not belonging in any other layer
windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE
focused windows having state _NET_WM_STATE_FULLSCREEN
I was able to use get the _NET_WM_USER_TIME atom to order windows. I used XQuerySubtree and XGetWindowProperty. But it's not the best solution, as lots of times it gets the window before the most recent window. Code here: https://gist.github.com/Noitidart/60aab0a96f060240614f
I was wondering if there was a way to get windows by z order?
Moved from comments:
XQueryTree does return children sorted by stacking order:
The children are listed in current stacking order, from bottommost (first) to topmost (last)
Answer to "is there any way to do a quick test if the window is visible in task bar / task switcher" is "check if it's _NET_WM_WINDOW_TYPE_NORMAL window"
I have an app which creates a series of modeless dialog windows which are shown in a 'cascade. The user is supposed to be able to click on any window to bring it to the top and interact with it.
Here's a screenshot, showing this working as intended. The user has clicked on the window 3rd from the bottom, successfully bringing it to the top.
A user reports that when he runs this, and clicks on one of the obscured window then the window does not rise to the top.
Here is a video showing the problem occurring. It shows a normal cascade of notebook windows, behaving as expected. Then a cascade of my application windows appears, but the user cannot bring any selected window to the top. The selected window changes appearance, indicating that it has been selected, but it remains obscured. ( The video concludes by demonstrating a related problem, which we can probably ignore for now )
The user reports that this problem occurs on other PCs he has tried. I cannot reproduce the problem.
I am completely stumped and cannot even guess what might be causing this.
( One theory I had was that the app had frozen and was no longer responding to paint messages. However, the video shows the user dragging the obscured window out of the cascade, and then the window is painted just fine. It seems clear that the app does not get a paint message, or ignores it, when the window is selected )
The app is written using C++ and wxWidgets 2.9.4 and runs under windows 7
This appears to be a wxWidgets 2.9 issue. When built with v2.8.12 libraries, the user reports that it works fine.
Here is the code to create the windows. Note that the parent is NULL. ( This allows the main application window to be minimized without minimizing the cascade windows - a required feature. )
cNewDataPopup::cNewDataPopup( cPatDataset& data )
: wxDialog(NULL,-1,L"New data",wxPoint(200,200),wxSize(570,242),
wxDEFAULT_DIALOG_STYLE|wxSTAY_ON_TOP )
, myData( data )
{
After some experimentation, I found that adding wxDIALOG_NO_PARENT to the wxSTAY_ON_TOP 'fixes' the problem.
( The following explanation is due to VZ. )
Apparently, specifying the window's parent as NULL is not sufficient to convince wxWidgets that you want no parent. It goes ahead and assigns a parent anyway, more or less at random. This is why odd, unexpected and unreproducible behaviour is observed. The algorithm for assigning a parent was changed in v2.9.x, which is why the odd and unexpected behaviour changes when I upgraded wxWidgets. In order to convince wxWidgets that, yes, really, I do not want a parent for a window, I have to specify BOTH a NULL parent and the wxDIALOG_NO_PARENT style.
The use of wxSTAY_ON_TOP is almost certainly the culprit. If you just need the windows to stay on top of the parent window, don't use this style, either use wxFRAME_TOOL_WINDOW or override WM_SIZE handling by overriding MSWWindowProc() in your parent frame.
In Carbon you could change a window's visibility with HideWindow(WindowRef) and ShowWindow(WindowRef).
In Cocoa I know you can call NSWindow's orderOut: to hide and orderFront:, orderBack: or orderWindow:relativeTo: to put it back on screen, but none of those respect the ordering of the window relative to other windows when it was last visible.
For example, if I have two windows, one above the other, and then call orderOut: on the back window, how do I show the window again such that it is still behind the front window without calling orderWindow:relativeTo:.
The only thing I can think of right now is to remember the window ID of the window immediately above it and then use orderWindow:relativeTo: when showing it again, but I haven't thought through what happens if the window above is closed before the rear window is made visible again.
I don't think there's any method available in Cocoa. I guess you need to mimic that using your idea.
By the way, what was the Carbon behavior if you start from four windows ordered as
A B X C D E
Then hide X
A B C D E
Now the user reorders them, and removes some:
E A C
and then show X again. Where did X go in Carbon in this case?
How do I find the name of the running X window window manager from a program?
If I start another window manager when one is already running, then an error occurs, so there must be a way for the other window manager to detect the first one.
How does it work?
By the EWMH spec, a compliant window manager will set the _NET_SUPPORTING_WM_CHECK property on the root window to a window ID.
If the _NET_SUPPORTING_WM_CHECK property exists and contains the ID of an existing window, then a ICCCM2.0-compliant window manager is running. If the property exists but does not contain the ID of an existing window, then a ICCCM2.0-compliant window manager exited without proper cleanup. If the property does not exist, then no ICCCM2.0-compliant window manager is running.
That window (not the root window, but the one described by a property on the root window) should have a _NET_WM_NAME property on it, which is what you are looking for.
The wmctrl command can display information about many EWMH/NetWM-compatible X window managers including their names:
$ wmctrl -m
Name: Compiz
...
Accroding to its Wikipedia page, it works with the following window managers at the present moment (Aug 2012):
blackbox >= 0.70
icewm
kwin (the default WM for KDE)
metacity (the default WM for GNOME)
openbox >= 3 (the default WM for Lubuntu)
sawfish
fvwm >= 2.5
waimea
pekwm
enlightenment >= 0.16.6
xfce >= 4
fluxbox >= 0.9.6
matchbox
window maker >= 0.91
compiz
awesome
wmfs
You may find an "atom" that has the information, but I don't think there is a 100% guarantee that all window managers use the same atom. Do an "xlsatoms" to list the atoms on your server, or "xprop" (and click) to see the properties (including atoms and their values) of a particular window.