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

The reference point of a window should include the window decorations but it does not. #5953

Open
2 tasks done
LevitatingBusinessMan opened this issue Mar 15, 2024 · 5 comments
Labels
4.23 bug missing-log Read the CONTRIBUTING.md file for instructions

Comments

@LevitatingBusinessMan
Copy link

LevitatingBusinessMan commented Mar 15, 2024

Welcome

  • Yes, I'm using the latest major release or the current development version. These are the only supported versions.
  • Yes, I've searched similar issues and discussions on GitHub and didn't find any.

Current Behavior

When moving a window to 0,0 I get this:
image

Expected Behavior

image

Reproduction Instructions

Assuming that you are not using a dual monitor setup (0,0 actually being the topleft) this will create a window with gtk and move it to 0,0

#include <gtk/gtk.h>

int main(int argc, char** argv) {
  gtk_init(&argc, &argv);
  GtkWidget* window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  gtk_window_set_type_hint (GTK_WINDOW (window), GDK_WINDOW_TYPE_HINT_UTILITY);
  GtkWidget* label = gtk_label_new ("This is my label");
  gtk_container_add (GTK_CONTAINER (window), label);
  gtk_widget_show_all (window);
  gtk_window_move (GTK_WINDOW (window), 0,0);
  gtk_main();
  return 0;
}

This behavior, deciding on the reference point of the window should be controlled with gravity1. So implementing gravities could solve this problem.

With no proper/easy way to get the size of the window decorations, this bug makes it extremely hard to place a window at an exact offset from the screen borders.

I think this is a duplicate of #1341 but you wanted me to file a new bug report.
That issue was closed with #3184, but I think the bug has resurfaced or the PR didn't fix the issue.

i3 version

Binary i3 version:  4.23 (2023-10-29) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.23 (2023-10-29) (pid 14541)
Loaded i3 config:
  /home/rein/.config/i3/config (main) (last modified: Wed 03 Jan 2024 12:59:17 AM CET, 6288274 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

Config file

This happens with default configuration.

Linux distribution & Version

ArchLinux

Are you using a compositor?

picom

Logfile

No response

@i3bot
Copy link

i3bot commented Mar 15, 2024

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

@i3bot i3bot added missing-log Read the CONTRIBUTING.md file for instructions 4.23 labels Mar 15, 2024
@LevitatingBusinessMan
Copy link
Author

The proper way to fix this bug would be to tackle gravities (#1335). Or completely comply with wm-spec1. But just changing the reference point should suffice with this specific bug.

@orestisfl
Copy link
Member

#1341 was specifically about this:

i3 calculates that the left-top corner of the frame would be at (0, -9) and decides to resort to putting it at the center of the screen.

not about respecting gravity hints.

As about this ticket, I don't see why i3 "must" default to north-west gravity instead of static. I agree it's more user-friendly behavior but I don't see why the current behavior is an i3 bug.

@LevitatingBusinessMan
Copy link
Author

LevitatingBusinessMan commented Mar 16, 2024

#1341 was specifically about this:

i3 calculates that the left-top corner of the frame would be at (0, -9) and decides to resort to putting it at the center of the screen.

Ah I see, though the root cause for that is still that applications are confused by the default gravity of i3 right?

The NorhWestGravity really is meant to be the default, and this is what applications expect. From the GTK3 docs1:

The default window gravity is #GDK_GRAVITY_NORTH_WEST which will typically “do what you mean.”

If i3 doesn't like this behavior and instead wants to default to STATIC gravity that is fine, but then I think it definitely should respect gravity hints. Otherwise an application cannot correctly control its position.

If I currently want to write an application that spawns a floating window at an offset from the screen, it seems like I would have to set the gravity hint, but then also a special clause where the user is using i3wm, and then detect the size change when reparenting the window so I can detect the size of the titlebar and work that in. But like stapelberg said:

I don’t think the actual application should ever be interested in the height of the title bar.

@LevitatingBusinessMan
Copy link
Author

My reasoning is that I am trying to spawn windows that serve as notifications. Thus I want them to float and appear in a specific corner. I preferably want to keep i3's decorations on them, but as you can imagine this has turned into a hassle due to the static gravity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4.23 bug missing-log Read the CONTRIBUTING.md file for instructions
Projects
None yet
Development

No branches or pull requests

3 participants