Feature request: add centre positions
Closed this issue · 6 comments
Hi. I just installed this and think it will be very nice to use. This is more of a feature request, but is it possible to add more positions?
Specifically my want would be top-center like yakauke does it.
I've also seen zones like:
123 top-left, top-center, top-right
456 center-left, center-center, center-right
789 bottom-left, bottom-center, bottom-right
Thanks again!
Hi amaryniuk,
Thanks for reaching out. This request makes a lot of sense and would be pretty straight forward to implement, it just hasn't occurred to me to add as a feature.
Just so I'm sure I understand, you want something along the lines of this in terms of placement, correct? To preserve backwards compatibility, I'd be inclined to add a new cli option, say -a / --align to modify the point of origin from which to grow the major dimension - e.g. -a center to yield the behaviour you're after.
The only snag with the -a option proposal is that if we want to allow word processor-style choices for it, i.e. -a left|center|right for when -p top|bottom and -a top|center|bottom for when -p left|right, which seems sensible, then we'll have to do some sanity checking during argument parsing to give users who try e.g. -p top -a top a slap on the wrist. Would be a bit cleaner if we could find a single word to cover "left or top" and another for "right or bottom", but nothing comes to mind at the moment.
Anyway, I'll see what I can do.
Hi,
Yeah, your linked screenshot is the behavior I'd like.
I see your point about backwards compatibility.
Yeah, One quirk I see that if I have a --shape of 0.7 0.3, and a -p of top and change to left, the top left 0,0 position stays the same, but the shape length width swaps.
One option could be to do a --zone option as I said above, where essentially left is zone 4, top is zone 2, right is zone 6, bottom is zone 8. And then new zones for the corner and centre positions. It would preserve backwards compatibility, but you would maybe run into trouble if someone tried to pass a -z and a -p flag.
Whatever you decide, thank you for considering this enhancement.
One quirk I see that if I have a --shape of 0.7 0.3, and a -p of top and change to left, the top left 0,0 position stays the same, but the shape length width swaps.
Yes, past me wanted to generalise the shape to have the first value always refer to the "major" dimension of the Kitty window, which with positions limited to hugging either a horizontal or vertical edge seemed like a good idea at the time. But it is both inconvenient to work with and, as your comment highlights, not very intuitive. So let's throw that out and standardise (x, y) order for shape from now on*.
I did a test implementation of the proposed -a / --align argument, but after chewing on the results for a bit it was apparent that this approach made for a pretty messy implementation and retained some potentially confusing redundancies (e.g., -p top -a left -s 1.0 0.5 == -p left -a top -s 0.5 1.0). So instead I've decided to go with your zone suggestion but treating it as an extension of the -p / --position option (as opposed to adding a separate -z / --zone option).
In the next release of Kitti3 you'll be able to position to any of the 9 quadrants via a 2-char ID:
| Left | Center | Right | |
|---|---|---|---|
| Top | LT | CT | RT |
| Center | LC | CC | RC |
| Bottom | LB | CB | RB |
Note that neither case nor character order matters (e.g., RT == tr).
Further, the -p / --position option will still accept the old choices (for now), with the following internal mapping:
| Old | New |
|---|---|
| top | LT |
| bottom | LB |
| left | LT* |
| right | RT* |
* For backwards compatibility I've elected to retain the (y, x) shape order when the user specifies one of the legacy-style positions, -p left|right. This way no one should get an unwelcome surprise when updating Kitti3, while the shape argument will always be in (x, y) order for the new-style positions.
I hope this looks like good solution. Thanks for the feedback so far, and don't hesitate to let me know if you have any further comments.
Err, closed this prematurely; I'll leave it open until I've done the actual PyPI packaging push.
Oh wow. Completely unexpected, but appreciated turn around time on this request. I look forward to trying the update.
Thanks so much!
You're very welcome. It was a good feature request which coincided with some time off from work, so fortunate circumstances :)
I have just pushed the latest release - v0.4.1 - to PyPI, so you should be able to take it for a spin now.