Community
Participate
Working Groups
build 20030826 On Motif there is major flash in the status line every time I press a key in an editor. This happens in the Java editor and in a plain text editor.
Should be investigated for M3. Knut, did this not happen before?
It's probably because the keybinding of the last pressed shortcut is displayed in the status line (until the action finishes). To see that, press Ctrl+Shift+T in a java context => Open Type dialog comes up and statul line displays key binding
What flashes is the field that shows special characters used for key bindings (e.g. Esc). The same problem is also visible under Mac but not under WinXP. This status line field is contributed by the Platform UI.
The status line does not flash in the 0717 build. The editor updates it with the column/line without causing flash.
*** Bug 42294 has been marked as a duplicate of this bug. ***
I can see the very same behavior with eclipse-SDK-I20030903-linux-gtk. When I move cursor position, the status bar flases (for small moment I even can see TWO similar status infos: Read Only | Insert | 19:19 | Read Only | Insert | 19:19). If I press Down Arrow for some time (to get to the next page, for example) the status bar can't handle that and I can see in the status bar area is a white area (damaged repaint). I guess this is one of the reasons for such dramatic performance degradation in scrolling in M3 under Linux. Btw, eclipse-SDK-I20030806-linux-gtk is fine, no visible flickering or performance problems with scrolling.
Created attachment 5964 [details] Patch to Workbench Moves the update to the mode line into the block where an action is executed. I believe this maintains Chris' original intention -- which is to display the key strokes used to activate actions -- without causing visual artifacts and performance degradation. Alternatively, the first update to the mode line could be removed entirely.
Chris: please review and commit. Particularly: am I right about what you intended by the first update to the mode line?
i'm going to reject this patch. first of all, it breaks the display of incomplete multi-keystroke keysequences. (emacs ctrl+x ctrl+c, for instance, doesn't show ctrl+x after after it is pressed). secondly, shortly i want to move the press(..) method to command manager, and decouple the status line contribution item to update its text based on listening to mode changes from the command manager. please investigate how to reduce flicker / eliminate repaint problems in the status line contribution item. this may require some timing mechanism to only show key strokes after the user has paused for a short time.
*** Bug 42466 has been marked as a duplicate of this bug. ***
Created attachment 5993 [details] Revised patch for Workbench Now it makes the mode appear in two cases: 1.) There are larger unmatched key sequences 2.) An action has been found and is about to be executed. Otherwise, it leaves the mode alone.
chris: review/apply. thanks
applied patch, but this will just come back to bite us later once we move the press method (very shortly). when the press method moves to command manager, lines within the press method that refer to the status line item will be removed (as the command manager doesn't know about the status line item). the status line item will need to update itself by listening to changes in the mode. (that is why i only updated the status line item immediately after a mode change). lets leave this bug open so we don't lose track of it.
This bug is fixed. An enhancement request (Bug 42591) has been opened for Chris' request to move the press(..) method from Workbench to CommandManager.
