App Sweep window & Spaces

With Spaces active, I'd like the App Sweep window to always appear in the current space instead of the jolting distraction of sometimes being auto-switched to a different space where it appears. I couldn't figure out which app (if any) to choose in Spaces Preferences to appear in all spaces in order for that to happen. It's not HazelHelper and Finder would be an unacceptable choice. If that's not possible please consider this a feature request, however it's implemented. Thanks!

Last I checked, this wasn't something controllable by the app. I'll dig around and see if that's changed. It is the HazelHelper process that brings up the window so if that's not working, my guess is that it's a bug with Spaces. Nonetheless, I'll look into it.

Thanks.

Mr_Noodle wrote:It is the HazelHelper process that brings up the window so if that's not working, my guess is that it's a bug with Spaces.

I was testing on 10.5.8.

Looking at the docs, it looks like this is fixable after all. There is some confusion in the APIs but I think it's more clear now. I'll play around with it and hopefully it'll make the next release.

By the way, it seems there are two different ways to do this, have the App Sweep window show up in the active space or appear in all spaces. I'm leaning towards the former as that seems to be more consistent with dialogs. Unless you feel strongly in the other direction (and can provide a good case for it), I think that's how I'm going to implement it.

Thanks for the followups.

Having it only appear in the active space is preferable (to me). My failed attempt to configure it to appear in all spaces would have been a less desirable workaround to avoid the unwanted space-switching.

Hopefully it'll still be possible to minimize the dialog window or move it to a different space (e.g. with a toolbar click-and-old plus Control-# shortcut). And, if possible, I'd rather it didn't grab focus when it appears unless there's a good reason for doing that… hmm, maybe to avoid unintentionally emptying Trash before acting on the dialog once it appears?

Which relates to:

Another issue I'm having is being unsure how long to wait for the dialog to appear (or not). And its appearance is normally unnecessary when doing drag/drop updates by first deleting the old app instead of overwriting it with a new version (my usual method) but I'll wait for it to appear anyway.

I'd originally thought App Sweep could be permanently enabled, but not being able to predict both where and when its dialog will appear and demand attention is causing intrusive delays. Now, after a couple weeks of testing I realized (while composing this) that it could be more effective for me to only enable it when explicitly needed instead of constantly monitoring. And that would make the interaction with its dialog window and Spaces less significant than it was when I started this topic.

Finally wrapping this up, I'd like it to be possible to leave enabled without excessive interrupts/delays but can be satisfied with an as-needed usage strategy.

Well, it has to grab focus. If it doesn't, it will end up buried. And especially since it's done in response to a user action.

Doing a delete and then copying it over is totally unnecessary and there is no way for AppSweep to know you are doing this (it can't predict the future when you throw it away that you are going to replace it). If you are super quick you might be able to pull it off but you can't expect it to know what you are going to do and to wait. Just let Finder do the swap.

You know there is a checkbox where you can turn it on and off?

Mr_Noodle wrote:Well, it has to grab focus. If it doesn't, it will end up buried. And especially since it's done in response to a user action.

For comparison, there's a NetAuthAgent dialog that pops up, prompting for a password for keychain access, that doesn't grab focus and is triggered by a user action. That's how I was wondering if App Sweep's might behave.

Doing a delete and then copying it over is totally unnecessary

I'd prefer skipping discussion of that method and my reasons for using it.

and there is no way for AppSweep to know you are doing this (it can't predict the future when you throw it away that you are going to replace it).

Yup, I understand it can't and never expected it could.

If you are super quick you might be able to pull it off but you can't expect it to know what you are going to do and to wait.

I can often do a delete and replace before the dialog appears (if ever), but it's awkward because of the anticipation of the dialog in that context.

Just let Finder do the swap.

That'll certainly reduce unnecessary dialog appearances while allowing App Sweep to remain permanently enabled.

You know there is a checkbox where you can turn it on and off?

The Enable App Sweep checkbox on the Trash tab of Hazel preferences? That's the only way I know to turn it on and off.

Summary:

If you changed the App Sweep dialog not to grab focus and/or I changed my app update style my preferred choice would be to normally leave App Sweep enabled. If neither of us make a change I'd rather it be normally disabled. Currently I can choose whether my app update style or keeping App Sweep enabled matters more, which becomes less of an issue if you happen to make the dialog change. I'm leaning towards the latter since it's likely I'll forget to re-enable App Sweep at times I'd want it working. And I'd rather adjust my app update style to do that than allow the focus-grabbing dialog to be a distracting nuisance. If you changed the dialog later then I could decide whether or not to revert my app update style.

Conclusion:

Regardless of how I'll use App Sweep I'd prefer its dialog to be non-focus-grabbing but don't want to make that the deciding factor in my usage. I think the focus-grabbing would be less of a concern to me if the dialog delay was consistently short enough.

Last moment idea:

Optional Growl notification to indicate App Sweep processing has finished when it doesn't throw up its dialog. Waiting for that notification would be more tolerable to me than waiting for a dialog that may never appear.

Well, the delay is the time it takes to do the scan. I'm always trying to optimize it but it can take a while depending. I could try something like bring up the panel once it finds the first file and have it incrementally load. I'd prevent the panel from being dismissed until it's done though. I'm also considering some indicator that it's busy scanning.

As for grabbing focus, it's normal for dialogs to do so. It's complicated in this case by the fact that it's a UI-less/headless app. So, even though you don't see it, it is switching to another app. I'll play around with it but it may not be avoidable, depending. For instance, right now it's prone to getting buried under other app's windows and I don't want to increase that likelihood.

I'm satisfied we've reached a mutual understanding about this. If nothing more, I'm hopeful a future release will have the dialog appearing only in the active space (if possible). As always, I appreciate your thorough explanations -- thanks!