Community
Participate
Working Groups
If you create a perspective extension, define the standalone=true and visible=false, when the view is opened, the view is not created as a standalone view although all other parameters are respected. More generally, I'm trying to offer my users the ability to open a view through an action. That view needs to be a standalone view. There seems to be no way to open a standalone view outside of the initial perspective creation. Another option is to offer an API to open a view as standalone, perhaps as another overloaded showView method.
Chris, does it work if you add the standalone placeholder directly in the perspective factory? This may be a dup of bug 98536, or related to it. Basically the visible="false" means: define a placeholder, and it's not keeping the correct attributes.
No it doesn't work if you add the placeholder in the perspective factory. Regarding bug 98536, it is very closely related but I think a little bit different. I believe 98536 just asks that the place holder's closeable and moveable parameters be respected. I think the root of my problem is that there seems to be no way to create a place holder with the standalone parameter. So when creating a place holder in the perspective factory, or using the perspective extension (which essentially does the same as you said), theres no way to mark the place holder to open the view as a standalone. IViewLayout has an isStandalone but not a setStandalone. I think LWP and my app are trying to accomplish a very similar thing. We both want to open 'fixed' (in LWP's case thats an unmoveable & uncloseable, in my case thats standalone & unmoveable) view after the perspective has been created. Actually, I tried duplicating LWP's problem and I cannot. If I create a place holder and set moveable/closeable = false those values are respected so I'm not sure whats up with that.
I agree it's slightly different API-wise, but under the covers it's very similar. "If I create a place holder and set moveable/closeable = false those values are respected" Was this a top-level placeholder, or in a folder? I checked that the latter isn't working, but maybe the former is.
You're right. If I tried with a place holder within a folder, I reproduced their issue. Back to my issue, it is important for me that the standalone property be honored specifically, because it allows me to prevent users from combining views together.
There are several known issues with standalone views. There are still a bunch of holes where movement is not locked down as tightly as it should be. Do a bugzilla query against Platform UI with "standalone". And we're quickly running out of runway for 3.1. Another option would be to consider using a custom presentation. While non-trivial, this would give you complete control over how layout is done, and whether rearrangement is allowed. There is an example in org.eclipse.ui.examples.presentation. See also the discussion about presentations towards the end of bug 68684. I'd like to see several good quality presentation implementations become available as building blocks for RCP apps, but these would have to come from the community.
If you'd like to help out here, take a look at how PageLayout, PlaceholderFolderLayout, FolderLayout, and PerspectiveExtensionReader are implemented.
I am actually using a custom presentation. And I'm also planning on building a few custom presentations to make available commercially. So I'm definitely with you on that. I've started www.swtplus.com towards that end. About creating custom presentations, I did not have any easy time when I started out. It seems the presentations API was not intended to be responsible for layout/dragging decisions. At least thats what Stefan mentioned in my bug 87211. Its counter-intuitive to what I was expecting. I was expecting/assuming that a perspective is less responsible, providing only hints (i.e. moveable being a hint) that can be honored by the presentation or not. So I've had to still make all my views standalone so I can satisfy my main useability request, to not combine views together. I may actually be able to get in there and take a look at this problem. I'm sure I won't be able to do that for 3.1. I really didn't assume this bug would be fixed for 3.1 when I submitted it anyway.
One last thing. I am rather proud of the custom presentation I wrote and I would love to have it on the RCP examples page or on Ian Skerrett's blog, but unfortunately the CEO here is afraid of showing screenshots of our app. I guess our competitors would then realize our secret sauce :(
The swtplus widgets look cool! Nice to see. The workbench needs to control DnD rearrangement since only it knows where the other parts are, however the presentation gets to control whether DnD is initiated at all, and whether the system actions (including move etc) are included. See IStackPresentationSite.dragStart(...) and addSystemActions(IMenuManager).
Created attachment 24360 [details] Patch Here ya go... This patch encompasses two real changes. First and foremost, it alters PageLayout to add a new addStandaloneViewPlaceholder method. This is also an API addition to IPageLayout. Second, the PerspectiveExtensionReader has been modified to use this method to create standalone placeholders when necessary. I'm really hoping this could be in one of the first 3.2 builds or milestones.
Should check the placeholder id using checkValidPlaceholderId. See how PageLayout.addPlaceholder does it. Should also update the placeholder's ViewLayout to return appropriate values for isStandalone() and getShowTitle(). See PageLayout.addStandaloneView.
Created attachment 24367 [details] New patch Fixed. Attached new patch.
Thanks Chris, will review.
paul could you look at this patch?
Released into HEAD >20060208 PW
verified in I20060216-0010
