no answer yet.. and as I am not familar with GUI stuff either...well, I guess we will have a look on the final work. However as long as you add things, I don't have a problem with that (if we port that over). But .. I/we also have seen/proposed nicer (more natural) docking frameworks. Did you solve the synchronization issue? ..which is definitively a JUMP feature and used by several people.
stefan Sunburned Surveyor schrieb: > I'm finally getting back to my work integrating the > ViewAttributesTablePlugIn into the InfoNode Docking Windows Framework. > (All this work is taking place in my own fork of the core. No changes > have or will be made to the JPP SVN.) > > Here is what I have done so far: > > - Modified the WorkbenchFrame class to contain two (2) new private > variables. The first is a reference to the active TaskFrame. The > second is a boolean variable that indicates if the WorkbenchFrame > currently contains an active TaskFrame. > > - I added one protected method (WorkbenchFrame.setIsATaskFrameActive) > which sets the boolean variable and a public method > (WorkbenchFrame.isATaskFrameActive) to retrieve the value of this > variable. I also added a public method > (WorkbenchFrame.getActiveTaskFrame) to retrieve a reference to the > active TaskFrame. > > - Modified the TaskFrame.internalTaskFrameActivated() method to add a > reference to the activated TaskFrame to the WorkbenchFrame and to set > the isATaskFrameActive variable to true. > > - Modified the TaskFrame.internalTaskFrameDeactivated() method to set > the active TaskFrame reference in the WorkbenchFrame class to null, > and the isATaskFrameActive variable to false. > > - I added a two (2) public methods to the PlugInContext class. The > PlugInContext.getActiveTaskFrame method returns a reference to the > active TaskFrame. The PlugInContext.isTaskFrameActive method indicates > if > the WorkbenchFrame contains an active TaskFrame. > > Here are a couple of questions: > > - Will I need to mess with the internalFrameOpened() method of the > TaskFrame class? Is it possible to open a TaskFrame but not have it > active? Is the internalFrameActivated method called when a TaskFrame > is opened? > > - I've got the methods used by a plug-in to access the active > TaskFrame in the WorkbenchFrame in the PlugInContext class. This > probably needs to be moved to appropriate implementations of the > WorkbenchContext class. What do you think? > > I'm struggling with the best design for this code. I'm trying to keep > the "model" separate from the "GUI", but in this case I need to allow > plug-ins access to the TaskFrame class. Typically plug-ins work with > Task objects, not with the component that displays them. If someone > can think of a more elegant solution, please let me know. > > SS > > On Thu, Nov 6, 2008 at 7:04 AM, Sunburned Surveyor > <[EMAIL PROTECTED]> wrote: >> Let me make the changes first in my own fork of the core. If I get >> everything working with no (detected) bugs I'll post here again on the >> topic. >> >> Thanks, >> >> SS >> >> On Wed, Nov 5, 2008 at 7:30 PM, Stefan Steiniger <[EMAIL PROTECTED]> wrote: >>> so.. are you adding your method? >>> (As said once: adding methods is not the bid deal, but changing core >>> processes/structures is) >>> >>> stefan >>> >>> >>> Sunburned Surveyor schrieb: >>>> Yes, it makes more sense now Michael. Thanks for all of the comments. >>>> >>>> SS >>>> >>>> On Tue, Nov 4, 2008 at 11:15 AM, Michael Michaud >>>> <[EMAIL PROTECTED]> wrote: >>>>>> Michael wrote: "If you want to use the TaskFrame as the place to dock >>>>>> everything, I >>>>>> think every TaskFrameProxy will become a dockable of your TaskFrame, and >>>>>> you'll have to find another name for what is actually called a TaskFrame >>>>>> (ie a frame containing a LayerView, a LayerNamePanel...), and, if >>>>>> possible, consider there may be several of those components in your main >>>>>> TaskFrame" >>>>>> >>>>>> I'm not sure if I quite understand this. I do want the TaskFrame to be >>>>>> the parent window in the docking window tree. It will contain all of >>>>>> the other windows related to the task. Right now, a lot of these >>>>>> windows are added as internal frames. I don't know that I need to >>>>>> change the name of the TaskFrame class. It will still be an internal >>>>>> frame used to display a LayerViewPanel and a LayerNamePanel. >>>>>> >>>>> You're right, you don't need. I was talking about a component inside >>>>> your TaskFrame and made of a LayerViewPanel + a LayerNamePanel (what the >>>>> actual TaskFrame is). But you don't need that. You can consider that >>>>> your TaskFrame is directly composed of one (or several) LayerViewPanel, >>>>> a LayerNamePanel, one or several ViewAttributeFrames... >>>>> Hope it makes more sense. >>>>> >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel