java-gnome-hackers

[java-gnome-hackers] MouseButton improvements

[Vreixo F. <met...@ya...>]

Dear all,

I send you this tiny patch that changes MouseButton constant, according
to:

1- I have deprecated constants for mouse buttons 4 and 5 (wheel), as
they, together with buttons 6 and 7, are not mapped to mouse-clicks
events, but to scroll-event, so it makes no sense to treat that as mouse
buttons. Or do you know any case where these constants make sense?

2- I have added constants for mouse buttons 8 (BACK) and 9 (FORWARD), as
many new mice have such buttons, and not including them causes an
exception to be thrown. I have not named it EIGHT or NINE because I
really think that using the name the user expects (in the same way we
have done with LEFT click, MIDDLE, etc) is a better option.

What to you think about these changes? Do you agree? Does any of you
have a mouse with more than 9 buttons? If so, can you provide meaningful
names for those?

Andrew, I'd like to propose this patch for mainline, btw

Cheers
Vreixo
 

Re: [java-gnome-hackers] MouseButton improvements

[Andrew C. <an...@op...>]

On Sun, 2009-05-17 at 17:56 +0200, Vreixo Formoso wrote:
> I have added constants for mouse buttons 8 (BACK) and 9 (FORWARD), as
> many new mice have such buttons, and not including them causes an
> exception to be thrown. I have not named it EIGHT or NINE

Sure. If you've got a reasonable name for them, that's excellent.

>     /**
> -     * Mouse button <code>4</code>.
> +     * Mouse button <code>4</code>. Do not use this, connect to
> +     * {@link ScrollEvent} instead.
>       */
> +    @Deprecated
>      public static final MouseButton FOURTH = new MouseButton(4,
> "FOURTH");

So,

1. If you're going to mark something deprecated, use the JavaDoc
@deprecated tag please. That way you'll be consistent with everywhere
else in the library.

and,

2. Good of you to say "what to use instead". We don't generate javadoc
for deprecated methods, but it'll be good if someone is hovering over a
deprecated constant.

but,

3. I'm not sure that these should to be deprecated. Do these
ButtonPressEvents not get generated anymore? They still get emitted, *as
well as* ScrolledEvent, right?

Certainly the text about "what you really want is..." and a @link is
excellent.

4. What happens if you scroll the mouse wheel in a window without a
Viewport & Scrollbar? Do you still get ScrollEvent?

Otherwise, yes, this is great.

AfC
Sydney

[java-gnome-hackers] Res: MouseButton improvements

[Vreixo F. L. <met...@ya...>]

Hi!



> 3. I'm not sure that these should to be deprecated. Do these
> ButtonPressEvents not get generated anymore? They still get emitted, *as
> well as* ScrolledEvent, right?

No, afaik. I cannot get a button-press-event for those buttons, for example... 


> 4. What happens if you scroll the mouse wheel in a window without a
> Viewport & Scrollbar? Do you still get ScrollEvent?

Yes, it seems those buttons are always mapped to an scroll-event. In fact, from devhelp documentation:

"The ::scroll-event signal is emitted when a button in the 4 to 7
range is pressed. Wheel mice are usually configured to generate 
button press events for buttons 4 and 5 when the wheel is turned.
"

The second sentence is not clear, as I never receive the button press events. I guess it refers to "mouse wheel is usually configured in X to generate button press events, that we map (in GDK)  to scroll events".

In fact, looking at gdk sources I found this piece of code, that belongs to function "gdk_event_translate" (that I guess it translates X events to GDK events):


  switch (xevent->type)
[....]

    case ButtonPress:
[......]
      
      /* If we get a ButtonPress event where the button is 4 or 5,
     it's a Scroll event */
      switch (xevent->xbutton.button)
        {
        case 4: /* up */
        case 5: /* down */
        case 6: /* left */
        case 7: /* right */
      event->scroll.type = GDK_SCROLL;
       [.............]

        default:
      event->button.type = GDK_BUTTON_PRESS;

[....]
(piece of code from gtk+-2.16.1/gdk/x11/gdkevents-x11.c)
        
So it seems that those buttons always generate scroll events, and only scroll events.
I don't know, however, whether some special configuration can change this behavior, although I don't think so.

Cheers
Vreixo


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: [java-gnome-hackers] Res: MouseButton improvements

[Andrew C. <an...@op...>]

On Mon, 2009-05-18 at 09:23 +0000, Vreixo Formoso Lopes wrote:
> > Do these
> > ButtonPressEvents not get generated anymore?
> 
> No

> In fact, looking at gdk sources I found this...

Great job doing the research on this.

So definitely go ahead with deprecating them and moving the emphasis to
ScrollEvent.

Cheers!

AfC
Sydney