How exactly does it cause a problem for you? I downloaded Gimp and added it to the ignored list (using only gimp-2.8.exe in the File Name field); I don't seem to see any incompatibility issues at first glance.

Where do you see the problem? Also, what do you have defined in the ignored application fields?

The goal of S+ is to be as lightweight as possible; in terms of RAM and CPU resource usage. It's easy for S+ to know when an application has become active via Windows Event notifications. It's also easy to check the window under the mouse right when you press a mouse button.

However, for S+ to re-enable itself when a window/program is no longer running would require S+ to constantly poll all running processes and enumerate all windows...all the time.

That would affect performance negatively, and likely make a few people rather upset!

You can store the process handle when S+ is disabled and do a simple WaitForSimpeObject() or WaitForMultipleObjects() on this handle to know when the process ends. No polling involved with this method and you only add one process handle per process S+ awaits on to the resource count (and maybe a single thread to execute the WaitForXXX() but I don't know your architecture).

I always forget about WaitForXObject. I'll keep it in mind, will move this back to the request forum as open.

My only concern it the amount of variables. Meaning, someone has Gimp disable S+, then they switch to another app and manually re-enable S+. Then activate another ignored window with the same disable setting, then manually re-enable again.

Just seems like there's the possibility of a situation which isn't purely deterministic in what should happen. Not that it couldn't probably be overcome, just sounds like either a simplified version of the feature (only the first or most recent ignored handle is managed), or complicated state management.

Like I said, I'll tinker around and see if it's something that can be easily handled.

another happy discoverer of strokesplus here after about a decade of using strokeit. Gimp is the first app I've encountered issue with and just had to add the exe ignore and then uncheck Keep Gesture Window On Top*

This is the first actually useful description and hint we ever got for this issue (we suspect something similar might be the cause for related issues we got with tools like SnagIt, Camtasia, Camstudio, Skype...). It has been confirmed to affect other applications based on the GTK+ ui framework as well, so the issue is likely there. My guess would also be that the full-screen window makes the toolkit think the windows are obscured.

We'd like to check if we can solve this on the application or preferably toolkit level - but none of us are Windows developers, so we lack ideas what would have to be done to still get all mouse-related events. Any hints here?

P.S. we would have loved to get a bug report about this in 2013/2014, would have saved us a lot of time.

If that is of any help. Note WS_EX_TRANSPARENT and WS_EX_NOACTIVATE , these tell Windows that the window is transparent and cannot be activated by the user. Though, transparent windows can also have color key/alpha blending where there are non-transparent parts of the window, so the existence of a WS_EX_TRANSPARENT style on the window doesn't mean the whole thing is transparent. Also, I know some apps look to see if there's a WS_EX_TOPMOST window that's visible and think there's a full screen app open; again, this is simply not a good approach in most cases since you can have a fully transparent top most window that's not interactive like S+ has.

Again, I think the first place to look would be to see if there's anything in the main message pump that's checking the topmost window and deciding whether or not to process the messages. You really shouldn't need to be selective at all, just process them as Windows is already doing that job for you. Unless, of course, there's a specific application reason you need to do so.

And by the way, by unchecking the options Keep Gesture Window On Top* and Don't Hide Gesture Draw Window*, S+ hides and sends the drawing window to the background. By default it stays on top for performance reasons and to avoid flickering when setting up the window/blending/etc every time the user clicks the stroke mouse button.

So turning those off allows GIMP (or likely the toolkit) to not see a window above GIMP and process events normally.