| Author |
 Topic  |
|
|
Firepawa
4 Posts |
 Posted - 08/20/2013 : 10:53:14
|
Hello world and a great thanks for this great tool.
My suggestion is to add a "Enable S+ if this application is stopped" option in the Ignored list.
I disable S+ when GIMP is started because there is an incompatibility between the two software on my Windows 8 x64 (only disabling S+ for GIMP still makes GIMP unusable). |
|
|
Rob
USA
2615 Posts |
Posted - 08/20/2013 : 12:59:56
|
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? |
 |
|
|
Firepawa
4 Posts |
Posted - 08/20/2013 : 18:29:23
|
With S+ active load a picture in GIMP and then try to select various tools in the tool bar. For me once you selected a tool it is almost impossible to select another one, it just doesn't click it.
I think it is more an incompatibility issue with the graphical framework they are using because I also have the same issue with Inkscape which I think uses the same framework. |
|
|
|
Rob
USA
2615 Posts |
Posted - 08/20/2013 : 19:49:30
|
| Try unchecking Keep Gesture Window On Top* and Don't Hide Gesture Draw Window*. The gesture drawing surface is a full-screen transparent window. It's possible that Gimp thinks it's an application window and doesn't behave properly. |
|
|
|
Firepawa
4 Posts |
Posted - 08/20/2013 : 20:24:17
|
Unchecking "Keep Gesture Window On Top*" solved my GIMP issue.
Thanks !
Anyway you may want to keep my first suggestion :) Seems strange that S+ can't be automatically reactivated once the app it's been disabled for is stopped.
Thanks again great support.
|
|
|
|
Rob
USA
2615 Posts |
Posted - 08/20/2013 : 20:28:39
|
Strange as it may seem, there's actually a very good reason 
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! |
|
|
|
Firepawa
4 Posts |
Posted - 08/20/2013 : 20:55:42
|
| 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). |
|
|
|
Rob
USA
2615 Posts |
Posted - 08/20/2013 : 21:05:56
|
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. |
|
|
|
todd
4 Posts |
Posted - 12/02/2014 : 13:39:57
|
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*
thanks |
|
|
|
schumaml
1 Posts |
Posted - 04/13/2017 : 04:58:16
|
quote:
Originally posted by Rob
Try unchecking Keep Gesture Window On Top* and Don't Hide Gesture Draw Window*. The gesture drawing surface is a full-screen transparent window. It's possible that Gimp thinks it's an application window and doesn't behave properly.
Hi,
GIMP developer here.
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. |
|
|
|
Rob
USA
2615 Posts |
Posted - 04/13/2017 : 08:56:34
|
It may be as simple as not checking for any windows in front of the app. Windows won't send your app any mouse events unless it's accessible (visible, not behind an interactive window, etc.)
The lines S+ uses to setup its screen-wide drawing/gesture capture window are:CreateWindowEx(WS_EX_LAYERED | WS_EX_TOPMOST | WS_EX_TOOLWINDOW, szWindowClass, szTitle, WS_POPUP,
GetSystemMetrics(SM_XVIRTUALSCREEN),
GetSystemMetrics(SM_YVIRTUALSCREEN),
GetSystemMetrics(SM_CXVIRTUALSCREEN),
GetSystemMetrics(SM_CYVIRTUALSCREEN),
NULL, NULL, hInstance, NULL);
...
SetWindowLongPtr(hWnd, GWL_EXSTYLE, GetWindowLong(hWnd, GWL_EXSTYLE) | WS_EX_NOACTIVATE | WS_EX_TRANSPARENT); 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. |
|
|
|
Rob
USA
2615 Posts |
Posted - 04/13/2017 : 11:34:08
|
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. |
|
|
| |
Topic |
|
[OPEN] Enable S+ if this application is stopped
Forum Locked
