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

Raise on focus for tiled windows. #3676

Open
slole opened this Issue Apr 4, 2019 · 9 comments

Comments

Projects
None yet
3 participants
@slole
Copy link

commented Apr 4, 2019

I'm submitting a…

[ ] Bug
[x] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

When I hover my mouse above a non-floating window, the focus moves with it, however the window does not get raised.

Expected Behavior

When I hover my mouse above a non-floating window it should raise above other non-floating windows (all floating windows should stay on top, as is)

Explanation

I, like most people like floating windows not to raise above each other, however I would like for the tiled windows to raise above each other to make life easier when dealing with shadows (compton). This could be a new option for the config (something like "tiling-raise-on-focus" or similar).

Thank you any response.

@i3bot i3bot added the enhancement label Apr 4, 2019

@Airblader

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

Hi, thanks for opening an issue.

The stacking order of tiled windows doesn't matter for anything that I could think of other than what you mentioned. However, this seems to fall into an eye candy kind of category, which i3 is not really trying to enhance (technically we don't even support compositing, though it generally works fine). Adding an option for this would be incredibly technical and unjustified configuration complexity.

I'm not even sure how well this would work given the way i3 deals with titlebar rendering in split containers (which famously conflicts with compositor features such as transparency). For all of these reason I'll have to reject & close this request. Thanks for understanding!

@Airblader Airblader closed this Apr 5, 2019

@slole

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

Thanks for the response. Is there a way I could raise windows through the IPC interface?

@Airblader

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

No, the IPC doesn't allow that, sorry.

@slole

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

Is there any other way to do this or should I try to go into i3wm's source and make a custom fork?

@Airblader

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

You could try sending the necessary requests yourself, though I'm not sure how well that works as at the very least one problem would be that i3 overwrites it everytime it restacks.

Applying a local patch would probably be the safest way to go. The interesting code should be x_con_raise in src/x.c and in the same file you can search for stacking.

If you do come up with a patch feel free to post it here as a comment!

@slole

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

Thank you! I'll look into it.

@slole

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

I found a very easy solution! To achieve the desired effect all I had to do is ensure that the condition in line 132 of render.c is always true. This also keeps the desired behavior of floating windows!

My next step will be to add a command for the configuration that enables this behavior and extend the condition in the mentioned line to account for the configuration.

Also: after the initial impression nothing broke (tried floating windows, stacked and tabbed configurations and all worked). Is there any potential flaw or immediate red flags with my solution?

EDIT: typo

EDIT2: link:

i3/src/render.c

Lines 131 to 149 in 56bbc52

/* in a stacking or tabbed container, we ensure the focused client is raised */
if (con->layout == L_STACKED || con->layout == L_TABBED) {
TAILQ_FOREACH_REVERSE(child, &(con->focus_head), focus_head, focused)
x_raise_con(child);
if ((child = TAILQ_FIRST(&(con->focus_head)))) {
/* By rendering the stacked container again, we handle the case
* that we have a non-leaf-container inside the stack. In that
* case, the children of the non-leaf-container need to be
* raised as well. */
render_con(child);
}
if (params.children != 1)
/* Raise the stack con itself. This will put the stack
* decoration on top of every stack window. That way, when a
* new window is opened in the stack, the old window will not
* obscure part of the decoration (it’s unmapped afterwards). */
x_raise_con(con);
}

@Airblader

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

Is there any potential flaw or immediate red flags with my solution?

I'm not sure about ramifications, but it doesn't sound correct. I would think we want more something along the lines of

if (con == focused) {
    x_raise_con(con);
    render_con(con);
}

somewhere. Solving it in render.c is an interesting approach, for sure, though. If we can make it work with such a simple change we could also reconsider putting it directly into i3 as it wouldn't raise complexity as much as thought (this isn't a promise ;-) ). Let's maybe reopen for the moment.

@orestisf1993 What do you think?

@slole

This comment has been minimized.

Copy link
Author

commented Apr 6, 2019

That was actually my initial approach, however just x_raise_con(con); does not do the trick and adding render_con(con); just causes infinite recursive calls, before crashing with a stack overflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.