Hi,
Is there a way to hold pressing the mouse for a while, then release. Now the mouse acts as if it is always pressed. When you move the mouse, it will drag around. When you click the mouse again, it will return to normal.
Windows7 has this mode for accessibility.
Thanks,
Be more specific.
– Thomas Adam
For example, if I click the title bar of a window and hold it for more then 750ms, the “H” event will be triggered. I put something in this function
AddToFunc Move-or-Raise
hoping that even after I release my mouse, the window is still in move mode. When I move the mouse, the window will move along the mouse. Once I am done, I click the mouse again. Now the window is put down.
The same applies to resizing.
Hope it is clear.
I see. It can’t be done.
– Thomas Adam
Do you think it is useful? How to ask to have this feature?
It’s not useful, and due to how functions work anyway, you can’t ever -have- this feature.
– Thomas Adam
This should work for Titlebars.
Mouse 1 T A Temp1
DestroyFunc Temp1
AddToFunc Temp1
+ H Function Temp2
DestroyFunc Temp2
AddToFunc Temp2
+ C MoveNo. This is completely dependant on ClickTime – and you don’t need the extra function to do it. There is no timeout you can apply here – the mouse is always grabbed hard and fast.
Why don’t people listen?
– Thomas Adam
Hi Thomas,
Don’t mean to cause you hassles, just trying to understand.
I’m not sure how to go about doing what I’ve done in a single function, but that’s a separate issue for now.
I do understand this is dependent on ClickTime. I also see that you can just whack the Move command in the actual binding and just click the titlebar rather than hold. But why is my example wrong or bad if it has the functionality he’s asked for?
I know he can’t set any times independent of ClickTime, but that’s not a show stopper. I’m not sure I understand your use of “timeout”. I assume you mean how long the button must be held before it theoretically activates the Move command.
Because the timeout once the function has happened means you can’t then do an action, set a delay, and then undo it again, because the function itself has grabbed the pointer. It’s grabbed immediately.
The point of ClickTime is that this only applies beforehand.
So even though your suggestion is fine, it still won’t do what’s asked.
Did I suggest reading the wiki? I can’t remember now, but I’ve documented all of this there already.
– Thomas Adam
I’m reading through the wiki now. I assume you’re referring to the “Function Caveats” section. I’m reading and slowly maybe comprehending it (I’ll keep re-reading, dont worry.)
The first thing I’m understanding from it is that the XServer isn’t going to let anything else happen in the middle of the function. Eg. I run/start a GUI program, but then perform the function before the program has had a chance to pop up on the screen. The XServer is unable to complete opening the program until the function is completed.
I’m not sure if that is what you’re getting at in this particular case though.
The function(s) exactly as I have written it, behave just as I would expect (including the above caveat.)
If I single click the titlebar, nothing happens.
If I click and hold the titlebar for the amount of time set in ClickTime, I can then release the click and freely move the window around the screen. A single click then places the window in its new position.
I’ll keep reading through the wiki because I don’t quite understand this:
Thanks for trying to explain.
P.S. There are some extra links in the wiki’s list of main pages that seem to be spam/advertising.
It’s entirely possible I’ve just misunderstood what was being asked.
In which case, I’ve already given the answer without realising it – functions grab the pointer for the duration of their operation, which means you can wrap commands like move and resize in a function, and clicking and releasing the mouse at the point the operation happens (which is always in a function context) means it’s locked into doing that function until the operation in it has completed.
Outside of the function – if you just had:
Mouse 0 foo bar MoveYou cannot then just click the mouse, have the window move and then click to end the action – you’d have to keep the mouse button down for the entire duration the window needs to be moved for, because the server is not grabbed in the same way.
ClickTime comes into its own here in the amount of time that’s considered a click to perform an action – it has nothing to do with the content of the function – I think the English of the original poster threw me. In the case of +H the timeout is considered before the action takes place.
Not true. You can do this:
DestroyFunc foo
AddToFunc bar
+ C Exec exec foo
+ H Exec exec barThe point of the XServer being grabbed simply means that some other application cannot grab the pointer, if it were to, we’d be switching context, and then we’d be forcing an operation on a window which was never meant to receive the action in the first place. That’s bad.
At this point though – go and read the FunctionSynchronisation page on the fvwmwiki (fvwmwiki.xteddy.org/fvwmwiki/Fun … onisation/) to find out more about PipeRead.
It’s only myself who seems to do anything to that wiki – so I’ll fix it later. However, since it is a wiki you could also remove the spam in question.
User contributions… that’d be a first.
– Thomas Adam
I’ll get to the rest of it tomorrow, but I can definitely do this using:
Mouse 1 T A MoveTo move a window from the titlebar while holding the mouse button down I have to use a function with:
Is this not normal?
Again – if you want to do it so you can release the mouse button and still move the window, you have to use a function to do it because the pointer is grabbed, right from the point the command (Move, in this context) is issued.
If you don’t want that, then bind “Move” directly, which is what you just did.
Both cases are valid – the case of using a Function to do it indicates the side-effect of how functions work internally.
There’s only so many ways I can phrase this – so if you still don’t get it, I’ll try and rephrase it – patronisingly or otherwise.
– Thomas Adam
I really don’t think I misunderstood. You said it can’t be done that way, then you said it could when I questioned it.
I’m cool with patronising if it comes down to it. Hopefully my responses don’t come across as ungrateful. I really appreciate your help.
I’ve carefully read through this thread again, as well as the four main function pages in the wiki. I believe I have a reasonable grasp of your points. I can’t work out how any of what you’ve said in this thread or the wiki has any bearing on how the “accessible window move” functions that I suggested operate.
I do grasp the points you’re putting forward, but I can’t see how they relate to the functions in question.
I don’t suppose you could show how the same functionality could be achieved in a single function? I’ve been trying to wrap my head around how that would work, but can’t quite get there.
Once more, then:
MoveNo grab of the pointer, which means it has to be held down for the entire time the window needs to be moved. You cannot release the mouse pointer and expect the window to still move – instead, releasing the mouse pointer confirms the window’s moved position.
DestroyFunc fo
AddToFunc foo I Move
fooHere, calling “foo” will immediately grab the pointer, and execute the Move command, this grab is still enforced whilst the Move command is happening, so one is free to release the mouse and still move the window, and then must click the mouse to confirm the window’s position. At this point, the grab is released and the function ends.
There is no other way for me to explain this.
In the case of some random timeout needed before an action happens, well:
– Thomas Adam