How could I remove the move/resize window delay?

I noticed a half second delay when moving then resizing a window. I'm assuming this has something to do with Sonoma, but I've downgraded to Ventura and the delay still persists. Is there any way to remove this delay (even if it comes at the cost of consistency)?

Thanks in advance :slight_smile:

It is not restricted to Sonoma.

You can eliminate the delay with:

defaults write com.stairways.keyboardmaestro.engine WindowSetFrameAnimationTime -float 0.0

But if your move & resize windows start acting oddly and failing in weird ways, please remember you did this rather than sending in support requests asking why.

Sadly it's a choice between slow and works (almost always) or fast and works sometimes for some people maybe. Until Apple decide to resolve it.

Hello Peter

Thanks for this hidden preference ..

I seems to me (since this is not the first time I see an answer from you with a defaults command like this one) that such preferences aren’t listed anywhere in the wiki … is there a reason for this ?!

Also it seems to me there are way more of these - can you maybe please add a dedicated page to the wiki for all these possible commands with a declaration why they exist and when they are to use ?!

Maybe I am missing something here and you’ve listed them already ?!

Again I thank you for your time you put in here. It’s always a pleasure reading such replies from you.

Greetings from Germany

Tobias

Thanks for the fix! I'll keep this mind if I notice odd resize behaviour.

FWIW there is a page that lists a fair number of the command line preferences, albeit not this particular one: Preferences manual. Look for “Preferences Set by Command Line” about ¼ way down the page.

Although I can't speak for Peter, speaking as someone whose company releases Mac apps, there are a few reasons not to simply create a page listing every possible hidden setting. Here are a few of the reasons we don't just list all our hidden prefs:

The first (and most important) is as Peter alluded to above: A user will set a hidden setting, then months later (or when they get a new Mac or do a full reinstall), write in to complain that the app either isn't working as explained in the help, or that the app no longer works as it does on their other Mac or as it used to work. There's nothing more frustrating than going through a long troubleshooting exchange until someone figures out they'd set a hidden preference.

We also use hidden preferences to test things out that we're contemplating for general release as features. In that case, we don't want users setting these values—not because we don't necessarily want them to see the features, but because we might decide not to release that feature, or change it substantially before we do, or Apple may break whatever thing we were relying on to enable the feature.

Finally, we have some hidden preferences that exist solely for users who are experiencing an issue that's very specific to their setup, and that wouldn't apply to the general user base. As a specific example, we found that some users with a very esoteric method of connecting external displays were having trouble with our app Moom. After much troubleshooting with these users, we came up with a workaround that requires invoking a hidden preference. If a user who wasn't having these issues applied that setting, Moom would stop working properly for them. So we won't publish that setting, because we only want the affected users to use it, not the general user base. (And that number of users over the last five years is like three or four, total.)

There are other reasons, but for us, these are the main ones as to why we don't share every hidden setting with our users.

-rob.

2 Likes

Hey Rob

Thanks for this reply … I think you’ve nailed it … your long and detailed message opened my eyes - many many thanks for this even though that you are not Peter …

My wish was it to maybe give him some time back that he could invest into the development of Keyboard Maestro - while the average user has maybe some way to troubleshoot for him self… this was maybe not an intelligent idea…

I understand your statement absolutely and now after reread of Peters post his answer, too.

While I and some others (you included) would use such preferences only as a last resort - there are maybe many others that would never try to figure out their issues …

Wish you a nice day

Greetings from Germany

Tobias

1 Like

Hey Chris many thanks pointing to the Preferences Page of the Manual … even though that I know this Page and the contents are in my head - it’s nice and very kind of you on your try to help.

Totally appreciate this :+1::+1::+1:

Greetings from Germany

Tobias

2 Likes

Rob answered this pretty clearly.

There are lots of command line settable preferences that are documented on the wiki page. These exist to workaround specific customer issues, or to offer solutions that are easy to code, but not easy to explain or add visible preferences for, or to allow for future changes which I can foresee but not predict, etc.

This one, I'm not sure I want to formally document. It basically trades off working correctly (albeit slowly), and dealing with Apple’s weird bugs, for speed but perhaps (likely) unreliability. I hade that this is even a choice. And the preference exists as much as anything to allow setting the delay even longer, since there is no real way to know how long the animations might take or how that timing might change in the future.

Hello Peter :wave:

Thanks for your reply - even after I answered on Robs reply that I now fully understand that „why?!“ and you’ve put a like on this …

Yeah, I’m aware of these Preferences… and I am dealing with them in my Macros on their particular use case when needed … they are a „really nice thing to have“ and of course I curse them always with caution …

I totally understand that … it is of course your decision on if or if not providing us such preferences on the wiki pages for dealing with this weird thing that apple is doing on providing us more features but not fixing old bugs they’ve provided in the past.

I also hope that you understood what my intentions were… just giving you back more time for further developing Keyboard Maestro increasing the power of functionality and features and giving us somewhat like a last resort go to feature we could try to deal with on our selfs before we need to ask you for help on troubleshooting our issues.

But I also understand that there is the factor of an amount of people who might not really try to figure out things the usual way and tend to use the easy way around this and producing automation that will maybe make things more worse as they’ve thought it might be.

I hope this makes sense to you …

I wish you a great day and of course:

Greetings from Germany to Australia

Tobias

1 Like