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

Improvements for static windows #3243

Open
5 tasks
m-col opened this issue Jan 24, 2022 · 9 comments
Open
5 tasks

Improvements for static windows #3243

m-col opened this issue Jan 24, 2022 · 9 comments

Comments

@m-col
Copy link
Member

m-col commented Jan 24, 2022

The Static class is a bit half baked and could do with some love. Here are some improvements that would be good to have:

  • Let static windows be qtile.current_window: allows for exposing Static commands, simpler focus logic.
  • Add a command to un-static and make the window floating.
  • When making the currently focussed window static, keep focus on that window (this affects the wayland backend, unsure about the x11 backend)
  • When executing cmd_static on a window before the client_managed hook, still let it grab focus.
  • Add a config option to set their borders, or perhaps let borders be passed to cmd_static?

Any other improvements that would make these more usable?

If anybody wants to work on these then that's amazing, if not, I will get round to it at some point.

@m-col
Copy link
Member Author

m-col commented Jan 24, 2022

We may be able to actually drop the Static class altogether and just have a flag that tells the floating layout that a window is static.

@m-col
Copy link
Member Author

m-col commented Jan 24, 2022

Thinking on this some more, there are two use cases for Static that ought to be distinguished:

  • Permanently static clients, such as third party bars and panels. Having a separate class is helpful in this case by isolating these clients from all of the group, layout and focus logic, as well as the IPC interfaces (lazy.window shouldn't be a panel). Importantly these do not ever need to be made un-static, so no new commands need to be added to Static.
  • On-demand static clients, which are regular windows that the user wanted to stick to the screen. In this case it might be easier to build and to use if we just add this functionality to the regular Window class. I suspect this makes it very easy: the FloatStates in backend.base enumerates possible floating states, and we can just append 'static' as a new state. Then we can add cmd_{enable,disable,toggle}_static just like we have for maximize, floating etc. Floating would then handle not unmapping and mapping as the group changes... or perhaps keep them on Qtile directly if that's easier.

It might be worth thinking about what to name these two things, so that we don't have to refer to both as 'static' which will be confusing. e.g. we could rename Static to Docked or something, or call the second case above 'sticky' instead of 'static'.

If anybody has any feedback or comments on this, I'd love to hear it.

@elParaguayo
Copy link
Member

Definitely worth distinguishing those two use cases.

I'm not sure I totally follow that you're saying in the last sentence of your second bullet though.

As for names, I prefer Docked and Static over Static and Sticky.

@elParaguayo
Copy link
Member

I do want to get our website done but would be happy to take a look at this if you haven't already started by then.

@m-col
Copy link
Member Author

m-col commented Jan 26, 2022

Awesome, I haven't started on this beyond the thoughts above.

@deivi98
Copy link

deivi98 commented Mar 20, 2022

Hi there, setting a Window to 'static' mode has helped me to have an awesome way to stick windows, but I'm having trouble when trying to disable static mode. The window gets buggy and the only way to fix it is restarting Qtile. Any updates on this?

@elParaguayo
Copy link
Member

I've not got round to looking at this yet...

@justinesmithies
Copy link

Thinking on this some more, there are two use cases for Static that ought to be distinguished:

  • Permanently static clients, such as third party bars and panels. Having a separate class is helpful in this case by isolating these clients from all of the group, layout and focus logic, as well as the IPC interfaces (lazy.window shouldn't be a panel). Importantly these do not ever need to be made un-static, so no new commands need to be added to Static.
  • On-demand static clients, which are regular windows that the user wanted to stick to the screen. In this case it might be easier to build and to use if we just add this functionality to the regular Window class. I suspect this makes it very easy: the FloatStates in backend.base enumerates possible floating states, and we can just append 'static' as a new state. Then we can add cmd_{enable,disable,toggle}_static just like we have for maximize, floating etc. Floating would then handle not unmapping and mapping as the group changes... or perhaps keep them on Qtile directly if that's easier.

It might be worth thinking about what to name these two things, so that we don't have to refer to both as 'static' which will be confusing. e.g. we could rename Static to Docked or something, or call the second case above 'sticky' instead of 'static'.

If anybody has any feedback or comments on this, I'd love to hear it.

Would love to see sticky windows added to Qtile as in option two described above. This would be really useful for when I for example have mpv open at a set size / location and and floating. Being able to pin it ( sticky ) to an output would be perfect.

@lulivi
Copy link
Contributor

lulivi commented Dec 29, 2023

After reading the discussion #3221 and seen that there is no way of making a Static window a (normal) Window again. I tried to add it to a group and it seems to be missing some parts. In the following code I search for static windows under the mouse. If there are no static windows, I make the qtile.current_window static. When there is a static window I try to make it normal again:

@lazy.function
def toggle_window_static(qtile: Qtile) -> None:

    def _window_contains_mouse(window: WindowType, mouse_position: Tuple[int, int]) -> bool:
        return (
            window.x <= mouse_position[0]
            and mouse_position[0] <= window.x + window.height
            and window.y <= mouse_position[1]
            and mouse_position[1] <= window.y + window.width
        )

    current_mouse_position = qtile.core.get_mouse_position()
    static_windows: List[Static] = [
        window
        for window in qtile.windows_map.values()
        if isinstance(window, Static) and _window_contains_mouse(window, current_mouse_position)
    ]

    if not static_windows:
        send_notification(
            f"The window {qtile.current_window.name} is now sticky to the screen", ""
        )
        qtile.current_window.static()
        return

    selected_static_window: Static

    if len(static_windows) > 1:
        # Select the static window to make normal
        pass

    selected_static_window = static_windows[0]
    send_notification(f"The window {selected_static_window.name} is back to normal", "")
    qtile.current_group.add(selected_static_window)

Error: AttributeError: <class 'libqtile.backend.x11.window.Static'> has no attribute floating

Is there any way of creating a x11.window.Window from the static one?

Maybe as a workaround I might be able to use the @hook.subscribe.setgroup hook in order to move that specific window to the current group with every change.

To finish this comment, I'm loving Qtile, great work team!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants