While trying to implement click-to-focus in my custom window manager, I noticed that windows were lowering when I clicked on them, instead of raising. The lines in question looked like this:
XSetInputFocus(this->display, this->event.xbutton.subwindow, RevertToParent, CurrentTime);
XRaiseWindow(this->display, this->event.xbutton.subwindow);
I changed that to
XSetInputFocus(this->display, this->event.xbutton.subwindow, RevertToParent, CurrentTime);
XLowerWindow(this->display, this->event.xbutton.subwindow);
and now windows are being raised when I click on them, as is proper.
Per the man page: "The XRaiseWindow function raises the specified window to the top of the stack so that no sibling window obscures it." Vice versa for XLowerWindow. The behavior I'm observing is precisely the opposite of what is described; XRaiseWindow pushes windows to the background instead, and XLowerWindow moves them to the foreground.
What is going on here?
(This is with Ubuntu 14.04.2 LTS, for what it's worth.)
The problem turned out to be trivial, and entirely my fault: the lines above were in a switch() statement, the break; statement below was missing. The next condition called XCirculateWindowsUp(). So focusing and raising the window would fall through to lowering it again.
Whoops.
Related
While using the amazing Python Jedi plugin from GVim, I have started noticing some odd behavior with function completion tips popup (not the autocomplete as far as I can tell).
Firstly, while the function argument helper popup is visible, GVim input becomes laggy, even for builtin functions and standard types. Once the popup is closed, lag disappears. Autocomplete seems to work just fine on all levels, this lag seems to only apply to the function helper.
Secondly, I recently had a case where a popup became frozen in the buffer, even after it should have closed, and actually replaced the contents of the buffer at that location in the file. I finished the function I was working on, and then used :/__init to jump cursor location. My window scrolled down, but apparently the original function popup didn't clear, and become a fixture in my text.
When I saved the file, that line was replaced with the popup contents (obviously threw an Exception when python tried to execute that line). Going back to that location in the file, reactivating that function help popup and then closing it again fixed the frozen popup text.
Are these problems related?
Is this an aggressive configuration setting that I should change. Honestly those popups are a bit too aggressive for my liking sometimes, so how do I disable/hotkey-bind them in the configuration?
I have only experienced this behavior in GVim. Maybe it happens in console vim, but I have not tried to reproduce the situation, so I don't know.
GVim circumstances:
7 tabs open
each tab usually has two vertical windows
each window is usually a separate python module
There's a multitude of issues about this on jedi-vim's issue tracker: https://github.com/davidhalter/jedi-vim/issues/217. The whole lag situation is slowly getting better.
One of the easiest solutions is to just disable call signatures:
g:jedi#show_call_signatures = "0"
As of now (I just merged that), there's another way of displaying call signatures:
The call signatures can be displayed as a pop-up in the buffer (set to
1, the default), which has the advantage of being easier to refer to,
or in Vim's command line aligned with the function call (set to 2),
which can improve the integrity of Vim's undo history.
You could try if you like this better (but you have to update jedi-vim):
g:jedi#show_call_signatures = "2"
Okay, as Title says.
For example, i use NAudio to playback what i record (loopback if you want).
And if i click on the GUI (the top part, so i can move the window).
It will cause a "sleep", and when that happens the current activity (Audio playback) stops.
And then it continues afterwards.
But i want to remove that, as i don´t know any other application that has it, so it´s probably something to do with how i am programming.
Please keep it simple, i am extremely new to c#.
I am guessing on Bakckgroundworker or something, but i couldn´t get it to work.
So hopping for a more concrete answer.
This was just me not understanding that using the Main Thread in a window form will cause anything on the GUI to be run on it.
Meaning, if i move the GUI, that movement will be Priority over the rest of the code, so everything else will get paused if run on that thread.
Perhaps it differ from object to object, but in this scenario it was the case, so i just moved it to a separate thread and it´s solved.
I want my frame to be always on top, but I want it to be really on top. I want no other windows to hide it, even if they are also "always on top". I'm using wx.STAY_ON_TOP and wx.FRAME_FLOAT_ON_PARENT, but still there are windows that appear on top of mine. Also, the taskbar appears on top of my frame, while I'd like it to be behind my frame.
I've tried a lot of things that didn't work, detailed here.
Any idea how to make my frame really on top?
Because their is no standard method in doing so, as it is most often an undesired effect, you can possibly achieve this by frequently setting the topmost flag again to "overrule" any other applications going for the topmost position. You could do this using a timer which sets the value every x ms, or you can try and only set the ontop flag again when the window has lost focus. The events to set the ontop flag are:
EVT_SET_FOCUS
EVT_KILL_FOCUS
Try using this:
wx.Frame.SetFocus()
So yes, I find myself in the dubious position of implementing a SwitchToThisWindow call to force my window to the front. I agree, its not ideal, but its not always possible to argue against product "features" that others deem necessary.
Now, I consider SwitchToThisWindow to be a win over the AttachThreadInput hack to do a forced window switch as its less likely to deadlock, and should SwitchToThisWindow be removed, or cease to function I won't complain.
However, SwitchToThisWindow has the unfortunate side effect of pushing the current foreground window to the bottom of the z-order in addition to bringing the target window to the top when FALSE is passed for the fAltTab parameter, and not doing anything if TRUE is passed.
How can I avoid this 'push current active to z-bottom' behavior without resorting to AttachThreadInput?
Alternatively, MS can just remove AttachThreadInput as a viable workaround and I can just tell my manager that the impossible, is in fact, actually, impossible.
I don't know if this helps, but the only way i found out to bring my window to top reliably is to make the following 2 calls:
ShowWindow(myhwnd, SW_MINIMIZE);
ShowWindow(myhwnd, SW_RESTORE);
Obviously these calls only should be made, when your window currently is not the topmost one in order to avoid flickering. But this also should not have the side effect of bringing the current front window to the bottom of the z order.
When passing fAltTab=FALSE you are actually emulating Alt+Esc. So you could reverse this z-order change with SetWindowPos and its hWndInsertAfter after the SwitchToThisWindow call, but then you are back in ugly hacky-land IMHO.
The question is, do you really need keyboard focus?
Let me suggest another alternative:
If your window is minimized, restore it
Set your window to be topmost, when your window is activated remove the style again.
Call SetForegroundWindow to flash the taskbar button (Or FlashWindowEx)
This should avoid the scenario where a user is typing and ends up performing some action in your UI without even looking at the screen.
Edit:
HWND hwndFgnd=GetForegroundWindow();
SetWindowPos(hwnd,hwndFgnd,0,0,0,0,SWP_NOSIZE|SWP_NOMOVE|SWP_NOACTIVATE);
SetWindowPos(hwndFgnd,hwnd,0,0,0,0,SWP_NOSIZE|SWP_NOMOVE);
..will probably work if you don't want to set the topmost bit at any point (Even if your window is at the top of the z-order, you still can't legally get the focus with SetForegroundWindow)
This is a bad problem I faced too. See my solution here. It works both for Show() and ShowDialog().
I am facing a little annoying design problem. Not easy to give a title of my question.
I must display two windows, one over another one. The first one is a Cocoa window, the second is made with Qt. In the second window, an action is performed, but the user can choose to close this window. He must fall back on the first window.
To display my first window, which is actually a SFAuthorizationPluginView, I do:
[myview displayView];
then, to display the window made with Qt on top of first window:
QWidget* w = openMyScreen();
NSView* v = (NSView*)w->winId();
[[v window] setLevel:2003];
This works well, however there is a small delay before the second window is displayed. We can thus see for a very short time the first window.
I need that the second window stays on top of the first window, because the user can close the second window and must have access to the first window.
Any ideas on a trick how to hide the first window, just the time, the second window appears?
Thanks in advance
NSDisableScreenUpdates and NSEnableScreenUpdates (link) might be useful in this situation. The documentation says:
You typically call this function so that operations on multiple windows appear atomic to the user.
which seems to describe your situation.
A word of unrelated advice though: Don't go setting window levels willy-nilly. A window level of 2003 will likely cause the window to appear over things like the dock or even the menu bar, which would definitely be strange. You should stick to the standard levels declared in NSWindow.h unless you have good reason. NSFloatingWindowLevel might be appropriate (although I'm not sure what level the SFAuthorizationPluginView window is displayed at).
Starting with MacOS 10.4, you can use :
[NSWindow disableScreenUpdatesUntilFlush];