Re: [JPP-Devel] Proposal for new method of WorkbenchContext class.

[Sunburned S. <sun...@gm...>]

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
<sun...@gm...> 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 <ss...@ge...> 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
>>> <mic...@fr...> 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
>> Jum...@li...
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>