How to open a view tabbed with a existing vldocking view?

[hrong]

Hey,guys

I'm using vldocking descriptor as the default page docking system.

Now I want to open a view to be shown tabbed defaultly.

I have known how to programmatically open a view but DO NOT know
how to open that view as a tab as a member of a vldocking group.

Does anybody know that ?
best regard.
hrong

[adamarmistead]

Currently the VLDockingViewDescriptor does not support DockGroups so there
is no way to enforce them through configuration as far as I have found short of extending VLDockingApplicationPage, VLDockingAplicationPageFactory, VLDockingViewDescriptor, and ViewDescriptorDockable and adding DockGroup support.

I have created an issue in jira for this and submitted a patch that adds this functionality. If you need this support, please vote on it. I'm just waiting for it to be imported into the codebase.

http://jira.springsource.org/browse/RCP-609

The only way I know how to open a view as a tab is to extend VLDockingApplicationPage and override the doAddPageComponent(..) method or to provide the VLDockingPageDescriptor with your custom implementation of VLDockingLayoutManager. The default VLDockingLayoutManager simply calls desktop.addDockable(dockable) and desktop.remove(dockable) to add and remove dockable views. I would say the second method is probably preferred.

Although I haven't tried it i suppose you could somehow embed DockGroup support in your layout manager code as a side effect of adding/removing views.

[hrong]

Currently the VLDockingViewDescriptor does not support DockGroups so there
is no way to enforce them through configuration as far as I have found short of extending VLDockingApplicationPage, VLDockingAplicationPageFactory, VLDockingViewDescriptor, and ViewDescriptorDockable and adding DockGroup support.

I have created an issue in jira for this and submitted a patch that adds this functionality. If you need this support, please vote on it. I'm just waiting for it to be imported into the codebase.

http://jira.springsource.org/browse/RCP-609

The only way I know how to open a view as a tab is to extend VLDockingApplicationPage and override the doAddPageComponent(..) method or to provide the VLDockingPageDescriptor with your custom implementation of VLDockingLayoutManager. The default VLDockingLayoutManager simply calls desktop.addDockable(dockable) and desktop.remove(dockable) to add and remove dockable views. I would say the second method is probably preferred.

Although I haven't tried it i suppose you could somehow embed DockGroup support in your layout manager code as a side effect of adding/removing views.

thanks ! I will try it later

[rdawes]

Currently the VLDockingViewDescriptor does not support DockGroups so there
is no way to enforce them through configuration as far as I have found short of extending VLDockingApplicationPage, VLDockingAplicationPageFactory, VLDockingViewDescriptor, and ViewDescriptorDockable and adding DockGroup support.

I have created an issue in jira for this and submitted a patch that adds this functionality. If you need this support, please vote on it. I'm just waiting for it to be imported into the codebase.

http://jira.springsource.org/browse/RCP-609

The only way I know how to open a view as a tab is to extend VLDockingApplicationPage and override the doAddPageComponent(..) method or to provide the VLDockingPageDescriptor with your custom implementation of VLDockingLayoutManager. The default VLDockingLayoutManager simply calls desktop.addDockable(dockable) and desktop.remove(dockable) to add and remove dockable views. I would say the second method is probably preferred.

Although I haven't tried it i suppose you could somehow embed DockGroup support in your layout manager code as a side effect of adding/removing views.

Yes, the idea when I wrote this code was for people who had specific layout requirements to provide their own VLDockingLayoutManager. I never really figured out a good way for it to decide how to lay out a View, though.

Should this be done as an extension of VLDockingViewDescriptor that indicated whether it wanted to be tabbed with something else? The VLDockingLayoutManager could then cast, extract this information, and apply it . . .

It sounds about right, since the layout preference IS probably a property of the View, but creating the DockGroup doesn't seem to be intuitive to me.

Then again, the last time I looked at this was when I wrote it, about 2 years ago! :-P

[rdawes]

Looking at your patch, I have to ask how well this will work if there are two windows open?

Since you have a single DockGroup defined at a ViewDescriptor level, which would be reused if a new Application window is opened containing an instance of the View described by that ViewDescriptor, that would probably not work too well, unless you create the DockGroup using a factory of some sort, which would probably also not work too well.

That sentence doesn't make a whole lot of sense, but I hope I conveyed my meaning.

A better solution might be to have a String naming the DockGroup, which would be created on demand by the VLDockingApplicationWindow, and stored in a map, for example.

