Community
Participate
Working Groups
The WorkbenchConfigurer currently only has support to create the menubar, coolbar, statusline and the page composite. It lacks methods to create the perspective bar, fastview bar and the progress region. Therefore if you override the WorkbenchAdvisor.createWindowContents() method, you cannot create these controls.
While we are on the topic, you also can't use the cached control wrappers and TrimLayout that are created in the createDefaultContents() method.
Yes, we would need to expose TrimLayout and friends to allow the perspective bar, fastview bar and progress indicator to be created in a custom layout, since they're aware of the layout and allow themselves to be repositioned (well, the progress indicator doesn't, but the others do). Alternatively, we could do the extra work to decouple these parts from any particular layout, but this would require the app to do more work, e.g. handle the context menu for the perspective bar and fast view bar.
Can you do both? Can the parts be told they're in a TrimLayout and thus can show the popup menus for arrangement and such? Otherwise, they will not show the popups and the RCP developer will be responsible for their layout.
The first step should be pretty easy: TrimLayout doesn't have many dependencies, and shouldn't be hard to promote to API. However, we may want to hold off until we figure out what SWT is planning to do about layouts in 3.1 -- TrimLayout currently uses a non-standard interface (ICachingLayout) to handle caching efficiently, and I've heard talk that SWT is planning to offer something similar in a standardized way -- that would be much better than the TrimLayout-specific solution. You shouldn't need the caching control wrappers, since they work around SWT performance bottlenecks which will likely be fixed for 3.1.
Chris, in the RCP newsgroup you've mentioned a couple of times that trying to use jobs in a custom window layout fails. Is there an existing bug report for this? If not, could you please file one so we can track it?
Absolutely, its entered as bug 78034. I had thought that there was already something entered for it but I can't seem to find it now.
In addition to exposing TrimLayout as API, we could consider the following: 1. Once we get nested parts working (bug 46207), create a set of interfaces that allow other parts from a parent context to be dragged into/out of a custom part. 2. Provide a new extension point to declare parts that are neither views nor editors, but can be instantiated programmatically. 3. Use this support to refactory the interesting workbench layouts (TrimLayout, PartSashContainer, and presentations) as ordinary parts. In this case, RCP apps could reuse not only the layout but also its drag/drop behavior and persistence.
Has there been any consideration for this for 3.1?
I'd also like to add that as part of a custom workbench, I'd like to be able to change the default workbench background color. I need to update the background color to complete the branding of our RCP app. I want to make sure that this will be possible when this bug is finalized. This would require that all controls (toolbar,perspective bar, menubar, status line, page composite) would allow their background to be updated.
cc'ing Kim for the preceding comment, as the logical mechanism to use would be the themes support.
Reassigning bugs in component areas that are changing ownership.
Any possibility of this done?
Sorry, but given that we are already past the API freeze, I don't think that we can solve this for 3.2.
I have noticed the interest in this bug (and the votes), but unfortunately, it is not on the 3.3 plan so chances are I won't be able to spend time on this during 3.3. Marking as helpwanted - would someone from the RCP community be interested in helping with this?
Hi Boris, Any chance this will get cycles in 3.4? Alternatively, when is API freeze for 3.4? Anyone who knows: Did SWT do the caching work that was discussed in comment #4 above?
API freeze is soon - March 28. :(
I have the same requirement for a way to customise my RCP application without loosing functionality.
Prakash is now responsible for watching bugs in the [RCP] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
