StrokeIt + Firefox + FireGestures

Hello,

Can I use StrokeIt with Firefox while still let FireGestures add-ons function?

So the gestures in [Global Actions] is for StrokeIt to handle, but every others gesture is forwarded to Firefox FireGestures add-ons.

Only if the trigger buttons for those two are different. If they use the same you have to decide which one to use and disable the other. Their gesture engines have no knowledge of each other's presence, and even if they'd have, they would not know each other's set of gesture therefore they cannot decide which one of them should execute its action in case you make a gesture that both of them know.

I would not recommend using any other gesture application (be that standalon, plugin or extension) than StrokeIt. You can easily make StrokeIt do the same things that other app does on the same gesture.

Oke, I understand. Thanks for yours explain.

For now I will put firefox in the disabled apps group and continue to use firegestures add-ons. I may however switch completely to StrokeIt later on.

Thank you.

002 Wrote:
-------------------------------------------------------
> For now I will put firefox in the disabled apps
> group and continue to use firegestures add-ons. I
> may however switch completely to StrokeIt later
> on.

Out of curiosity, what feature of firegestures do you find better than strokeit?

For instance, if I remember correctly, it does not have \ or / (these are recognized as horizontal or vertical gestures (left/right/down/up).

Yes, diagonal gestures are an important feature missing in FG. The FF extension Mouse Gestures Redox, however, does have them. The advantages of FF mouse gesture extensions over StrokeIt is that it is much easier to program them to do context-sensitive things in FF, such as opening a link in background, going to the next results page in Google, or opening all links within a selected text. But StrokeIt can do nearly all those things, with Lua scripting (which I have never been able to do) or Autohotkey. Moreover, StrokeIt is usually more reliable, and faster.

That said, I am still using the FF Easy Drag To Go extension for opening links: drag a link up with the left mouse button to open in new foreground tab, down for background; drag an image right to save it to disk, drag it left to view it in new tab; drag selected text up to search for it in Google, right for dictionary.com, left for Ebay, etc. etc..

Cerberus Wrote:

> The advantages of
> FF mouse gesture extensions over StrokeIt is that
> it is much easier to program them to do
> context-sensitive things in FF, such as opening a
> link in background, going to the next results page
> in Google, or opening all links within a selected
> text. But StrokeIt can do nearly all those things,
> with Lua scripting (which I have never been able
> to do) or Autohotkey.

I also use the FF Easy Drag To Go extension and would like to do the same in Opera and other browsers. The problem is to get the object at the starting point of the gesture. With Autohotkey I can get the coordinates and do for example a shift+click at that position to open a link in a new tab, but it would be much better if I could do different things depending on whether there is a link or an image or whatever at the cursor position. Does anybody know how to get the DOM object in Autohotkey?

Probably it is possible in LUA, but LUA seems to be very difficult for beginners. I would like te see some easy to use code snippets in the wiki.

If someone would be so kind to describe the gestures and the corresponding actions, I will try and see what can be done to implement them somehow using StrokeIt + Lua (if I can spare some time at the weekend, of course :)

I don't think there's an easy way to access a DOM element from an external program without creating/installing a firefox plugin to proxy the request for you.

Even then there's no friendly GetDomElementAtPoint() sort of function. I created something similar for K-Meleon many years ago when I created StrokeIt, but it was a really gross kludgy hack that just simulated a mouse event and let that bubble up to the topmost DOM element.

That was a long time ago. There may be some friendly plugin available today that makes this possible.

Alternatively, you could bypass the DOM stuff altogether. Just send a "right click" to the gesture starting point and check that context menu for items like "Copy Link Location", "Copy Image Location", etc to determine whether or not you're over a link, image, or whatnot.

-- Jeff

jeff Wrote:
-------------------------------------------------------
> I don't think there's an easy way to access a DOM
> element from an external program without
> creating/installing a firefox plugin to proxy the
> request for you.

I think a UserJavascript can do this. JS can find the element under the cursor very easy, and this can be started from outside by a hotkey.


> Alternatively, you could bypass the DOM stuff
> altogether. Just send a "right click" to the
> gesture starting point and check that context menu
> for items like "Copy Link Location", "Copy Image
> Location", etc to determine whether or not you're
> over a link, image, or whatnot.

That seems to be more reliable. The menu will flicker, but I'll check that out. I'm sure that can be done with Autohotkey. Thanks for your offer, gemisigo.

hi all,

I really love Firegestures add-on and it's hard to get rid of it.
I've try to imitate all gestures from FG as much as is posible but sometimes is very hard to do it, because configuration of FG is definitely easier than Strokeit.
So, I think there is some way to go for a kind of compromise witch allow to use both gestures:
FG and Strokeit at the same time!

As I said, it's about compromise so this solution belove is NOT so perfect but works pretty well after spending few minutes on practicing...

So, first off all...
It's good to add to Strokeit basics firefox gestures like e.g "new tab", "close tab", "close window", "minimize", "maximize", "reload page", "refresh", "next tab", "previous tab", "back", "forward", "stop" etc.
These are common keyboard shortcuts, so it's simple to add.

Next...
Of course we can set different trigger button for FG and Strokeit but I think most of us rather prefer to use right button for gestures than left :)
So, as we know, when we use the same button, gestures from Strokeit are execute in a first place and those from FG not works.
But when we wait e.g 250 ms (sets in Strokeit by default) until Strokeit's gesture will expire, then we can use (continue) Firegesture!

