How to modify a window based on its role

[lyndhurst]

Hi,

I am trying to control the gtk file chooser spawned by some of the application I use because it starts up partly outside of the screen and a bit oversized to my taste. I would like to use its role to transform it using methods like center() or set_floating_size()

To be honest I never understood how to use the 'Rule' object described in the doc and I have not found any example of it. I use Match in the float_rules list of the 'Floating' layout but they come with default_float_rules that work pretty well, so I do not want to mess with that. This part, I simply copied from other configs I checked out, and added my own Match rules.

Since I have been using qtile for weeks now, and I am enjoying it a lot, I'd like to understand this part better.

So the window I am interested in has the GtkFileChooserDialog role, but the name varies depending on the context and application. I added this role to my floating rules, and it works, but unlike other floating windows I have, the placing and sizing does not improve by just floating it.

All I know how to use for that purpose would be client_new or client_managed hooks, but to my knowledge I can only pass the client object as an argument to my function, and it only gives me access to the name. Adding a if statement to each and every name I come across feels redundant when I have a (so far) constant window role.

Beyond that I found the group_window_add that could give me access to windows properties, but I had no luck using it.

Thanks in advance for any help understanding better how this works.

[elParaguayo]

The client_managed hook is probably the way to go here.

However, there is a misunderstanding in your post: the client object gives you much more than just the name and you can access the role.

You should therefore be able to do something like:

@hook.subscribe.client_managed
def resize_dialog(client):
    if client.get_wm_role() != "GtkFileChooserDialog":
        return

    client.set_size_floating(new_width, new_height)

[lyndhurst]

Yes, it was quite a misunderstanding on my part. I did not realize I could retrieve information about the window this way. Thanks a lot, it works 👍

[elParaguayo]

Excellent. Glad it's working. Have fun and come back with any other questions you may have.

[lyndhurst]

@elParaguayo Thanks as usual for your support. I am actually back already, because when I answered you before, I thought I overlooked the get_wm_role method when looking at the Window documentation page where I got the set_size_floating one. So I went back to the page, and I cannot find it.

Is it an omission in this otherwise quite extensive doc, or is it another misunderstanding on my part that I am not interacting with a Window object when using client ?

[elParaguayo]

This is a much more common misunderstanding. The commands listed in the Window documentation (https://docs.qtile.org/en/stable/manual/commands/api/windows.html) are the commands that are available via the public API which means they can be accessed via qtile's command interface (e.g. lazy.window...).

The client object you get via the hook is the instance of the python object representing that window. This means you have access to all the internals of that object, including methods like get_wm_role. This isn't included in our docs as we may need to change some of these methods in the future. However, you can find all the methods by looking at the source code.

[lyndhurst]

Thanks for the clarification, the similar naming for some of the methods got me confused I guess. I bookmark that new info in my notes, and hopefully, next time I am trying to go overboard with my window tinkering, I ll think of looking at the source code, I am sure there is a wealth of tools there that can be pretty helpful ! Thanks again.

[elParaguayo]

Where the names are the same, it's because they are the same functions. All the "public" commands are methods of the relevant python objects. The names were different in earlier versions of qtile but we changed this to reduce confusion.

[lyndhurst]

Well, since the object targeted and the purpose of those methods are similar it makes perfect sense to harmonize the naming, and I am sure it makes things more fluid when you get more fluent in qtile code base and APIs. When I said it got me confused it might not have been the best choice of word, but human brain wiring is thus made that if we see a pattern, it must be a sign we are on the right track :) especially when trying to solve a problem..