Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement some window properties for x11 shell #1785

Merged
merged 6 commits into from
Jun 14, 2021

Conversation

maan2003
Copy link
Collaborator

Implements:

  • set_size
  • get_size
  • set_min_size
  • resizable
  • get_position
  • set_position
  • set_level
  • set_window_state (only for WindowBuilder)

druid-shell/src/platform/x11/window.rs Outdated Show resolved Hide resolved
druid-shell/src/platform/x11/window.rs Outdated Show resolved Hide resolved
@maan2003
Copy link
Collaborator Author

Also, dropdown example from nursery is now functional on x11 backend.

@maan2003 maan2003 added the S-waiting-on-author waits for changes from the submitter label May 19, 2021
@maan2003 maan2003 added S-needs-review waits for review and removed S-waiting-on-author waits for changes from the submitter labels May 20, 2021
Copy link
Contributor

@psychon psychon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just received a notification due to jneem's comments and apparently I have an old, unsubmitted review laying around... huh?

druid-shell/src/platform/x11/window.rs Show resolved Hide resolved
druid-shell/src/platform/x11/window.rs Show resolved Hide resolved
if let WindowLevel::DropDown = level {
log_x11!(conn.change_window_attributes(
self.id,
&ChangeWindowAttributesAux::new().override_redirect(1),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm. Making a window override-redirect after it is already shown sounds like a bad idea.

Can you somehow make this only work before the window is mapped? However, no idea how to do easily do so...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we remove the window-level-changing methods from WindowHandle and only allow them on WindowBuilder? Is there a use case on any platform for changing a WindowLevel after the window was created?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like gtk backend is also doing this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, you are right. Gtk really does this: https://github.com/GNOME/gtk/blob/77f32a69c0a35ffd3a1a542a6057c1c6d13c793d/gdk/x11/gdkwindow-x11.c#L3534-L3553

Still seems like a really bad idea to me. If the WM already reparented the window, the resulting state will not work properly. You can move and resize your window insides of the WM's container window, but the container itself is not affected / does not follow...

@jneem
Copy link
Collaborator

jneem commented Jun 12, 2021

Thanks! I was actually wondering if we need WindowHandle::set_level on any platform, but I'll open another issue for that.

@maan2003
Copy link
Collaborator Author

either set_position or get_position is not correct. When using dropdown example from nursery on a window manager with a top bar. the drop down is not positioned correctly. Zulip discussion

image

@psychon
Copy link
Contributor

psychon commented Jun 12, 2021

Well, since you are not assigning a window gravity (and IMO you should not), the functions might not really do exactly what you expect. The ConfigureRequest generated by set_position will be interpreted by the WM to be the position for the top left corner of the frame window (Edit: This is NorthWestGravity which is the default window gravity according to ICCCM, I think). The implementation for get_position however calculates the position of the top left corner of your child window.

Both positions are correct, they just do not "do the same thing". Which one is correct depends on the exact definition of these method (and I guess is not really defined).

Edit: Never mind, I am now confused by _get_position

Edit: My new guess is that the positions returns is off by two times the size of the window decoration. One of these comes from my comment in get_geometry and the other time due to window gravity. I guess you also need to implement handling of _NET_FRAME_EXTENTS from EWMH and hope that the WM supports that (check _NET_SUPPORTED on the root window).

let geom = conn.get_geometry(window.id)?.reply()?;
let cord = conn
.translate_coordinates(window.id, geom.root, geom.x, geom.y)?
.reply()?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the above be translate_coordinates(window.id, geom.root, 0, 0)? You want to know which coordinates the point (0,0) in your window has in the root window. As written, this function figures out the position of the window inside of its parent window (which will be the size of the top/left window decorations in a reparenting WM) and then translates this to the root window.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks :)

@maan2003
Copy link
Collaborator Author

maan2003 commented Jun 13, 2021

translate_coordinates(window.id, geom.root, 0, 0) fixes it for gnome and xmonad( with top bar). Not sure if _NET_FRAME_EXTENTS will be required

@psychon
Copy link
Contributor

psychon commented Jun 13, 2021

_NET_FRAME_EXTENTS does not appear in https://github.com/xmonad/xmonad, so I guess it is unsupported. And the open issues seem to suggest that xmonad does not implement ICCCM's window gravities anyway, but I guess a tiling WM can get away with that easily...

No idea if it is possible with xmonad for a window to request to be floating, but I would expect that a floating window requesting position (0,0) will end up with its window decorations off-screen. :-(

@maan2003
Copy link
Collaborator Author

working with gnome, kde, lxde, xmonad

gnome

Screenshot from 2021-06-13 10-02-25

kde

kde

lxde

lxde

xmonad

xmonad+topbar

@maan2003 maan2003 merged commit d2e46e6 into linebender:master Jun 14, 2021
@xStrom xStrom removed the S-needs-review waits for review label May 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants