UP, DOWN, RIGHT, and LEFT are toggling various sizes.
akume opened this issue · comments
If hit "Control, Option, Command, Right Arrow", the first time I press the button it occupies half the screen, the second time it occupies 1/4 of the screen and the third time it occupies 3/4 of the screen. In the previous version it only ever shifted to one size, not toggle between 3 sizes. How do I disable this. I only want to adjust the size if i use "increase/decrease"
I am also seeing this issue. I'm on macOSX 10.13.1 High Sierra, Shiftit version 1.6.4.
However, I also see this: 4eb812c#diff-56871a3206d3da0335c9957855cdb290
Perhaps it's not an issue, but a built-in function.
If this was intentional, I'd really appreciate a toggle option to disable it. Even just moving a window between the left and right sides of the display will iterate through the small/medium/large sizes, which is undesirable behavior.
macOS Sierra 10.12.6
ShiftIt 1.6.4
Also on macOS Sierra 10.12.6 and ShiftIt 1.6.4 and would love an option to disable if it's a feature and not a bug. Every shift left and right takes three key presses to split my screen evenly down the middle and it's a feature that I use constantly.
this blames to #223, which implements a buggy solution to #183, because shifting Left then shifting Right causes the window size to change, though #183 suggests that window size should only change after successive inputs of the same shortcut.
the easiest fix is to downgrade. the next easiest fix is to release a version with this PR reverted. the right thing to do is to fully implement the suggestions in #183. I might take a look at fixing if I find the time...
Yep, I absolutely love the simplicity of Shiftit. But, this change has made me from LOVING it, to being totally frustrated. For the sake of my workmates who have to listen to my whinging -- my vote is to revert back to previous behaviour, or add it as a preference with the functionality disabled by default.
Successfully reverted to 1.6.3 -- FTW!
There were some requests for the 1/3 so perhaps we can just make it a bit smarter. I guess always having at first to move to 1/2 should be reasonable?
I guess always having at first to move to 1/2 should be reasonable?
No, please don't. Accidentally hitting the key combination the second time should not do something different than hitting it the first time. It would drive me nuts when I'm in a hurry.
I strongly vote for giving 1/3 its own key combination.
I'm strongly in favor of keeping the feature -- I'm a huge fan of it. If it can be a preference to toggle the behavior on/off that's fine.
I'm strongly in favor of this becoming an option that can be set in preferences.
In the mean time, it sounds like the best I can do is just install 1.6.3 instead.
There were some requests for the 1/3 so perhaps we can just make it a bit smarter. I guess always having at first to move to 1/2 should be reasonable?
I think this improvement should be made, and the cycling behavior should be a toggle-able option. Cycling can be useful to some users, and would be more useful if it always moved to 1/2 first (as you suggested). And for those who don't want cycling, having the ability to turn it off would be great.
I tried to get use to for 2 days, then I found this issue.
Rollback to 1.6.3 and be happy
I used to love shiftit, then I took an arrow to the knee (and looked everywhere for the option to disable this new feature).
As @phorust said, window size should only change after successive inputs of the same shortcut. With a default size being configurable (50% for me) everything would be great again.
I think that should be the default behaviour, no need to create a checkbox to disable it if it works that way
Make ShiftIt Great Again! I'm going to run away now. haha!
From reading the thread, suggestions have been:
- make it an option to toggle on and off
- make it a different key combination
May I suggest adding a cycle preference that defaults to 0.5 (the old, expected behavior). This means that no matter what key combination is being used the size is going to be one half. Additional sizes can be added by changing the setting to, for example, 0.5, 0.3, 0.7 and that would roughly emulate the current, strongly disliked, setting.
This also opens up the possibility for 0.5, 0.5, 0.7 - i want to cycle to half size twice for my twitchy finger ness and then only size up, before starting the cycle again.
Or 0.7, 0.5 - i want to start with a larger size and then drop to half.
This "feature" is so annoying I have also downgraded. Drives me bonkers to try to shift something to one half and it takes up 2/3 or whatever size.
I'm not super opposed to successive inputs causing it to resize, but if I have a window taking up the upper right quadrant and then I try to make it take up the right half, that's not what happens. This sizing is going crazy.
I think cycling (1/2, 1/3, 2/3) if you repeatedly shift to the same location/direction makes sense. However, what makes a lot less sense to me is that it cycles even if you shift to different locations.
Eg:
- shift to left, window now takes up 1/2 the screen on the left
- then shift to right, window now takes up 1/3 the screen on the right
I would expect that left then right would cause the window to take up 1/2 of the screen on the right, not 1/3. This appears to happen because the 1/2->1/3->2/3 cycling happens even if you alternate locations/directions.
Is this particular an intentional part of #223, or a bug?
Yes, I also think shifting to a different location should be consistent. I made a similar comment in #253.
IMO, whether a bug or not, the experience can be better.
@waltz, would you be up for modifying the sizing behavior so it, at least, consistently sizes the window to 1/2 when switching directions.
Thanks!
I feel fairly strongly that repeated key-press perform the same; ie , would remain at 1/2 screen size. From the UX perspective, shortcut behavior usually does not change (how often does hitting + alter the behavior of copying text that's selected?) with repeated key-presses.
That being said, I think it's completely acceptable to have an option one way or the other; something along the lines of "allow repetitive key press to dynamically change window size" as to satisfy both schools of thought (those that are ok with subsequent shortcut invocations to change the window size, and those who want it to remain static).
What I found most counterintuitive is that even if the windows was not in the position the previous cycle left it, it would still cycle. This meant my application started in some random location on the screen and would get resized to an arbitrary size every time.
Not to my liking, and therefore I also downgraded.
Yeah, it was a mistake to include the PR without properly testing it. I was without apple laptop for quite some time (I had it stolen) so I did not realize it. I shall be fairly easy to change the behavior to do 1/2 and then 2/3, 1/3 (something what others wanted). Anyone wants to give it a try?
@fikovnik I have a working version that I've been using for a couple days that fixes the buggy behavior (but doesn't add a toggle, or custom sizes). Are you interested in a PR?
@kjrokos please open a PR. I think consistently starting with 1/2 is a big step in the right direction.
Draft of fix here: https://github.com/rca/ShiftIt/releases/tag/1.6.5 with consistent sizing to 1/2 when directions change. Thank you @kjrokos !!
Second draft of fix. The cycling behavior can be enabled / disabled by running defaults commands on the command line:
defaults write org.shiftitapp.ShiftIt multipleActionsCycleWindowSizes YES
defaults write org.shiftitapp.ShiftIt multipleActionsCycleWindowSizes NO
Download ShiftIt.app.zip here: https://github.com/rca/ShiftIt/releases/tag/1.6.5
This complete killed my workflow, at least make it start at half-screen. The fix that @rca mentioned works like a charm though!
kjrokos did the hard work. I merely compiled it.
Just waiting for some feedback before rolling an official release.
@rca I install with "brew cask install shiftit", apparently I do not have an option for specific versions due to a limitation in the cask system. I cannot use a previous version easily. The current one is not defaulting to 1.6.5 with this command, it is using 1.6.4 instead. Is there any way we can get 1.6.5 to be the default release or does it require additional testing? This issue is annoying to me, but not quite annoying enough for me to change the way I install programs.
@tekemperor you can downgrade to 1.6.3 while we wait for the official 1.6.5 release.
@fikovnik Sorry to hear about your computer being stolen :( Thank you for the work on this.
For the record, I agree that there should be a toggle in the preferences GUI for always 1/2 vs steps of 1/2, 1/3, 2/3.
Good news, everyone, I've released 1.6.5: https://github.com/fikovnik/ShiftIt/releases/tag/1.6.5
@tekemperor I'm new to the release workflow; please let me know if brew finds this new release.
Thank you, and closing.
Thanks for pushing this through!
Unfortunately, the release doesn't seem to have worked properly. The "new version" update window shows, but spins indefinitely:
And when clicking "Install Update", I get:
Perhaps this has to do with the fact that there are 3 commits since the release that update configs to the new version number and define the release notes? 1.6.5...master
From what I understand, typically the version bump commit would be pushed directly to master, and that commit would be the one tagged for release.
If the commit has to be on master then, yes, I blew it. :/
Can I get a confirmation that the update is failing for someone else? Or conversely that it does work for someone else.
I can make a .6 release tagging directly to master.
@rca It does not work for me either. Same problems as @sjdemartini.
The auto-update was failing for me too. I reinstalled from releases.
Using homebrew works fine:
$ brew cask upgrade shiftit
Where have my thirds gone?
I just got used to them and found them useful.
edit:
phew - found them again:
defaults write org.shiftitapp.ShiftIt multipleActionsCycleWindowSizes YES
Please add this to the UI options.
Please add this to UI