I want to minimize the main window of a C#/Eto app and switch to another program. But when a timer in the Eto app fires it opens a new window, which I want to see. It should be displayed on top of all other windows currently open. The focus may switch to that window, but it's ok if not.
Using BringToFront() of the Form class does not work.
What else could I do?
Due to the way Apple made OS X, you are unable to make a window go to the top with programming. On Windows it is different.
Good luck!
Related
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
I have Debian 2.6 running on a SBC that I plan on using in an embedded setup. What I need to do is configure it so that linux will start up and run just my Qt GUI application. Do I need a window manager to do this or can I just do it with X11. Also because it is going to be for an embedded system I do not want to load any desktop manager. Any info on how this can be done would be great!
Yes you can do this without a window manager.
first: You need to boot into a non X session, init level 1 or 3.
second: You need to start the X server, in a basic mode by just calling X or xinit.
third: Start your app. You may need to take a little more control over where your app is positioned on the screen and its dimensions in your code, as you will not have a window manager to help with this.
alternatively: you can launch one of the more basic window managers to see how they play with your system. Motif Window Manager (mwm) and Tab Window Manager (twm)
Note: While working without a window manager, you may get into a state where you cannot do some very basic operations (ex: close a window, move a window, resize a window). You may find that you cannot survive without at least some of the more basic window management functions. Until you close the loop on this, remember, Ctrl + Alt + Backspace will kill the XServer.
If you want to start your app just with X11, you need do:
copy file /etc/X11/xinit/xinitrc to ~/.xinitrc
write all you want to run to it
run command startx
It worked for me and I hope it will help you
i have a simple question,
i search the exact name of the window manager for Windows.
For Unix : X Window System
Mac : Quartz
Windows : ?
Thanks you.
In the sense of the linked article, Windows does not have a discrete window manager. The windowing system is responsible for drawing the windows, and "the shell" - typically explorer - is responsible for displaying a task bar and any icons on the desktop.
The appearance of a window manager however is an emergent property in Microsoft Windows: All windows have a WindowProc that handles messages - and all messages not handled by the application code must get passed to a function called DefWindowProc. DefWindowProc handles the clicks in the non client areas of the windows to perform the tasks typical of window managers - sizing, moving, maximizing and so on.
Because all window's WindowProcs get to choose how to handle messages, they can choose to not implement the typical window manager behaviors by handling the message them self and not calling DefWindowProc.
The taskbar - provided by explorer - provides buttons to manipulate windows but ultimately (a) Its just a regular window itself, and (b) It sends messages to the windows to get them to maximize, minimize, restore etc. themselves, so again, any particular window could choose to not act like the other windows.
DefWindowProc is implemented in user32.dll - so really that is the window manager.
It's got a really original name - It's called the "Desktop Window Manager". You can see they thought long and hard about how to get that one exactly right.
(This obviously had absolutely nothing to do with the Microsoft marketing department, otherwise it would have been called something crazy and unrelated like silverstuff or aero.)
Its called "Windows Explorer"
See http://en.wikipedia.org/wiki/Window_manager
The thing that does the drawing of lines and pixels on the screen has traditionally been GDI (gdi32.dll), or now WDDM (for Win7) - Windows Display Driver Model, which has another layert on top of that, DWM - Desktop Window Manager.
On top of all that, you have Aero and then Windows Explorer that display and manipulates windows.
Oh yes, I nearly forgot about Direct2D which is another rendering layer that fits in there somewhere. I suppose they'll come up with a final technology one day that'll form the basis of graphics and windowing for the next 25 years.
I have an application that sends the focus to other windows but those windows then don't automatically display themselves in the foreground, i.e. on top of all the other windows. Where can I configure the preferences of my window manager so that this is the default behaviour?
In particular I'm using the Ctrl-0 and Ctrl-Shft-0 shortcuts in the MATLAB IDE to move between the command window and the editor window and although the focus seems to be transferred the new window doesn't automatically redraw itself in the foreground.
Not sure of a key binding off hand that does it, but if you alt-click on a window (which allows you to drag a window) it should come to the front.
As codeDr suggests, MATLAB is also kind of bad about repainting its windows. If you draw to a figure while code is executing, the figure does not update unless you execute drawnow or have some similar pause in the execution to allow the GUI to repaint. Since we're talking about MATLAB, the figure command will also cause the indicated figure to come to the front (in fact, it's harder to get it to not come to the front). So you could do figure(gcf) to bring the current figure to the front, or save the figure number with h = figure; and then later do figure(h). Incidentally, if you want to switch current figures without switching focus, set(0, 'CurrentFigure', h) should set h to the current figure.
Your window manager (probably Metacity?) implements focus-stealing prevention so that rogue apps don't pop up windows that would disturb your typing. Matlab needs to raise its window, and give it the input focus with the correct timestamp. If this is being done from a KeyPress event handler, the timestamp for setting the input focus would be the timestamp from the KeyPress event (i.e. the timestamp of the user-generated event that caused a window to be raised/focused).
To politely give the input focus to a window, google for _NET_ACTIVE_WINDOW.
Usually when the window doesn't repaint, it means that the application's main application loop isn't running to refresh the window. Could it be that Matlab is doing some computation or disk activity when you are switching between windows?
I am working on old Motif-based application for Linux. I want to be able to programmatically change the active window of our application. I can redirect the input by using XSetInputFocus() function and the keyboard input start to go there, but XReconfigureWMWindow() and XRaiseWindow() functions just don't work.
I've read that Window Managers try to stop this behaviour, so tried to disable configure redirection, but this doesn't work either. Any ideas how to make one of my own windows on top of the window stack?
There is a tiny program called wmctrl available (at least in Debian/Ubuntu it is in standard distribution) which is able to perform many operations on windows and desktops, and handles plenty of window managers. I'd suggest testing whether it works in your environment, and if so, peeking at its sources.
You may find the answer to this is dependent on the Window Manager the user is using, or even what settings they've given to the Window Manager. I like to set my Window Managers to do "focus follows mouse", which means you can't send the focus to a window that I haven't put my mouse on, unless you also warp the mouse there (is that function called XWarpMouse?).