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 d
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 s
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 cla
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 metho
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
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
> 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...),
Frame.this);
>>>
>>> in the internalFrameActivated() callback, and
>>>
>>> workbenchContext.setLastActiveTaskFrame(null);
>>> in the internalFrameClosed() callback.
>>>
>>> Now the WorkbenchContext will al
hContext will always know what the last TaskFrame is and the
>> other existing none-TaskFrame internal frames won't interfere with this.
>>
>> This may also help with the TaskFrame cloning issue.
>>
>>
>>
>> Bing
>>
>>
>> ---
t the last TaskFrame is and the
> other existing none-TaskFrame internal frames won't interfere with this.
>
> This may also help with the TaskFrame cloning issue.
>
>
>
> Bing
>
>
> ----------
> From: "Sunburned Survey
rfere with this.
This may also help with the TaskFrame cloning issue.
Bing
--
From: "Sunburned Surveyor" <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2008 6:12 AM
To: "OpenJump develop and use"
Subject: [JPP-De
Michael,
These are good points. Here is what I am trying to do:
I've got a TaskFrame which extends a class that can host other docking
windows. I want to modify the ViewAttributesPlugIn to add a docking
window to the TaskFrame instead of creating a new JInternalFrame to
display the attribute tabl
Hi Landon,
Can you tell more about your need.
It seems to me that it is not safe to rely on JInternalFrame title to
find the TaskFrame attached to a plugin :
create a task named "Landon" (create new Task + save as... Landon)
create a clone (window>clone) : OJ will name it "Landon (view 2)"
delete
>I thought it returned the "active internal frame"
That may be true. All bets are off when working with another window manager.
On Mon, Nov 3, 2008 at 5:04 PM, Sunburned Surveyor <
[EMAIL PROTECTED]> wrote:
> Hmmm. I thought it returned the "active internal frame" which would be
> whatever intern
Hmmm. I thought it returned the "active internal frame" which would be
whatever internal frame had focus. So, if a plug-in had created an
internal frame with focus, this object would be returned, not the
TaskFrame. But I'm not sure now that you asked this question. It does
seem logical that Vivid w
Does workbenchContext.getWorkbench().getFrame().getActiveInternalFrame()
give you what you need?
Larry
On Mon, Nov 3, 2008 at 4:12 PM, Sunburned Surveyor <
[EMAIL PROTECTED]> wrote:
> I'd like to propose the attached code be added as a method of the
> WorkbenchContext class. I sometimes find mys
I'd like to propose the attached code be added as a method of the
WorkbenchContext class. I sometimes find myself with a need to access
the active TaskFrame for the Workbench, especially when I work on the
docking window integration. Perhaps others have found a need to do
this as well.
At any rate
17 matches
Mail list logo