That might lead to a memory leak, perhaps a WeakHashMap, with a reference to the DockGroup stored in the actual View, so that when all the Views referencing the DockGroup go out of scope, the DockGroup can be garbage collected? Dunno . . .

[adamarmistead]

Are you referring to opening a new window of a running application and dragging docks between the two windows or just dragging docks for each windows and dropping them on their parent window?

If its the first, I haven't looked into how to do this at all, although I remember it being supported by VLDocking, but it certainly doesn't work that way out of the box unless I'm doing something wrong. If your asking does DockGroup support work with the second use case, it does. If I have 2 windows opened and have 2 dock groups the docking behavior is as expected for both windows.

Hopefully I have understood your question, but I'm not sure.

[rdawes]

Are you referring to opening a new window of a running application and dragging docks between the two windows or just dragging docks for each windows and dropping them on their parent window?

If its the first, I haven't looked into how to do this at all, although I remember it being supported by VLDocking, but it certainly doesn't work that way out of the box unless I'm doing something wrong. If your asking does DockGroup support work with the second use case, it does. If I have 2 windows opened and have 2 dock groups the docking behavior is as expected for both windows.

Hopefully I have understood your question, but I'm not sure.

What I was really referring to, and maybe just asking the question really, was:

Since you specify the DockGroup instance as a parameter to the VLDockingViewDescriptor, any instances of VLDockingView created by the Descriptor would share that DockGroup.

However, if you opened two windows, and therefore created two VLDockingApplicationPage's (with associated DockingDesktop), the DockGroup would be used by both instances of DockingDesktop simultaneously. I don't know how well this works in practice. Or what the DockGroup actually does. If it is effectively a descriptor with no per-DocingDesktop state, then all is good. If it holds per-DockingDestop state, then things might not be so good.

I wasn't really talking about dragging View's between Windows, which I think is a bad idea, since the View has a reference to its Window, as far as I recall.

Hope that explains my concerns better.

[adamarmistead]

Ah, a DockGroup is just a string, a name if you will for a group of dockables, and optionally a parent DockGroup. So, you can create a group, say "editors" and another group, say "tools" and assign these to the dock key for the dockables. Afterwards drag and drop operations are limited to dockables in the same group. So you cant drop a "tools" dockable on an "editors" dockable, the docking framework keeps them separate. As dockables can have parents you can have nested groups. Since this is nothing more than a string name for the group and a reference to a parent group at most I don't see it being a problem and i haven't found a use case in which it fails.

Dockables can be shared between windows if both windows have the same DockingContext. They can have different DockingDesktops but must share the same context. This would require you to create a DockingContext and DockingDesktop and for the second window, create its DockingDesktop and use the constructor that takes a docking context to have the new desktop use the shared context. Haven't tried it yet but supposedly thats all it takes. Although I do see your point with the views having a reference to the window.

[rdawes]

Ah, a DockGroup is just a string, a name if you will for a group of dockables, and optionally a parent DockGroup. So, you can create a group, say "editors" and another group, say "tools" and assign these to the dock key for the dockables. Afterwards drag and drop operations are limited to dockables in the same group. So you cant drop a "tools" dockable on an "editors" dockable, the docking framework keeps them separate. As dockables can have parents you can have nested groups. Since this is nothing more than a string name for the group and a reference to a parent group at most I don't see it being a problem and i haven't found a use case in which it fails.

Dockables can be shared between windows if both windows have the same DockingContext. They can have different DockingDesktops but must share the same context. This would require you to create a DockingContext and DockingDesktop and for the second window, create its DockingDesktop and use the constructor that takes a docking context to have the new desktop use the shared context. Haven't tried it yet but supposedly thats all it takes. Although I do see your point with the views having a reference to the window.

Ok, now I understand. I guess that makes sense then.

[rdawes]

Ok, now I understand. I guess that makes sense then.

Actually, I'm not so sure about this.

My understanding is that the DockGroup prevents any docked windows from leaving that group. e.g. editors in an "Editor" DockGroup can be tiled/tabbed, etc as desired, but they can't be dragged out into the rest of the DockingDesktop.

This doesn't really seem to achieve the objective entirely.

What I could see as desirable is the ability to specify that by default the View should be tabbed with another specified View or class of View perhaps (if it exists), but if not, place it in the most likely place (where "likely" is defined by the developer).

As you can see, this is a very complex thing that does not really lend itself to parameterized layout, IMO. Hence the introduction of the VLDockingLayoutManager interface.

That said, Eclipse, etc seem to have this figured out, perhaps we should be looking there to see how it is done?