I currently use FPClickToFocus, FPClickDecorToFocus, FPClickIconToFocus, FPGrabFocusTransient for the window style. But the Problem is the Window loses Focus when mouse leave it and give the focus to the window it is in;
So which Style(s) give the normal fill and look in this specific matter; like other WMs openbox, gnome ... (i.e click in the window or on its titlebar; gives it focus and bring it on top)
Using this below Style(look down) only changes and brings window to the front but the Focus (the window that action happens in i.e i can type in) doesn't change.
It means I change a window but my cursor is still in my geany and i am typing a web-site URL in geany while the firefox is in front and nothing happening in its addressbar For Example.
#-----------------------------------------------------------------------
# The focus policy. Once you are used to clicking *inside* windows to
# raise them you will not want to lose this feature.
#-----------------------------------------------------------------------
Style * ClickToFocus
Style * MouseFocusClickRaises
Related
Whenever I open a new labview project, it opens two small windows, one for the block diagram and the front panel. Since using labview effectively requires simultaneous use of both, is it possible to set things up such that, upon starting a new VI, it opens these two windows in pre-determined positions and sizes?
I do not know setting to do so (and think there is no such setting), but your problem is easily solvable if you press ctrl+t when new vi is opened.
ctrl+t will set front panel on the left half part of the screen and block diagram on the right part. Pressing ctrl+t a second time will set the panel to top half and diagram to the bottom half.
Shortcuts In LabVIEW
Another workaround:
Create a new empty VI
Resize and reposition the front panel window as you wish
Do the same for the block diagram window
Save the VI as a template (.vit)
Double click the template to use it (position and size of windows will be as they were when saving)
Alternatively if you want to be doing manually everytime. You can press WIN+LEFT on one of the windows and WIN+RIGHT on the other. This will evenly distribute the two windows over the screen.
You can set window position for individual VIs by pressing Ctrl+I to open the VI properties, and setting the desired appearance under "Window Size"
I would like to draw some sort of window on top of all the other windows. For example, to display some debugging infos (like conky) or things like a timer.
The main thing is that I would like to able to continue using the other windows while using it (the events go through transparently).
I've tried doing it with pygtk, pyqt and others but can't find a way to make it a real overlay with no event capture.
Is there some low-level x11 solution?
I think the Composite-extension-approach will not work when a compositing manager is running (and thus Composite's overlay window is already used).
Since you explicitly mention "no event capture":
The SHAPE extension allows to set some different shapes for a window. Version 1.1 of this extension added the "input" shape. Just setting this to an empty region should pretty much do what you want.
Some concrete example of exactly what I think you ask for can be found in Conky's source code: http://sources.debian.net/src/conky/1.10.3-1/src/x11.cc/?hl=769#L764-L781
Edit: Since you said that you didn't find anything in Gtk (well, PyGtk), here is the function that you need in Gtk: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-input-shape-combine-region
You might need Composite extension + GetOverlayWindow request:
Version 0.3 of the protocol adds the Composite Overlay Window, which
provides compositing managers with a surface on which to draw without
interference. This window is always above normal windows and is always
below the screen saver window. It is an InputOutput window whose width
and height are the screen dimensions. Its visual is the root visual
and its border width is zero. Attempts to redirect it using the
composite extension are ignored. This window does not appear in the
reply of the QueryTree request. It is also an override redirect
window. These last two features make it invisible to window managers
and other X11 clients. The only way to access the XID of this window
is via the CompositeGetOverlayWindow request. Initially, the Composite
Overlay Window is unmapped.
CompositeGetOverlayWindow returns the XID of the Composite Overlay
Window. If the window has not yet been mapped, it is mapped by this
request. When all clients who have called this request have terminated
their X11 connections the window is unmapped.
Composite managers may render directly to the Composite Overlay
Window, or they may reparent other windows to be children of this
window and render to these. Multiple clients may render to the
Composite Overlay Window, create child windows of it, reshape it, and
redefine its input region, but the specific arbitration rules followed
by these clients is not defined by this specification; these policies
should be defined by the clients themselves.
C api : XCompositeGetOverlayWindow
PyGTK Solution:
I think the composite and shapes X extensions are sufficiently ubiquitous and shall assume here that they are active on your system. Here's PyGtk code for this:
# avoid title bar and standard window minimize, maximize, close buttons
win.set_decorated(False)
# make the window stick above all others (super button will still override it in the z-order, which is fine)
win.set_keep_above(True)
# make events pass through
region = cairo.Region(cairo.RectangleInt(0, 0, 0, 0))
my_window.input_shape_combine_region(region)
win.show_all()
# set the entire window to be semi-transparent, if we like
win.set_opacity(0.2)
Basically what this does is tell Gtk that other than pixel (0,0) the entire window my_window should not be considered part of itself in terms of event propagation. That in turn, according to my current understanding means that when the pointer moves and clicks, the events go to the underlying window under the pointer position, as if my_window was not there.
Caveat:
This does allow your overlay window being the focus window (due to user-solicited window switching or just because it pops up and gets the focus when your application starts). Which means that for example, keyboard events will still undesirably go to it up until the user has clicked through it to make it lose focus in favor of whatever window is under the cursor. I would likely use the approach described here to iron out this aspect.
If there's a different and proper approach for making a portion of the screen "display stuff but not receive events", without building an oddball window like above over it, I'm happy to learn about it.
I assume that one's particular desktop environment (gnome, unity, etc. on linux) may interfere with this solution depending on version and configuration, on some occasions.
Is there a way when documentation popup on AS to not hide immediately after it is showed by moving mouse on some class. What I mean. I move mouse cursor above Activity class and documentation is popup is showed, but when I try to move mouse above this popup (because I have to scroll it) it disappears. I can hold ctrl and then is will not hide, but if I press on it while holdint ctrl down it will disappear (so I should move cursor above it, release ctrl and after that to start scrolling). So is there an option to change this behaviour to be like in eclipse - documentation pop up is showed and if you move mouse above it you can scroll, otherwise it is closed.
There are a lot of bugs surrounding this UI element. I'm currently having the opposite problem where it won't go away unless I manually close it. I suspect in your case, a timeout is triggering too early, or some other event is erroneously hiding the window.
This workaround may be helpful. You can explicitly pop the documentation window from the View > Tool Windows > Documentation menu option. This will cause the tool window tab to appear on the right gutter by default. Right-clicking on the Documentation tab will pop up a menu that will allow you to pin the window, or dock it permanently in the UI by disabling "Floating Mode" and optionally moving it to the other side or the bottom.
Windows get focus is meaning that you can type in something in that. But at the same time, I hope that windows not to cover some others. How to config gnome 3 to implement that?
Leaving a window in focus though not on top of the screen is quite easy in Gnome. It is possible to give each and every window a special attribut which will shift their priority on the screen.
First, right click the titlebar of the application which should always be on top. A small menu should pop up. Now just select the option "Always on top" and you are done. This option may be parsed to multiple windows. Independently of which window is in focus, the application with this attribute will always cover it.
By the way the so called "Titlebar Actions" can be configured through the gnome-tweak-tool. Under the "Windows" tab you may define what should happen on a double click, a middle click or a secondary/right-mouse click.
I have a MFC dialog based application. User can change the language of the dialog, and I made this by closing existing dialog, and opening another with changed language. The problem is that the effect in the taskbar is that one icon is removed, and another identical is created in its place. If my application's icon is not the last icon in the task bar it will be perceived as it was moved to the end of taskbar icon set.
I want to retain icon's position in the taskbar, and rather to prevent icon flicker at all from happening. How do I do that?
The application must support OS'es from Windows XP to Windows 7.
EDIT: alternative question for which I would accept an answer is how to create an invisible window that is nevertheless shown in the taskbar, and how to forward relevant window messages from that window to my main window?
Make the dialog a child of another outer parent window. The parent can be a dialog or any other kind of window; all it will be providing is the title bar. If the user tries to resize it it will have to forward resizing commands to the dialog, but otherwise you shouldn't need to do much in the parent window.
Why not replace the dialog with a CFormView instead? That way there's a frame window that wraps around the dialog (which is embedded in a form view) and it's the frame window that owns the taskbar icon.
Create an SDI application that displays a CFormView. Display the dialog in the default language (or whatever langauge the user previously chose) on initialization. When the user chooses the 'change language' option, simply change the form view that's being displayed with a new one.
Bonus feature: with this design, the framework will take care of things like language-specific accelerators and menus for you with no effort on your part.
For more on how to do this, check out http://www.codeguru.com/cpp/w-d/doc_view/viewmanagement/article.php/c3341/Multiple-Views-Using-SDI.htm