Announcement Announcement Module
Collapse
No announcement yet.
Commands Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Magnus,

    I went back to my code and ran some tests. The important part with respect to enabling the executors to follow view selection is the dockableFrame.addDockableFrameListener call in the createDockableFrame method of JideApplicationPage.

    The specific dockable frame listener that I add basically converts the Jide dockable frame events into Spring RCP page components events.

    There's also a couple of other listeners that are required to cover specific cases with the workspace/editor implementation. One (addDocumentComponentListener call in the addDocumentComponent of workspace view) deals with the case when all editors are closed, and the workspace becomes empty. The other is the registration of a specific FocusOwnerChangeListener in the constructor of JideApplicationPage. This deals with the case of an editor being selected after a view. This is not dealt with by the usual Jide event mechanism.

    hope this helps.

    Jonny

    Comment


    • #17
      Hi Jonny

      Ok I'va been digging through this. You have in your code something like this

      dockableFrame.addDockableFrameListener(new DockableFrameAdapter() {

      public void dockableFrameActivated(DockableFrameEvent e) {
      fireFocusGained(pageComponent);
      }

      public void dockableFrameDeactivated(DockableFrameEvent e) {
      //Must not fire focus lost since non view component may
      fireFocusLost(pageComponent);
      if (e.getOppositeDockableFrame() == null) {
      fireFocusGained(workspaceComponent);
      }
      }
      });

      This is ok when you are shifting focus between view's only. BUT since other components may take the focus it means that when selecting a menu, which can also be tied to the global commands, a focus lost event occurs and the view looses its focus. Since the opposite fram is null, remember its a menu selection, the workspace will get the focus and the global commands will be set by the workspace instead.

      This is a BIG problem for me so what can I do?

      If each view ALWAYS must define a command executor for all global commands we could remove the fireFocusLost(pageComponent); in the dockableFrameDeactivated method. This would make the problem with the menu selection disappear since only when view are selected would the commands be set. The problem still exists with the workspace though. (Remember I have a workspace that does not use the editors so maybe I should redo this and have it as a normal view, which is not closeable etc). I need to listen for focus gained on the workspace view so I can fireFocusGained on it.

      I will continue investigating this and let you now what I've done. Please feel free to give a comment if you think I should skip the workspace or anything else

      Cheers
      Magnus

      Comment


      • #18
        Magnus,

        Dealing with the workspace has always been the biggest problem with respect to the global executors and focus. The e.getOppositeDockableFrame() == null was always a bit of a hack to get this to work. Since you don't use editors maybe using a non-closeable view would be a simpler solution.

        Also, look at the most recent codebase, especially JideApplicationPage and WorkspaceView. I checked some changes in maybe 3 weeks ago that dealt with these events and one change was to get rid of the e.getOppositeDockableFrame() == null check. Following some advice of the Jide guys I now use a FocusOwnerChangeListener that checks to see if the focus has changed to the workspace view and fires a focus gained method on that. The problem you mentioned, with menus etc., was brought up as a reason not to use the getOppositeDockableFrame hack.

        Please let me know what you find.

        Jonny

        Comment


        • #19
          Hi Jonny

          Well good I found it again then :-) Sorry for not looking at allready existing code but it's kind of fun to find out for yourself and to feel special :-), atleast until you put me straight...


          I think I'll go with the non closable view, maybe I'll go for the workspace later if I feel there is a need for editors, which there might be.

          I want to thank you for your help, it is really nice to have someone to bounce ideas with. I'll get back with more info when Im done with this part.

          Cheers
          Magnus

          Comment


          • #20
            Magnus,

            hope this solves your problems. If it doesn't, or other problems are found in this regard, please let me know. I'd like to be certain that this piece of the integration code is robust.

            And, yes, from what you've said a noncloseable view would suit your purposes better than the workspace view, which is only really needed for editors.

            Jonny

            Comment

            Working...
            X