On Sun, 16 Oct 2005 12:28:17 -0400 Dennis Nezic <[EMAIL PROTECTED]> babbled:
> > On Sat, 15 Oct 2005 14:45:02 +0900, > > Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > > > > On Mon, 26 Sep 2005 22:35:01 -0400 Dennis <[EMAIL PROTECTED]> > > babbled: > > > > > On Sat, Oct 23, 2004 at 10:53:42AM -0400, Dennis wrote: > > > > On 10/23/04 04:03, Kim Woelders wrote: > > > > >Dennis wrote: > > > > > > > > > >>The problem (scrolling too fast freezes the scrolling for a few > > > > >>secs) only exists when i have "Clicking in a window always > > > > >>raises it" enabled. Although, i can still use my keyboard to > > > > >>scroll, during the "freeze". My mouse also gets confined to the > > > > >>stuttering window. > > > > >> > > > > >>Also, when click-to-raise is enabled, I get different xev > > > > >>events. Not sure if they help. > > > > >> > > > > >With click-to-raise E intercepts every button press and passes > > > > >it on to the application. If E is busy doing something else (I > > > > >doubt that is the problem), E isn't sheduled in, or the button > > > > >press event delivery to E is somehow delayed you'll have that > > > > >problem. > > > > > > > > I would guess that something might be wrong with the button-press > > > > event queue in E. (since the problem does not appear in other > > > > WM's (ie. fvwm) .. and i assume both receive the same X input). > > > > > > > > Here are two different test cases (of the scrolling problem, with > > > > click-to-raise). > > > > > > > > xterm -> the scrolling problem cannot be remedied by any single > > > > keystroke that i know of .. however, i did discover that holding > > > > down alt-tab, the delays are eliminated > > > > > > > > firefox -> the scrolling delays can be eliminated by single > > > > keystrokes .. such as an arrow key, or any other, i think > > > > > > the bug _still_ persists =|. i'm wondering why more people don't > > > complain about this bug. perhaps click-to-raise isn't a popular > > > option? or, more likely, there is something more peculiar about my > > > setup. > > > > > > in any case, are there any new insights as to why this might be > > > occurring .. in particular, why is it that mixing in a few > > > keystrokes amid the button presses (mouse scrolling) fixes the > > > problem? > > > > > > also, it seems that it is the scrolling caused by my mouse that is > > > the source of the problem .. and not the scrolling caused by the > > > scroll wheel on my keyboard, even though they produce the same > > > button-press events. i have a usb logitech internet navigator > > > keyboard (which is actually a usb hub with a keyboard and > > > 'mouse' (scroll wheel)), and a usb logitech optical wheel mouse. > > > > > > how is it that the same event can cause a delay if it comes from > > > the mouse, and no problem if it comes from the keyboard(hub)? > > > > just to check... get xev out - and scrollwheel on xev - do 1 click of > > the wheel and see how many button down events u get with the mouse, > > and then the keyboard scroller wheel :) > > they both seem to produce the same output in xev, both mouse > scrollwheel and keyboard scrollwheel, both during regular scrolling and > stuttered scrolling. the only difference being the abnormal time delays > between events. that's bizarre. i know of no reason why e would delay differently to the same event - as it sees it it gets the same x input for the button (is this the case? does the keyboard wheel generate button press 4, button release 4 / button press 5, button release 5)? if e is getting the same event - it will respond in the same way. can you include some output of xev (when not runing in e17 or disable click to raise or click to focus) for the 2 wheels so i can compare them? (letting me know which is which) ? > [if you meant actual clicking, clicking the mouse wheel > (button 2) produces a normal single button press, while the pressing > the keyboard scrollwheel is not recognized.] > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users