StrokesPlus Forum
                       
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Feature Updates
 Requests
 [OPEN] Enable S+ if this application is stopped
 New Topic  Reply to Topic
 Printer Friendly
Author  Topic Next Topic  

Firepawa

4 Posts

Posted - 08/20/2013 :  10:53:14  Show Profile  Reply with Quote
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
2380 Posts

Posted - 08/20/2013 :  12:59:56  Show Profile  Visit Rob's Homepage  Reply with Quote
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?
Go to Top of Page

Firepawa

4 Posts

Posted - 08/20/2013 :  18:29:23  Show Profile  Reply with Quote
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.
Go to Top of Page

Rob

USA
2380 Posts

Posted - 08/20/2013 :  19:49:30  Show Profile  Visit Rob's Homepage  Reply with Quote
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.
Go to Top of Page

Firepawa

4 Posts

Posted - 08/20/2013 :  20:24:17  Show Profile  Reply with Quote
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.
Go to Top of Page

Rob

USA
2380 Posts

Posted - 08/20/2013 :  20:28:39  Show Profile  Visit Rob's Homepage  Reply with Quote
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!
Go to Top of Page

Firepawa

4 Posts

Posted - 08/20/2013 :  20:55:42  Show Profile  Reply with Quote
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).
Go to Top of Page

Rob

USA
2380 Posts

Posted - 08/20/2013 :  21:05:56  Show Profile  Visit Rob's Homepage  Reply with Quote
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.
Go to Top of Page

todd

1 Posts

Posted - 12/02/2014 :  13:39:57  Show Profile  Reply with Quote
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
Go to Top of Page

schumaml

1 Posts

Posted - 04/13/2017 :  04:58:16  Show Profile  Reply with Quote
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.
Go to Top of Page

Rob

USA
2380 Posts

Posted - 04/13/2017 :  08:56:34  Show Profile  Visit Rob's Homepage  Reply with Quote
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.
Go to Top of Page

Rob

USA
2380 Posts

Posted - 04/13/2017 :  11:34:08  Show Profile  Visit Rob's Homepage  Reply with Quote
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.
Go to Top of Page
   Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
StrokesPlus Forum © 2011-2016 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000