So, the solution is to sets "gesture timeout" in Strokeit for 250 ms (or even less if you're "speedy gonzales"), and for Firegestures sets this value for e.g 1000 ms and when these 250 ms for Strokeit expire, then we can continue to making gesture by using FG :)

These bacics firefox gestures witch we already configured in Strokeit will works imediately because there are making by Strokeit and for other (not configured in Strokeit) we will have to wait e.g. 250 ms in order to Firegetures starts work when "gesture timeout" for Stroke simple expire.

As I said, it's some kind of compromise but works pretty well.

Kind Regards

Kaboom, that is a great idea, I had also thought about trying it some time ago but never got to it. Currently I am using a combination of StrokeIt, Autohotkey, and the FF add-on Easy DragToGo to do nearly all of what Fire Gestures used to do.

Could you name a few of the most important functions of Fire Gestures that StrokeIt cannot do?

Being honestly, I'm not sure if Strokeit can not do something stricly reserved for Firegestures witch isn't simple keyboard shortcuts (the most important function).
But I have no doubt that FG is defiitely more user friendly to configure Firefoxe's gestures than Strokeit. (of course that's only my subjective opinion but I think true)

In FG there're already pre-configured planty gestures.
Some of them are very useful hybrid-gestures witch allow to set even more than 2 actions for the same mouse gesture depends on situation e.g. when we start to make gesture (on empty space on site, on link, on selecting text etc.)

So I think it will be hard for Strokeit to deal with it without spending a lot of time with DOM inspector in hand.
So, definitely it's a better and more natarual choice to stick with Firegestures for Firefox

Hi all,

So, there is no way to disable StrokeIT mouse gestures when using Firefox?

Ah, never mind, I have found it :)

HELP ME!!!. I don't want to use firegesture but I have to. the reason? i want to use the same move to close a tab in firefox or close any other windows:
(down-left ==>alt+F4)
if I try to use only strock-it, and put the ctrl+w in firefox move to close the tab, it give priority to the global action ((close window (alt F4).

so my problem is that I want to use strock-it also with firefox 'cause I have lot of global-shortcuts that firegesture can't make.

How could I do to keep the alt-f4 for every applications to close window, except for firefox that I want to close Tab?

Hi!
Gestures assigned to applications other than [Global] (Default.cfg) override those defined in [Global]. Take care not naming you application starting "[" in which case it can be [Global] that overrides your actions. I use CTRL+F4 to close tabs in FF and it is assigned to the same gesture (Down-Right) that closes windows otherwise. It works flawlessly. It might be that your FF application is not identified correctly in FF. Add an OSD command to your action to see if it is triggered at all.

Gemisigo is right: Strockit is able to do what you want. I didn't know applications starting with " [ " could be overridden by Global gestures!
I like to have a dedicated gesture C myself for closing any window, including FF, but I have Down-Right set to close a tab in FF and Opera, and close a document in Notepad++.

Hi Cerberus!
I said that because of my experiences. I noticed that StrokeIt uses a 1-level override, that is, it overrides the gestures that are closer to the top of the Command Editor with those that are closer to the bottom in case they would both apply.

[Global Actions] apply to all windows that do not have their app window disabled in StrokeIt and if they have another app that identifies them, StrokeIt overrides the global actions (providing there are actions with the same gesture in the app). According some experiment with that this override is 1-level only, meaning that it overrides with the first occurrence and any subsequent occurrences are ignored. Apps that identify the same window having actions with gestures already defined earlier ([Global Actions] and some app that is higher in the app tree) are not triggered.

Based on that, if you define an app called [FF] or [FireFox] it will end up higher in the tree, hence it could be overridden by (and not override) [Global Actions]. It might be the reason vesuve666's gestures don't work in FF.

I also noticed that apps without Application Identifiers do not behave as if they were global. They just do not fire, regardless the same gesture being overridden by [Global Actions] or other apps or not. Therefore my observations might not be valid for [Global Actions]. WARNING!!! I did NOT check that yet, so please, do not take it as a fact!

Gemisigo, that is very interesting! I didn't know it worked like that. So do I understand correctly if I assume the following.

Suppose I made two applications: one (FF) that recognized any Firefox window, and another (FF Gmail) that only recognized a Firefox window when Gmail was in its title. Suppose I created an action that would close the window in the general FF application, and another action that would delete an e-mail in FF Gmail. Suppose also that I had assigned the same gesture for both, and that this gesture existed as a Global gesture as well. Both applications would just be named FF and FF Gmail, no square brackets [ ].

If I then did this triply-defined gesture while Gmail was active, it would simply close the window, because it can only go as far as the second application (FF), and the third one (FF Gmail) gets ignored, because it is third in line, even though it should override the first two: is that right?

Sort of. I did something similar you described here but with OSD commands to see what happens. The results suggested that this assumption is correct. No extensive research or torture test was taken though :)

Okay, thank you for testing! At least we should be aware that this could be a problem in some set-ups. It is a pity, in a way, that we can't have StrokeIt configured differently for different websites. Oh, well.

Not exactly. It's a bit more complicated than that. You can configure it to use the same gesture with different actions for different websites as long as it is not defined as global for the browser. If it is defined in [Global Actions] and also defined in Browser global (FF in your case) the Browser global overrides [Global Actions] and it is executed. If it is not in [Global Actions] but in Browser global there is no override of [Global Actions] and it simply gets executed. Now if it is in [Global Actions] and not in Browser global but in WebsiteXY (identified by window title) then the override triggers. Therefore it works with some restrictions.
But I repeat, this is just a theory. I tested a few things but most of these is based on those few tests and some experience. It is very far from complete. In case you want to do something special you'll have to test it.