Could tiling window managers fingerprint users and render letter-boxing useless?
Tiling WM change and resize windows suddenly and move them around in a grid. The resize behavior is different than the resize in Desktop Environments.
Is it discouraged to use tor in tiling WM?
This is exactly one of the use cases and reasons for LBing. We try and open all windows so that the
inner window is at a maximum size (currently 1000 x 1000). But not everyone can be that size, so we also step down to fit. So everyone’s inner window falls into about 12 or so common sizes (e.g. 1000 x 1000, 1000 x 900, 1000 x 800, etc)
But sometimes there are issues, such as being off by a few pixels due to rounding on high devicePixelRatio devices and system scaling (which we should be able to fix). Or users can manually resize the window bigger (it’s not that hard to do it accidently either), or they maximize, or toggle on bits of chrome (menubar, sidebar, etc). And yes, I have seen when tiling managers take over or the newwin size is so close to the edges on creation that the OS takes over and snaps to fit.
This is when LBing takes over to at least add some protection by controlling the
viewport area’s size inside the
inner window. This keeps the reported values at a very small fraction of what is possible without LBing, so no, LBing is NEVER useless - it’s actually essential for precisely these situations
I don’t think it’s very feasible for a script to try and detect patterns in window resizes (i.e you were X now you’re Y), especially when there are so few LBing combinations. It’s also not likely IMO to be few a stable metric (disclosure, I do not use tiling managers). That said, it is an interesting thought - the speed of change (it would be a single step which is not likely human), and the possible aspect ratios of those (indicating use of tiling percentages in say 16/9 screens, but somewhat blunted by LBing restrictions).
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.