[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ScrollWheel, Xdps and NSEvent modification
From: |
Richard Frith-Macdonald |
Subject: |
Re: ScrollWheel, Xdps and NSEvent modification |
Date: |
Fri, 1 Mar 2002 07:16:15 +0000 |
On Thursday, February 28, 2002, at 11:20 PM, Pierre-Yves Rivaille wrote:
Hello,
I've just commited modifications to support scrollwheel under GNUstep,
but there are a few points i would like to discuss.
1. I 've added deltaX, deltaY, deltaZ support in NSEvent, so i added a
class method named
+mouseEventWithType:location:modifierFlags:timeStamp:windowNumber:context:
deltaX:deltaY:deltaZ:
i made this class public even though it does not exist in Openstep or
in MOSX doc, because it seems really consistent with the other class
methos. Does this seem ok ?
(this one is for you, Richard :-) )
OK, I'll take the bait and say ...
Sounds like bloat - what was wrong with using the existing
otherEventWithType:... method?
That's what the method is there for (actually, I don't think you even
need to use that method).
2. NSMouseMoved and NS*MouseDragged event do now use deltaX, deltaY and
deltaZ. It's not using eventNumber, clickCount and pressure anymore.
It's not raising an exception if you call those methods on those kind
of events, but it will soon (once i'm sure it does not break anyone's
code). I doubt anyone use those features, but you never know.
Are you saying you've broken the existing code .... sounds very bad.
Why would NSMouseMoved and MouseDragged events have Z delta? mouse
movement only has two dimensions.
In fact, a mouse movement should not have 'delta' at all - mouse events
are supposed to have a
location on screen - blurring that basic idea makes the operaqtion of
the gui conceptually
rather more complex.
Scrollwheel operation should afaik only have a single delta .... either
a positive or negative move
in one dimension.
In fact, this could be viewed as the mouse 'pressure' (though actually
pressure was used for the better
quality graphics pads which detect how heavily you are pressing on them).
IMO it sounds like some relatively complex changes, breaking the API and
(possibly) existing code,
when all that's needed for scrollwheel support is either -
1. map scrollwheel delta to mouse pressure and treat scrollwheeel
movement as mouse movement.
or
2. add a scrollwheel event, and put the scrollwheel movement in the
data1 field of that event.
Option 1 would add scrollwheel support without any change to the event
system.
Option 2 would add one new event type but make no other changes.
3. What should be the default behaviour associated with NSScrollWheen
event ?
right now we have (in NSScrollView)
- scrollwheel -> lineScrolling
- alternate+scrollwheel -> pagScrolling
Martin Brecher suggested adding "shift+ ..." as a horizontal scrolling
(like in GIMP), does anyone disagree on this point ? (i guess so ...)
Anyway i think we should have GNUstep defaults for this kind of thing.
Well ... mouse clicks on the scroller control are standard click for
line scroll, and
shift-click for page scroll. I'd suggest making scrollwheel consistent
with that
rather than having shift do horizontal scroll. I think internal
consistency is
probably more important then consistency with any one non-GNUstep app.
- Re: ScrollWheel, Xdps and NSEvent modification,
Richard Frith-Macdonald <=
- Re: ScrollWheel, Xdps and NSEvent modification, Richard Frith-Macdonald, 2002/03/01
- Re: ScrollWheel, Xdps and NSEvent modification, Pierre-Yves Rivaille, 2002/03/01
- Re: ScrollWheel, Xdps and NSEvent modification, Richard Frith-Macdonald, 2002/03/01
- Re: ScrollWheel, Xdps and NSEvent modification, Pierre-Yves Rivaille, 2002/03/01
- Re: ScrollWheel, Xdps and NSEvent modification, Richard Frith-Macdonald, 2002/03/01
- Re: ScrollWheel, Xdps and NSEvent modification, Richard Frith-Macdonald, 2002/03/02
- NSEvent types ... was Re: ScrollWheel, Xdps and NSEvent modification, Richard Frith-Macdonald, 2002/03/02
- Re: ScrollWheel, Xdps and NSEvent modification, Pete French, 2002/03/01