From: SourceForge.net <no...@so...> - 2008-10-27 17:57:41
|
Plugin Bugs item #2134884, was opened at 2008-09-28 16:44 Message generated for change (Comment added) made by ezust You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2134884&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kazutoshi Satoda (k_satoda) Assigned to: Dale Anson (daleanson) Summary: SideKick: Annoying focus request after parsing Initial Comment: With SideKick trunk r13830, the new filter box gets focus after every parsing. This is very annoying. I can live with the attached patch. But I can't just apply the change because I don't understand why the filter box requests focus so aggressively at first place. Making it as the default focus component is also questionable for me. ---------------------------------------------------------------------- >Comment By: Alan Ezust (ezust) Date: 2008-10-27 10:57 Message: I just did an svn up to check if it is fixed yet. It is not. I am still losing focus to the search text field. ---------------------------------------------------------------------- Comment By: Shlomy Reinstein (shlomy) Date: 2008-10-26 02:50 Message: I vote for applying voxmea's patch and closing this item. I think the reason for the original focus request by the filter field was done in order to retain its focus when the buffer is reparsed, not in order to "steal" the focus from other components when it didn't previously have the focus. The patch does this well. Any objections? ---------------------------------------------------------------------- Comment By: Shlomy Reinstein (shlomy) Date: 2008-10-07 21:25 Message: For me, the patch works fine, and if the filter box has focus, clicking the Parse button leaves the focus in the filter box. But - as far as I understand, parsing the buffer should not have anything to do with the UI (including changing the keyboard focus) except: 1. Updating the contents of the SideKick tree widget 2. Updating the parser-specific toolbar if exists Hence, I don't know why parsing has to do anything with the focus in the first place. It seems to me like this patch creates a workaround for a problem that should not have existed in the first place. I think that instead of trying to fix the focus after parsing, SideKick should not change it at all when parsing. (I am not referring to clicking the Parse button, but rather to automatic parsing that occurs when I save the buffer, for example.) ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2008-10-07 19:34 Message: Hrm, I don't know swing well enough to know how to fix this perfectly. I thought about trying to figure out if whatever was stealing focus was part of the SideKick pane, and taking focus back in those cases. But, I didn't find a foolproof way to accomplish this. I think the way it is now is much better than it was before. Any suggestions on how to handle this? ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2008-10-01 11:36 Message: The patch also solve the problem. But a questionable behavior happens. If I press the parse button while setting the focus on the filter box, the focus goes to the hide-dockable button. I thought moving the focus to the filter box is expected in this case with the patch. Is this correct? ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2008-09-29 13:43 Message: Please try the attached patch. This has been working for me with both docked and floating SideKick windows. File Added: SideKickTree.fix_focus.diff ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2008-09-29 11:30 Message: There were focus issues before this behavior where the tree wouldn't always get the focus (at least in a floating window). I'd like to try to fix both (textfield should not steal focus, textfield should be the default focused item when sidekick is focused). The text field does the right thing for up/down arrows and pgup/pgdown. I disagree that the tree should get the default focus. What other keyboard behavior are you missing from the tree that's not duplicated in the textfield? ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2008-09-29 11:11 Message: I agree, it should not be the default focus component. I think it should only get focus after the user types alphanumerics when the dockable has focus. Otherwise, it should be the tree, which responds to arrow keys, that should be the same default focus component as before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2134884&group_id=588 |