darcs patch: Decoration: add a mouseEventHook methohd... (and 2 more)

Hi,
these 3 patches are going to enable mouse dragging of decorated
windows. Mouse dragging is going to work only with layouts using the
windowArranger layer (obviously), which, at the present time, means
only the SimpleFloat - and any layout using SimpleDecoration together
with the windowArranger. DwmStyle is obviously excluded (see below to
understand why).
Since I'm experiencing some problems with focus changes and decoration
I'm not pushing till I have some tester confirming I'm not breaking
anything with those patches.
The first patch is just for moving code: I added a mouseEventHook
method to the DecorationStyle class (does it make sense? I thought
different styles may have different event handling mechanisms).
The second is just to enable mouse UI support in the windowArranger.
The third should be safe: if the decoration we are clicking on is the
decoration of the focused window we start grabbing it with the mouse.
If it is not the focused window we focus it.
The problem is that focus change, here, seems to be broken: the focus
changes but the decoration colors do not, as if the decoration state
was not being updated. I thought that could be related to issue #111
(by reading David's patch description) and I changed broadcastMessage
to sendMessage in Main.handle. Still I didn't notice any effect (but I
need to double check since perhaps I'm messing up my source trees).
This is going to interfere with mouseDrag, which will check the
decoration state to see if a decoration belongs to the focused window.
One more thing: now, when I start dragging I do not calculate the
distance between the mouse and the origin of the window, and so, at
first, the window origin will abruptly change to reflect the mouse
position. I know it's probably just a line of code but I didn't write
it so far...
I also need some advise on how to implement mouse resize: how do other
WMs handle that? Should I check for a small area around the window's
border? Just an area around the bottom right corner? Any idea?
Cheers,
Andrea
Fri Feb 8 08:35:14 CET 2008 Andrea Rossato

On Fri, Feb 08, 2008 at 12:49:09PM +0100, Andrea Rossato wrote:
The problem is that focus change, here, seems to be broken: the focus changes but the decoration colors do not, as if the decoration state was not being updated. I thought that could be related to issue #111 (by reading David's patch description) and I changed broadcastMessage to sendMessage in Main.handle. Still I didn't notice any effect (but I need to double check since perhaps I'm messing up my source trees).
it was me messing up my trees, indeed. I just checked and focus change works just fine here. so my patches seem not to be breaking anything and I'm going to push if no problem arises.
One more thing: now, when I start dragging I do not calculate the distance between the mouse and the origin of the window, and so, at first, the window origin will abruptly change to reflect the mouse position. I know it's probably just a line of code but I didn't write it so far...
should be easy (but my first attempt did not produce nice results: the window jumped out of the screen... maybe something wrong with my math...;) Andrea

On Fri, Feb 08, 2008 at 01:49:12PM +0100, Andrea Rossato wrote:
One more thing: now, when I start dragging I do not calculate the distance between the mouse and the origin of the window, and so, at first, the window origin will abruptly change to reflect the mouse position. I know it's probably just a line of code but I didn't write it so far...
should be easy (but my first attempt did not produce nice results: the window jumped out of the screen... maybe something wrong with my math...;)
Maybe it is the easiest thing to do, maybe it is even impossible. Who knows... I do not and I think I'll leave to those guys, here, who have some memory of analytic geometry, because at the present time I'm quite confused on the matter...;) BTW, pushed. So now we have some basic mouse dragging support (with that small initial jump, which makes xmonad such an interesting WM in the WMs' world). Andrea ps: suggestions on how to implement mouse resize without having to write tons of code are *highly* appreciated. :-)

On Feb 8, 2008, at 8:45 , Andrea Rossato wrote:
On Fri, Feb 08, 2008 at 01:49:12PM +0100, Andrea Rossato wrote:
One more thing: now, when I start dragging I do not calculate the distance between the mouse and the origin of the window, and so, at first, the window origin will abruptly change to reflect the mouse position. I know it's probably just a line of code but I didn't write it so far...
should be easy (but my first attempt did not produce nice results: the window jumped out of the screen... maybe something wrong with my math...;)
Maybe it is the easiest thing to do, maybe it is even impossible. Who knows... I do not and I think I'll leave to those guys, here, who have some memory of analytic geometry, because at the present time I'm quite confused on the matter...;)
Don't calculate. ButtonPress and ButtonRelease events include the (x,y) coordinates relative to the receiving window, which is the offset you want to keep as you drag. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Fri, Feb 08, 2008 at 10:43:09AM -0500, Brandon S. Allbery KF8NH wrote:
Don't calculate. ButtonPress and ButtonRelease events include the (x,y) coordinates relative to the receiving window, which is the offset you want to keep as you drag.
Thanks for the tips! The problem is that now I have to study how to relate that with the fact I'm moving the decorated window - while the receiving one is a decoration. But I'm getting closer. Cheers, Andrea

On Feb 8, 2008, at 6:49 , Andrea Rossato wrote:
I also need some advise on how to implement mouse resize: how do other WMs handle that? Should I check for a small area around the window's border? Just an area around the bottom right corner? Any idea?
Pick one. :) (or both, via separate contribs) Some window managers use one, some the other. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
participants (2)
-
Andrea Rossato
-
Brandon S. Allbery KF8NH