When I move the mouse over a break window, it does not move away

once I got it to move away by clicking on it, but I could not reproduce that 
behaviour (It jumped to the upper left corner. being used to wp, I didn't 
expect it to go there, but I guess it's acceptable :-) )

Works fine under Linux. This is probably a bug in GDK/GTK+ on win32.
enter_notify events don't work under win32...

Fixed. 
I must admit, it jumps around not exactly the way I programmed it to do. :)

In the linux version, now ALL windows move. This includes the MP/RB windows with
insist and buttons. The buttons are very hard to use this way....

I tried adding "set_avoid_pointer(false);" to RestBreakWindow::start(). It
didn't help...

It still is possible to enter the prelude window, without it jumping away. 
Admittedly, it's much more difficult than before.

One other problem: The text cursor is ignored. The prelude window just sits 
there in the middle being very annoying.

wp solves this by jumping away after a few seconds, regardless of mouse 
actions. When the prelude window is near the border of the screen, it is far 
less annoying :-)

The prelude window does jump away automatically, did so since the beginning.
Reporter, please confirm this.

I can confirm that there is one way to enter the prelude window:
- x=middle, y=bottom => you can enter from the left.

Technically, you are correct. The window does jump away. However, it takes much 
longer to do so than with wp. I propose to make it jump away sooner.

As for the x=middle, y=bottom stuf: It doesn't always work, and I don't think 
it's the only way, either.

Is it at all relevant from which side you enter?

gdk_window_get_pointer was unreliable, now using native W32 call.

Now, it is indeed impossible to move the mouse over a prelude window. 
Nevertheless, I'm still not entirely happy.

First of all, the prelude window stays too long in the middle of the screen 
before automatically jumping away. I think it should jump after one, maybe two 
seconds, but not much more.

When attempting to move the mouse over the prelude window, It jumps to a lot of 
places, all on the right hand side of the screen, following some kind of zig-
zag pattern. Two things can be said about that:
- there are a lot of places where the window is possibly displayed. 
- most of them are not at places where a user would see them (the border of the 
screen outside the area I'm usually paying attention to).

I guess, what I'm trying to say is, that if the prelude is near the border of 
the screen, I have to go look for it, because it is not "in view". With the 
current algorithm there are a lot of places I need to look.

I guess I'm going to advocate (once again :-) wp behaviour, where the prelude 
is either in the middle of the screen, or at the top of the screen. This way, 
the amount of searching on my part is minimized.

Ok, I forgot to have the prelude window moved automatically. Will be fixed.
Also, I will check why it is zig-zagging, as it shouldn't.  You should be able
to "push/shove" the prelude whereever you want.

> most of them are not at places where a user would see them (the border of the 
screen outside the area I'm usually paying attention to).
> I'm going to advocate (once again :-) wp behaviour, where the prelude 
is either in the middle of the screen, or at the top of the screen. 

The current behaviour is desirable, it is actually a feature. It doesn't really
show because of the zig-zagging, though, but that will be adressed. 

You don't always want to be disturbed by the prelude. So, you want to be able
shove it whereever it doesn't bother you. The top and center are not desirable
places. For example, when browsing the net, the top is your address bar, and the
center is the page itself.

Shoving is the way to go. I think it is wwwaaaay overkill to make this
configurable. What will become configurable is the _initial_ location of the
break windows (micro-pause, rest break and prelude).

The prelude jumps aways sooner now. This is a great improvement. However, 
I'm still not entirely happy. (You didn't expect me to, did you?)

When I first evaluated the new behaviour, it felt like it was still zig-
zagging, only this time the entire screen was used, instead of just the right 
half. Then, I asked Raymond the algorithm behind it:

> mouse coors = x,y
> prelude window center = cx,cy.
> je duwt het p-window langs de lijn (x,y),(cx,cy)
> als p-window tegen border aanloopt.. flipt ie naar andere kant.

This behaviour is recognisable :-). However, whenever you push the window, it 
jumps away way too far. This way, it is very hard to put the window precisely 
where you want it.

There also are some more minor remarks:

1. I don't think pushing along the line (x,y),(cx,cy) is a good idea. For 
example, if I'm moving my mouse on an exact horizontal line, but I'm not 
hitting the prelude box precisely in the middle, then the prelude box will also 
have some vertical movement, with the ultimate result of "falling of my mouse 
pointer". I think it would be better to move the window in the same direction 
and the same amount the mouse pointer is moving.

2. When moving fast enough, it is possible to move over the prelude window 
without it moving. This is somewhat annoying, because this is the way I 
currently work. When a prelude appears, I wave at it with the mouse, and then 
it should jump to the correct location. wr either doesn't move at all, or in 
some random direction, because of the uncoordinated wave and the pushing 
algorithm.

3. I'm not sure flipping to the other side is a good idea. Especially with the 
current large jumps, this gives a behaviour that appears random. Reducing the 
jumps should help. Placing the window partially off-screen might also help. 
Clipping to the screen (no flipping at all) might also be an acceptable 
solution.

I agree, I also didn't really like the new solution. In my 639th try to address
this bug, I'll do the following:

There will be nine places ("O") where the prelude can be positioned:
O-O-O
|X|X|
O-O-O
|X|X|
O-O-O
You can push the prelude from one O to the other O. The algorith is to determine
where to jump to will be the same as currently present.

So, in practice, this boils down to the current solution, but with the positions
restricted to a 3x3 grid.

Btw, you are talking about large jumps. IMHO, they should be large. If the mouse
pointer is there, that means that you are trying to work in that area. The
prelude should _not_ interfere, and move the h*ll out...

You're mixing two different concepts.

1. "I'll go wherever you push me" -- In this concept, the user has to have fine-
grained control over the pushing, otherwise you get apparent random behaviour.

2. "I'll get out of the way" -- In this concept, the window jumps to the "right 
place". The user cannot be expected to indicate which place is the right one. 
Large jumps are allowed, if they lead to "the right place".

The most obvious "out of the way" location is an invisible prelude. If you want 
to go this way, I propose to make the prelude invisible if it has to jump away 
more than two times. If you like, you can turn the sheep in the system tray red 
to indicate that there is an invisible prelude. This approach is especially 
desirable if the prelude is going to disappear anyway. If a break is going to 
be forced, you probably don't want this.

The "I'll go wherever you push me" is pointless if you have a good
implementation of "I'll get out of the way". Why? Because you'll only want to
place it on a specific place if the current place interferes with your working
activities. 

> The most obvious "out of the way" location is an invisible prelude.

I don't agree, the prelude should somehow be irritating enough not to be
ignored, but it should be not irritating enough to obstruct your working activities.

IMHO, my proposed grid approach does just that.

Kees-Jan, you were right all along, almost:

> I guess I'm going to advocate (once again :-) wp behaviour, where the prelude 
> is either in the middle of the screen, or at the top of the screen. This way, 
> the amount of searching on my part is minimized.

There are now only three places where the window can be:
- Initially it appears in the middle.
- If  you continue working, it auto-jumps to the top of your screen. 
- If your pointer enters the window, it jumps to either the bottom/top.

That's it.. no grid, no more sin()/cos() to determine how to push the window in
a direction.

Finally!