I have a full-screen window (winA) and another window (winB) which is always on top.
Now I need to let winB display above winA, while winA is still above any other windows.
How to do this in GTK+? Thanks. (Maybe this needs Xlib?)
PS1: I won't use POPUP windows because it will put all the windows under it. I just need put winB on winA but not all the others. For example, if I am watching videos in the fullscreen mode, I wouldn't like to see winB. But if winA it's here, winB is just above it.
PS2: winA & winB are in the same program. In this case, it may simplify the solution.
The main way to tell the window manager to keep winB above winA is through the "transient for" hint, set in GTK+ with gtk_window_set_transient_for().
If your window is not a dialog, the behavior may not come out quite how you'd like; you could try setting a semantic hint with gtk_window_set_type_hint() and see if that gets you anywhere.
But the behavior is basically going to vary with window manager (which is intended). So you kind of need to just live with that and assume people will use a WM that works how they want it to.
Related
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
Background
I have a Gtk application running on a custom Linux distribution (based on Yocto running Waland/Weston). The application is developed on Ubuntu 20 which has both X11 backend and Wayland backend. The child dialogs or windows that are spawned by the main window are perfectly centered on the main window (in Ubuntu on both backends). However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Different Approach?
With what ever little I know I tried Gtk::Window::move, Gdk::Window::move and even dared to play with Wayland surfaces (gdk_wayland_window_set_transient_for_exported ) but with no avail.
That left me wondering how the user is able to move such child windows by grabbing the header bar (or title bar as Gtk::Window calls it) even under Weston. If I get to know how this works then perhaps I can emulate a grab-drag to position the window where ever I want.
I tried sifting through gtkwindow.c to find out what happens when one sets the title bar using the function gtk_window_set_titlebar but the rabbit hole went a little too deep.
It would be great if someone can point me in the right direction, at least quote some functions whose implementation I can study to get this working....
Your question consists of multiple smaller ones, so I'll try to give a shot at answering each and one of them.
The general idea is that Wayland is quite minimal, so to make it suitable for desktop use cases, you need a protocol extension. This extension is called XDG Shell.
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
This first part is described in the Wayland book, but the idea is that you forward an input event (usually a drag) back to the compositor, who will know what do with it. That might mean moving the window (or not moving it, if you've reached the edge of the screen.
However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Note that your confusing 2 questions here: one is where to put a child window, compared to a parent window, while the second sentence here talks about position any toplevel window. There is also a section in the Wayland book on popups (part of XDG shell also) which also describe something similar.
So whether you can arbitrarily move windows: the answer is no.
The most important question then becomes: what can you do to solve your problems with Weston? It's hard to say without any kind of code. You might want to make sure you set the GtkDialog parent when constructing it (also known as the transient_for property. You might want to play around with the modal flag also. There might be other options too, but it's a bit of a blind guess.
Is it possible to toolbar only when certain modes are used for the current buffer?
What I am aiming at is have the toolbar only active when gdb-gud or newsticker are running,
so that a quick interaction with it is possible. As soon as e.g. newsticker is closed, the toolbar-mode should be disabled.
Is there a general way to achieve this behavior, or do I have to write something myself?
tool-bar-mode is a global mode. You can of course turn it on or off on a mode hook, but it affects all buffers in all frames.
As #legoscia mentioned, you can make the tool bar frame-specific. tool-bar-here-mode makes this easier (togglable). It is in library tool-bar+.el
I don't think you can easily limit use of the tool bar to a particular mode.
However, you can make showing the tool bar be on-demand when you click Buttons in the menu bar. This saves screen real estate: Show the tool bar temporarily, for the space of a single use.
This is available with tool-bar-popup-mode, which is also in library tool-bar+.el.
Screenshots and description.
I've searched for solutions in many forums but they all tell me that usign the WindowPattern and checkign the topmost value should return true if the window is on top. However, this isn't the case for me. I am testing an application that is housed within a tab in outlok. A user can then click within the application and open a new window. I'd like to verify this window is in the foreground. Also.. this is a WPF application so I cant grab separate handles for new windows that open.
thanks
This might be a terminology problem: 'Topmost' has a special meaning in Win32 (See description of WS_EX_TOPMOST here), which basically means "floats above other ordinary windows" - it's typically used for things like tooltips, menu popups, notification balloons and the like, which float above all other windows on the screen. It's rarely by actual application windows.
An application can be the currently foreground window, above other windows, but not have this property.
An alternate approach to see if the window is in the foreground is to see if it is or contains the contains the current focus or active window.
I spend a lot of my time in emacs, and for the most part it's wonderful. But one thing really drives me nuts when I'm deep in it, and that's control over which window various new buffers are opened in. When I do find-file, it always opens in the current window, and this is what I like. But tons of other modes like to split my windows for me, change the layout, and do various other things that annoy me. For example running M-x manual-entry seems to have no rhyme or reason about where it opens the manpage, and various org-mode commands do the same thing, closing windows I want to keep open, etc. I don't like having to redo my layout everytime I want to look at my org agenda or open a manpage.
In short, is there anyway to globally control which windows are used for modes that want to open in a window other than the current one? Can I direct them more easily? Or will I have to hack each mode to act the way I want it to?
Try Winner mode:
http://www.emacswiki.org/emacs/WinnerMode
It provides an undo/redo for changes to the window configuration.
This question has always bugged me too. I found this:
http://www.gnu.org/software/emacs/elisp/html_node/Choosing-Window.html
It looks like you can use (setf pop-up-frames t) to make stuff show up in a new frame.
Also, it looks like you can use display-buffer-function to override the display function (how buffers are chosen.) Of course, you'd have to be good at elisp.
I'm involved in a project that is attempting to use the Eclipse RCP splash screen to gather user credentials, language, etc. If this screen loses focus, it is not available (under Windows at least) through the ALt-Tab functionality, and can only be found by minimizing all other windows and uncovering it. Any way of having this screen allow itself to be activated in this way? They're avoiding creating an intermediate screen, for reasons unknown at this point.
I think it might be time to examine those unknown reasons. Even eclipse doesn't use the splash screen in this way. If it needs to prompt for information, it opens a new dialog to ask for it.
Good luck.
[Edit] I stand corrected. This thread seems to have a solution to this. Good luck, I'm no SWT/RCP guru.
See this page. From one of the comments:
The splash screen window is created natively with the extended window style WS_EX_TOOLWINDOW which makes it not appear in the task bar. This corresponds to the SWT constant SWT.TOOL.
I don't know if it's possible to change the window style after it is created on Windows. You can always drop down to JNI if that's necessary.
Create your own implementation of AbstractSplashHandler.
When creating the shell, don't use the SWT.TOOL style.
The shell will be accessible through the windows task bar.