[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] NSScroller some event handling cleanups.
From: |
Michael Hanni |
Subject: |
Re: [PATCH] NSScroller some event handling cleanups. |
Date: |
Wed, 2 Apr 2003 10:36:03 -0800 (PST) |
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