Re: [PATCH] NSScroller some event handling cleanups.

[Michael Hanni]

Hi Benhur,

--- Benhur Stein <benhur@inf.ufsm.br> wrote:
> On 2003-04-02 07:15:08 -0300 Michael Hanni <michael@deviant-behavior.com>
> wrote:
> > [...]
> > I have only one question: I understand what the alternate
> > modifier does when clicking on the scroller button, but what does it do
> when
> > you grab the scroller "knob"?
> It does a slower scrolling, the mouse must be moved much more for the same
> movement of the scroller..

Ok, that makes sense. I just wanted to make sure I wasn't seeing things.

> >          * Source/NSScroller.m (trackKnob:): stop slogging through mounds
> of
> >          mouse motion events and use periodic events.
> I think that this kind of code exists in more than one place in GNUstep (and
> probably in some applications, like in mine), because there are too many
> mouse moved events that are generated by X. Wouldn't it be a better idea
> to change the backend to filter out some of those events and not have to have
> this solution reimplemented many times in many places?
> There is also a similar and very annoying flood of events when resizing a
> window using an opaque-resizing window manager.

I have heard of "event compression" used in toolkits like Gtk that might work
in this case. I have to admit I made a similar hack with Periodic events for
menu dragging and since then I've been looking for other places to improve
interactivity -- Hell, I even hacked Affiche with Periodic events to make note
moving much faster. :)

I'll poke around in the gdk sources and see if I can find something useful. 

> > Added mask for changed
> >          flags so we catch modifier key changes.
> I'm not completely sure, but I think that OS considers the state of modifier
> keys
> as they were at the beginning of a mouse tracking session for the whole
> session,
> ignoring changes afterwards.

Ok, I was just attempting to model the original code. This would be very simple
to remove (like 5 lines of code.)

The second part of my patch, which removes the event loop handling from one
function -- sorry I'm not at my desk so I don't remember the name --, is a
little more questionable. It seems to me that all that event loop code was
superfluous and never really used, I mean if you are going to go from mouseDown
to mouseUp in NSCell's track mouse why would you want to have a second event
loop setup? Of course, is there a subclass of NSScroller that depends on that
added loop? I'll have to check when I get back to my office.

Thanks for your comments,

Michael