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

Reply via email to