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.
Related
I am making a cross-platform windowing layer. When making window relationship stuffs, I got some trouble on window modality.
I have read the official spec: Application Window Properties, and some related topics like this: X11 modal dialog. It seems not sufficient to only set transient-for, but _NET_WM_STATE_MODAL is also required. So I tried to make small programs that apply this property along with transient-for.
I firstly made the program that create the window using SDL2, and use X11 stuffs using the fetched native window handle. But I did not observe any behavior change after the _NET_WM_STATE_MODAL attribute is set: the transient-for target window is still receiving mouse button events, which is not like a modal-blocked parent window that cannot operated by user.
To avoid potential evil stuffs done by SDL2, I further made the test program using GDK3, which provides ready-to-use wrapper functions. The behavior is same as the SDL2 program.
As I did not observed any change before/after _NET_WM_STATE_MODAL is set, what is the expected behavior of that property?
As I did not observed any change before/after _NET_WM_STATE_MODAL is set, what is the expected behavior of that property?
That's a question we cannot answer. It's a hint for the window manager to indicate modality, but, as in most cases, it is up to the window manager to decide what to do with this hint.
In other words behavior depends entirely upon the window manager and you haven't stated which window manager you were testing with.
Furthermore, this hint requires the window manager to be EWMH-compliant, which not all of them are or aren't fully. You can use _NET_SUPPORTED on the root window to see a list of atoms the window manager claims to support. If _NET_WM_STATE_MODAL isn't listed there, chances are the window manager really doesn't implement this hint at all. If it is listed, the window manager claims to support it, but a) it might be lying (let's not assume that, though) and b) behavior is up to the window manager.
I have recently upgraded from Delphi7 to Delphi XE5 and one of the differences that first jumped out at me is that by default, the IDE sets a forms default position to be in the top left corner of the screen instead of the center of the desktop like it was in D7 and I have looked all around in the options menu and have yet to find a way to set it so that when a new project is created, all forms default to be positioned in the center of the desktop and was hoping I was overlooked the option to do this or to confirm if it was not possible to set this option to be default.
I know there is the little box at the bottom right hand side of the form designer pane which allows you to move the form around so it is placed anywhere on the screen and of course you can set it to be in the center of the screen using the object inspector, but if I could set it to default to this position by "setting and forgetting" an option in the IDE, than that would be one less thing I need to bother with when starting a new project.
Anyway, any help would be appreciated and thanks in advance for any and all replies.
I figured it out myself in a roundabout way. It does not answer the question to the exact specifications that it was asked in but it works out close enough for my needs. The trick was to set the (now hidden) "Embedded Menu Designer" option to FALSE in the registry which causes the form to float independent of the rest of the IDE like it used to in Delphi 7.
Why this option was hidden from the options panel in Delphi XE3 and above is beyond me, but at least there is a way to get it back to the classic look I was after.
Source: http://theroadtodelphi.wordpress.com/2012/09/04/disabling-the-embedded-designer-in-rad-studio-xe3/
Note: The article talks about XE3, but the same technique applies to other Delphi versions as well. All that needs to be changed is the version number in the registry branch needs to match the version of Delphi that is being using. Everything else remains the same.
Isn't poDesktopCenter (TForm.Position property) enough? You set it in design time and forget about this.
I don't know what will happen if you have 1500x1200 form and the screen resolition is 800x600 - try it youself :)
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.
I need to draw a few small undecorated windows on top of another app's window. Each of these windows contains just a short label. It works fine but the windows are too big for my purpose. It seems as if Windows doesn't allow smaller than 104 x 27 toplevel windows, I might be wrong. I haven't tested on another backends. I'd like to shrink them to just the size needed to display the label. Is there a way to accomplish this?
Trying out things, I figured that setting the type hint with gtk_window_set_type_hint to GDK_WINDOW_TYPE_HINT_UTILITY allows the window to shrink horizontally but not vertically. I'm not sure what other implications this has. But it didn't solve the problem anyway.
I'm looking for a portable solution but platform-dependand answers are welcome too. Any help appreciated.
Edit: As usual, the solution is trivial. I had completely forgotten the GTK_WINDOW_POPUP window type.
Edit: Making the window GTK_WINDOW_POPUP has some unfortunate side effects which make it unusable for my purpose. I eventually got GTK_WINDOW_TOPLEVEL to work as expected. The key was to do gtk_window_set_resizable(window, FALSE) after the the window has been exposed.
Use gtk_window_set_resizable, this affects user resizes, which apparently includes resizes requested by the window manager. Setting it to FALSE therefore makes the programmatic value stick.
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.