ICEpdf
  1. ICEpdf
  2. PDF-85

Rationalize Viewer RI focus management

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 4.0 - Beta, 4.0
    • Component/s: Viewer RI
    • Labels:
      None
    • Environment:
      ICEpdf Viewer RI
    • Affects:
      Sample App./Tutorial

      Description

      The Viewer RI application is currently setting focus on the document panel (to support keyboard navigation of the visible document, scroll up, down, etc.) in numerous places, including every-time an actionEvent or itemChangedEvent is fired on the SwingController.

      This approach is too blunt and results in the focus being set many times when it is redundant or undesired. One side-affect of this behavior is that the Search panel is not able to set focus on the search entry field because focus is "stolen" away by some other event that sets focus on the document panel.

        Activity

        Ken Fyten created issue -
        Ken Fyten made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 4.0 [ 10212 ]
        Affects [Sample App./Tutorial]
        Assignee Patrick Corless [ patrick.corless ] Ken Fyten [ ken.fyten ]
        Ken Fyten made changes -
        Salesforce Case []
        Description The Viewer RI application is currently setting focus on the document panel (too support keyboard navigation of the visible document, scroll up, down, etc.) in numerous places, including every-time an action event or itemchangedevent is fired. This is too blunt and results in the focus being set many time when it is redundant or undesired.

        One side-affect of this behavior is that the Search panel is not able to set focus on the search entry field because focus is "stolen" away by some other event that sets focus on the document panel.
        The Viewer RI application is currently setting focus on the document panel (to support keyboard navigation of the visible document, scroll up, down, etc.) in numerous places, including every-time an actionEvent or itemChangedEvent is fired on the SwingController.

        This approach is too blunt and results in the focus being set many times when it is redundant or undesired. One side-affect of this behavior is that the Search panel is not able to set focus on the search entry field because focus is "stolen" away by some other event that sets focus on the document panel.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #19716 Tue Nov 17 15:59:22 MST 2009 ken.fyten PDF-85 - Rationalize focus mgmt.
        PDF-86 - Print toolbar button doesn't display Print dialog.
        Files Changed
        Commit graph MODIFY /icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/common/SwingController.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #19717 Tue Nov 17 15:59:56 MST 2009 ken.fyten PDF-85 - Rationalize focus mgmt - remove setFocus on mouseClicked
        Files Changed
        Commit graph MODIFY /icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/common/views/AbstractDocumentView.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #19718 Tue Nov 17 16:01:03 MST 2009 ken.fyten PDF-85 - Rationalize focus mgmt - remove setFocus on mouseDragged.
        Files Changed
        Commit graph MODIFY /icepdf/trunk/icepdf/core/src/org/icepdf/core/views/common/PanningHandler.java
        Hide
        Ken Fyten added a comment -

        This is fixed. The fix consists of:

        1. Removing redundant calls to "documentViewController.requestViewFocusInWindow();" being made in various locations, such as when opening documents, when the zoom settings change programatically, or when the visible page is updated (view updated), or when the mouse is clicked on the document (when the focus is already set when the mouse is pressed).

        2. It turns out that the only time the "documentViewController.requestViewFocusInWindow();" call is required is when a toolbar button is pressed (either the top or bottom toolbars). Also, when the mouse button is pressed over the document pane itself.

        3. The existing calls to the "documentViewController.requestViewFocusInWindow();" method in SwingController.itemStateChanged were refined to only make the call when an actual selection event occurs, not for every itemChangedEvent that comes through the listener. Also, the SwingController.actionListener was tweaked to not make the focus call if the Search button was pressed. The technique can be extended to other toolbar buttons in the future as necessary.

        Committed revision 19718.

        Show
        Ken Fyten added a comment - This is fixed. The fix consists of: 1. Removing redundant calls to "documentViewController.requestViewFocusInWindow();" being made in various locations, such as when opening documents, when the zoom settings change programatically, or when the visible page is updated (view updated), or when the mouse is clicked on the document (when the focus is already set when the mouse is pressed). 2. It turns out that the only time the "documentViewController.requestViewFocusInWindow();" call is required is when a toolbar button is pressed (either the top or bottom toolbars). Also, when the mouse button is pressed over the document pane itself. 3. The existing calls to the "documentViewController.requestViewFocusInWindow();" method in SwingController.itemStateChanged were refined to only make the call when an actual selection event occurs, not for every itemChangedEvent that comes through the listener. Also, the SwingController.actionListener was tweaked to not make the focus call if the Search button was pressed. The technique can be extended to other toolbar buttons in the future as necessary. Committed revision 19718.
        Ken Fyten made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 4.0 [ 10222 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Ken Fyten
            Reporter:
            Ken Fyten
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: