Improving Untiled Window Handling

[txiao]

The current behavior for untiled windows seems a bit unintuitive. This change makes untiled windows always start on the first configuration.

Implementation notes:

• The closest current configuration is still picked the same way.
• If the window is already on a configuration switch to the next. Otherwise use the first.
• Some windows, such as terminals or editors resizes in chunks, so "on a configuration" is loosely defined as within 500 pixels in Euclidean distance.

[ssokolow]

Sounds reasonable. I'll probably accept it once I've had time to look over the patch.

I was actually also thinking of redesigning Quicktile to keep an internal grid so it would be possible to bind keys to shrink/grow the current window's column/row. That would simplify this even further by making an easy way to check whether or not a window is in a tiled state.

[txiao]

Do you mean storing the grid positions of the windows that have been tiled?

[ssokolow]

What I'm currently thinking of is :

• Set up a grid of rows and columns in memory similar to an HTML table.
• Position windows by specifying their cell row, column, rowspan, and colspan.
• Add the following numpad keybindings to the defaults:
  • /: Shrink the column of the currently-selected window
  • * Grow the column of the currently-selected window
  • - Shrink the row of the currently-selected window
  • + Grow the row of the currently-selected window

All existing positioning presets would then be specified in row/column coordinates rather than pixel coordinates.

The main question I still have to answer about the design is whether users will have a need for a way to grow/shrink rows/columns that a window extends into via row/colspan.

[txiao]

That makes sense. It's also probably simpler to have the config specify window positions in terms of points on the grid. But I don't think there's need to change the size of the grids (at least not by hotkey).

The issues I can see are:

• If the grid size is increased without reducing the number of grids, then the bottom/right grids would be chopped off at the screen edge.
• Reducing the number of grids breaks predefined positions. A user might hotkey Ctrl-Alt-6 for the (3,0) (6,2) grid position because it corresponds to the right half of the screen, but if a column is removed, then Ctrl-Alt-6 would cause the window to be 2/5 of the screen in width.

An alternative is to set the number of grids/columns on the screen in the config file. If someone with a very large screen wants to put 4, 6 or 8 windows side-by-side, then they might divide the space into 12 columns, while those with smaller screens would be ok with 6 or even 2 columns.

One more thing: What will happen to the non-daemonized mode if the grid is stored in memory?

[ssokolow]

But I don't think there's need to change the size of the grids (at least not by hotkey).

I know there's demand for this row/column dynamic resize because I keep wishing for it and I'm also a user.

If the grid size is increased without reducing the number of grids, then the bottom/right grids would be chopped off at the screen edge.

It would work like the "grow/shrink active window" feature in tiling WMs like AwesomeWM. The grid wouldn't change size. Instead, space would be redistributed from one row/column to another.

Reducing the number of grids breaks predefined positions.

That's the point. It's not practical for me to quit QuickTile, edit the config file, and restart it just because I want one of my columns to be narrower temporarily. The idea for this is that the number of rows and columns would be static and defined in the config file right next to the preset window shapes. Users who don't want the feature can ignore it or even remove the keybindings for it.

What will happen to the non-daemonized mode if the grid is stored in memory?

I'm not sure. Either I'll change my mind about how the grid is implemented or I'll find a way to reliably save it to disk between runs. Either way, the non-daemonized mode will retain full functionality.

[txiao]

Don't mean to argue agains the feature. I'm happy so long as predefined positions continue to work (and ideally be user-defined in the config file).

[ssokolow]

Don't worry. It took me far too long to get a config file. If anything, I'll be extending what it can do. (Maybe adding support for a ~/.config/quicktile/functions.py file which would let you define your own tiling functions)

[ssokolow]

Sorry about being out of contact for so long. Life got busy for a week.

I've looked at the code, but I'm a little concerned about the min_distance[0] < 500 part. That seems like an awfully permissive size. (My monitors on my powerful pseudo-workstation are only 1280x1024 and I can see that breaking on any layout which divides an axis into more than two parts)

Could you make that relative to sizes the current layout specifies once the percentages are converted into pixel lengths based on the screen size?

[txiao]

Sure. I expected the 500 value to be problematic, but it's surprising that this is breaking on a 1280x1024 monitor. It's working fine on my 1920x1080 screen. Maybe the problem is that the value's actually too high.

[ssokolow]

I'm not saying that it is breaking. I'm saying that I can easily see it being a problem on a 1280x1024 monitor because some of the layouts I've used in the past make windows smaller than 500px to a side.

[txiao]

Ah there's a a quirk in the min_distance calculation. It was missing a square-root around the sum expression. So 500 corresponds the area.

[txiao]

I tested this and it's working with the default set of dimensions and monitor sizes down to 640x480.

[ssokolow]

Works here but I have two remaining concerns:

• I'm not entirely clear on the effect that * 0.5 has (The code you're modifying is something that was contributed and I always end up having trouble remembering how it works)
• I'm a little concerned about how close 25px is to some of the thicker titlebar themes I've seen. In my experience, there's always some window manager out there that will confuse any code you write to determine the window's decorated geometry.

If we can clear those points up, I'll merge it right away.

[txiao]

The **0.5 is the square root. The equation for the euclidian distance is sqrt((x2 - x1)^2 + (y2 - y1)^2). Whoever contributed this had forgotten the square root part, but it worked anyways because a < b implies sqrt(a) < sqrt(b).

Unfortunately, I can't test on those WM's. But anything between 20 and 150 seems to work for my setup for all the screen sizes I could test. Any number above seems to cause some issues at smaller screen resolutions. If you're ok with 100, I'll make the change.

[ssokolow]

Ahh, yeah. I'm a little sleepy today so, as you can see from my previous comment, I saw * rather than **.

I don't expect you to test on every WM in existence. My point was that doing so is impossible. Set it to some value in the range of 75 to 100, inclusive, and I'll give it a quick test and then merge it.

[ssokolow]

For the record, GitHub doesn't e-mail me when you add a commit. Only when you add a comment.