Stefan, I'm currently implementing the changes I suggested in my own BizzJUMP fork. I'll let everyone know how things go when I'm finished.
I plan on supporting cloned windows with my changes. I think this is what you were talking about with "synchronization". I don't have any plans on using a different docking windows framework in BizzJUMP. If other programmers want to integrate a different docking windows framework into OJ, I'd be willing to support that. In the meantime, the InfoNode docking windows framework is sufficient for my personal needs. SS On Mon, Dec 1, 2008 at 10:09 PM, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
