Support floating windows

[n0rad]

Hi there, I'm using quicktile for about 3 years and it's very useful.

Most of windows needs to be tiled but I still have few windows that I want to place at a specific floating location (like VLC). I'm doing it by hand for so long that it could be the time to automate it.

I think it could a good improvement to support key binding to set window at specific location instead of tiling rotation.

What do you think ?

[ssokolow]

Sorry for taking so long to respond. I was out on Monday and very distracted since then.

Snapping windows to more specialized presets is definitely a useful thing, but I'm not sure how you'd want QuickTile to handle that.

Some kind of custom GUI for defining presets? Some kind of "Remember position for this window" and "Restore position for this window" macro keys?

[n0rad]

I was thinking about something even more simple, in the config file define an hotkey where the value is coordinates.

In my use case, I usually put vlc (or chrome with a video) window in small and always on top in a corner, but not competly snap to the edge so I can see controls of the underlying window.
With an hotkey for specific position, it matches my usecase.

Remember the position for a window could be insteresting too, but I think much more complicated to implement, especially to identify the window (especially a specific window of chrome) and store that across reboot.

[ssokolow]

Sorry for the delayed response. I've got some deadlines and I completely forgot that I hadn't already replied to you.

I was thinking about something even more simple, in the config file define an hotkey where the value is coordinates.

I actually want to move the current tiling presets into the config file when I can find time to get back to working on QuickTile. It's issue #13.

Once that's done and I've properly generalized the config syntax, it'd just be a matter of declaring a new command which maps to a one-entry sequence of presets.

Remember the position for a window could be insteresting too, but I think much more complicated to implement, especially to identify the window (especially a specific window of chrome) and store that across reboot.

Storing it across reboots isn't difficult. Every application exposes a set of identifying strings specifically to allow window managers to hang presets off them. (Use xprop to inspect a window and look for WM_CLASS, WM_WINDOW_ROLE, and _NET_WM_WINDOW_TYPE. (Not to mention matching on the window's title.)

The tricky part is reliably telling apart two windows which are identical except for the content within them without making it too brittle... I'd probably solve that by allowing multiple save/restore keys, each with their own settings stores, so the combination of the keybind and the window could determine a destination. (eg. Hotkey1+Firefox = Position 1. Hotkey2+Firefox = Position 2. Hotkey1+Vim = Position 3.)

[n0rad]

Once that's done and I've properly generalized the config syntax, it'd just be a matter of declaring a new command which maps to a one-entry sequence of presets

👍
but, this would require declaring new not tilling sequences.

Use xprop to inspect a window and look for WM_CLASS, WM_WINDOW_ROLE, and _NET_WM_WINDOW_TYPE. (Not to mention matching on the window's title.

I just played with xprop to see how windows could be identified.

Matching on _NET_WM_NAME will not work since chrome and vlc change it depending on what is played.

WM_CLASS will work in my case, even for chrome, since windows are launched as desktop apps and have different class than the browser.

Now the tricky part is that depending on the window, match elements will not be the same.
And for classic chrome windows there is no way to identify one from the other.

[ssokolow]

Sorry for going silent. Things got... messy.

I'm currently preparing to release the port to GTK 3 and, as part of that, I've been writing the automated tests I need to have confidence in the config file rework needed to fix issues like this and #13. :)

(The main things still to be done before it can go to master are finishing up the new Sphinx-based documentation and fixing regressions #107 and #108.)

If you want to try it, it's at https://github.com/ssokolow/quicktile/tree/gtk3_port

Just don't use the pip3 URL install method from the README because it gives the URL for the master branch which still contains the GTK+ 2.x version.

[n0rad]

just tested the branch,

one binding is not working with this version for me :

...
[keys]
0x3c = monitor-next

[ssokolow]

Looks like the change happened outside QuickTile:

>>> from gi.repository import Gtk
>>> Gtk.accelerator_parse('0x3c')
(accelerator_key=0, accelerator_mods=<flags 0 of type Gdk.ModifierType>)

(I used gtk.accelerator_parse under PyGTK+GTK2 and I use Gtk.accelerator_parse under PyGObject+GTK3.)

According to the docs:

The names are the same as those in the gdk/gdkkeysyms.h header file but without the leading “GDK_KEY_”.

EDIT: This copy of gdk/gdkkeysyms.h uses "GDK_" prefixes rather than "GDK_KEY_" and zero-pads the numbers, but, aside from that, it maps 0x03c to GDK_less, so try putting less on the left-hand side.

Note to Self: The guide in the updated docs could use a direct link to a reference for valid keysyms.

[n0rad]

Ok it's fully working for me.

0x3c -> less

If you need help to test specific position keybindings when it will be done, feel free to ask 👍

[ssokolow]

Actually, the current HEAD of the gtk3_port branch is the release candidate, so right now is a good time for any and all testing you're willing to do.

EDIT: If you want to check out the new documentation which will become the site when it gets pushed to master, you can install the Sphinx-related packages in dev_requirements.txt and then run (cd docs; make html).

[n0rad]

Thx I was looking for how to get the new doc.
I gone through it but cannot find a way to have a floating window at a specific location.

I usually work with an always on top video floating at some location but not snapped to the edges so I can see scrolling bars/status bars and sometime switch the video to full screen and then put back floating.

[ssokolow]

Yeah. 0.4.0 is almost exclusively about bringing existing stuff in line with expectations for a modern project. (Dependencies, documentation, automated testing, etc.)

The only feature of note that got merged in was a proper fix for #45 because UseWorkarea=False was dropped in the porting process and I didn't want things to regress for people using it as a workaround.

Most of the work went into writing a solid foundation for writing future layout calculations in a maintainable way. (Basically, writing Rectangle and UsableRegion classes that are more suitable to the task at hand than the GTK+ 2.x equivalents they replace... as well as a thoroughly unit-tested class which functions as a parser for _NET_WM_STRUT_PARTIAL reservations.)

I don't plan on going silent again after 0.4.0 final is released, so new features shouldn't take too long to start arriving. (Though probably not at quite the rate I took up to get 0.4.0 out the door. I have other projects that also need some help. Heck, my second-most popular one is a userscript that is flat-out unusable due to changes in the sites it affects on.)