Better dimensions for "portrait" monitors

[kevinmarsh]

I have a dual monitor setup, the same size monitors with one in landscape (1920w by 1080h) and one portrait mode (1080w by 1920h). So cycling through the dimensions on my landscape monitor with quicktile works exactly as I'd like, however on the portrait monitor I'd like the window dimensions to be slightly differently. For example currently cycling through quicktile.py bottom results in the following window three sizes:

But having the window that skinny isn't any use to me, it'd be better if it cycled through full width but varying heights like this:

I've only used this on my own machine so it'd need some testing for cross compatibility but you can check my fork out for an initial working version. It should behave as normal on monitors in landscape mode (where the monitor is wider than it is tall) but on portrait monitors it will have different dimensions for the top, middle and bottom positions.

[ssokolow]

Thanks. I'm a little overwhelmed with coursework right now, but I'll take a look at it once my schedule opens up a bit.

[kevinmarsh]

No worries, the actual dimensions should probably be configurable (as suggested in issue 13) but it'd be nice to have the option to have different dimensions configurable dependant on whether the monitor is landscape or portrait.

[ssokolow]

Definitely makes sense. I'll have to spend some time thinking on whether there's an even more general solution I should implement in the config file system once I get around to solving #13

[Semmu]

hey! im not sure whats the state of this project, but i just found it, started using it, and i have the same issue 😅 any update? i see there hasnt been much activity on this project lately 😞

[ssokolow]

It is still on my TODO list. It's just that the bottom fell out of my schedule in the last few months (to the point where I have one hobby project that's flat-out non-functional that I didn't have time to fix) and I'm only now starting to claw things back into shape.

Once that's done and I've fixed said project in more urgent need of a fix, I plan to finish the in-progress port of QuickTile to Python 3.x and GTK+ 3.x and then, relying on the test suite I'm starting to build as part of that process, work on rearchitecting to clear out all the major flaws like this one.

(Porting to GTK+ 3.x is complicated by QuickTile relying heavily on the bits that changed the most between GTK+ 2.x and 3.x and on GDK APIs that PyGI has the most trouble providing bindings to in a convenient way.)

[Semmu]

well then good luck with your other project(s) and your life in general! dont forget to have fun while working on things like this 😄

[ssokolow]

In case you're interested in trying it out, the GTK 3 port that I'll be working toward a fix for this on is available in the gtk3_port branch now.

I still need to fix regressions #107 and #108 before it'll be at parity with the GTK+ 2 version, but it's already got much cleaner internals and a growing suite of automated tests.

Just don't use the pip3 URL from its README. That'll point to the GTK+ 2.x version until the port gets merged into master.