Hi,

Marco Munari writes:

I notice that mouse navigation tool, in the lower right corner of drawing window, could be improved in usability: before drag the viewing area is better to save the mouse position, restoring it after viewable area is moved and mouse released.

i mean the mouse pointer in navigation preview shortcut is absolutely not moved to change the mouse pointer context.

I'm not sure if warping the mouse cursor would be an improvement in useability. Usually doing so is considered a bad thing by user interface guidelines.

I think it's better that after the use of ccorner view drag tool, the mouse stay in the used tool, don't you think so?

what do you mean when you say 'mouse stay in the used tool' ??

gdk:
gdk_fb_mouse_get_info (&winx, &winy, mask);

xlib: XQueryPointer( dpy, w, &root_win, &win, &x, &y, &win_x, &win_y, &state_mask )

these are function to retrieve the pointer position, but they don't allow to set it. There's no way we will introduce calls to the GdkFB layer or let alone Xlib. Of course there's a way to get the pointer position using plain GDK, but I think there's still no way to warp the pointer to a different screen location.

Salut, Sven

mar@cf.nettuno.it (2002-11-25 at 0259.10 +0100):

I notice that mouse navigation tool, in the lower right corner of drawing window, could be improved in usability: before drag the viewing area is better to save the mouse position, restoring it after viewable area is moved and mouse released.

...

I think it's better that after the use of ccorner view drag tool, the mouse stay in the used tool, don't you think so?

Let me try to understand it:

+-------------------------+ it is, but not exactly there.

If there is a thing to change, it is to let the cursor go out of the preview if the user keeps dragging, thus make screen / mouse relation more tied, not less.

GSR

Hi,

"Guillermo S. Romero / Familia Romero" writes:

If there is a thing to change, it is to let the cursor go out of the preview if the user keeps dragging, thus make screen / mouse relation more tied, not less.

might make sense. Another thing to change is that we currently try to open the preview window in such a position that the pointer is in the correct spot within the navigation preview. This approach is doomed to fail if the image window is close to the lower or right edge of the screen. We should probably warp the pointer if this happens.

Salut, Sven

sven@gimp.org (2002-11-25 at 2042.06 +0100):

correct spot within the navigation preview. This approach is doomed to fail if the image window is close to the lower or right edge of the screen. We should probably warp the pointer if this happens.

Would not make more sense something like in drop menu (the one used for layer modes, if out of screen, it scrolls in as you keep / push the pointer in the border)? Maybe too complex.

But at least "happy warping" should be avoided if possible, that is sure.

GSR

Sven Neumann writes:

I'm not sure if warping the mouse cursor would be an improvement in useability. Usually doing so is considered a bad thing by user interface guidelines.

OpenLook on SunOS used to do this by default. It was fast, but took a lot of getting used to. You have to find the cursor after every move, which is annoying. Dropping the mouse cursor where you consider it needed next is doubly annoying if the user wants to do something else (perhaps unrelated to your program).

On 11/25/02 06:23, Sven Neumann wrote:

position using plain GDK, but I think there's still no way to warp the pointer to a different screen location.

It's been quite some time since I've done any X programming, but I recall having a function that would bound the pointer within a box. Should this exist, you could bound the cursor and then release it, perhaps after a motion event (I'm not sure how immediately the bounding event happened). :-\

Chris

Hi,

"Christopher W. Curtis" writes:

On 11/25/02 06:23, Sven Neumann wrote:

position using plain GDK, but I think there's still no way to warp the pointer to a different screen location.

It's been quite some time since I've done any X programming, but I recall having a function that would bound the pointer within a box. Should this exist, you could bound the cursor and then release it, perhaps after a motion event (I'm not sure how immediately the bounding event happened). :-\

please keep in mind that we don't do any X programming here; we need a GDK equivalent. IIRC, you can confine the pointer into a GdkWindow when calling gdk_pointer_grab(). However I did not understand your argumentation above. Are you saying that we should try to warp the pointer by using this functionality?

Salut, Sven

On 11/26/02 08:56, Sven Neumann wrote:

Hi,

"Christopher W. Curtis" writes:

On 11/25/02 06:23, Sven Neumann wrote:

position using plain GDK, but I think there's still no way to warp the pointer to a different screen location.

It's been quite some time since I've done any X programming, but I recall having a function that would bound the pointer within a box. Should this exist, you could bound the cursor and then release it, perhaps after a motion event (I'm not sure how immediately the bounding event happened). :-\

please keep in mind that we don't do any X programming here; we need a GDK equivalent. IIRC, you can confine the pointer into a GdkWindow when calling gdk_pointer_grab(). However I did not understand your argumentation above. Are you saying that we should try to warp the pointer by using this functionality?

I think "should" is too strong a word. You said that there was no way to do it. Well, this might be a way. An ugly hack, perhaps, but a way. If you really wanted to do it and had no other means to ...

Whether or not this *should* be done I'll leave up to you.

Chris