Community
Participate
Working Groups
To support the various look and feels expected from RCP clients, including Lotus, we need to allow RCP applications to render parts (views and editors) as they see fit. To address this, we have begun work on an API for 'presentations', and expect that applications can plugin their own presentation factory class to be called from the workbench whenever a presentation for a view or editor is required. This bug should track development of this feature, though this feature ha been in progress for about a week. New API is currently located in: org.eclipse.ui.workbench/org.eclipse.ui.internal.skins but is subject to move shortly (and won't be called skins) Development has been recently concerned with these areas: - this API in org.eclipse.ui.internal.skins - refactoring of PartTabFolder, ViewPane, TabbedEditorWorkbook, etc. to separate our presentations from the parts - IPageLayout and PageLayout, which calls for the creation of presentations as it lays out pages. - the perspectives and perspectiveExtensions extension points, which will probably be required to support additional data to be passed through to the presentation factory (explicit declaration of stacks, aka 'folders', marking stacks as fixed or of a certain style, etc.) - IWorkbenchConfigurer, where the application will probably establish its presentation factory class.
I spoke with nick for a while today. We ran through some scenarios with the current API and we came up with the following ideas: - We should support the idea of proprietary 'presentation hints' to be passed to the presentation factory methods. For instance, lotus has two completely different ways of drawing its stack presentations for views. - Presentation hints could include any of the following notions: 'fixed', 'detached', 'view', 'editor', 'lotus1', 'lotus2', 'single', etc. (all of these hint names are subject to change..) - IPageLayout should have an addView and createFolder variant methods that take a String[] of hints. - Hints should be forwarded through to the presentation factory methods as parameters. - We feel that AbstractPresentationFactory should be reduced to one method: Presentation createPresentation(Composite parent, IPresentationSite presentationSite, IPresentablePart presentablePart, int flags, String[] presentationHints) - Further, the Presentation type hierarchy could be collapsed to one class, Presentation, which has all the methods of StackPresentation. - Presentation should have read-only access to the presentation hints it was created with. - perspectiveExtensions should be improved to allow the explicit declaration of 'folders', such that we can introduce child elements to declare hints on those folders. currently, perspectiveExtensions can only create folders implicitly by 'stacking' view elements, hence we have no place to specify these hints. (note: this is not a requirement for M8 - the new methods on IPageLayout should be sufficient for Lotus'
There are two suggestions here: 1. Allow presentation-specific hints. 2. Only use one *Presentation class. After some discussion we have decided against item 2, although the class hierarchy may be rearranged to simplify implementing multiple presentation types in the same class. Nick has the most experience with RCP issues, so I will defer to him on issue 1. He has kindly agreed to figure out the interface for AbstractPresentationFactory, IPageLayout, and the main entry point for an application to contribute a presentation to the workbench. I will flesh out the implementation of IPageLayout if necessary.
Here is a clarification of the requirements for pluggable view presentations, including the requirements for fixed views and views with no title. Requirements for pluggable presentations for workbench parts. Description - Allow an application to change how the Workbench presents views and editors in the UI (i.e. which controls are used by PartTabFolder and ViewPane, not the view itself). Design goals - Keep an explicit separation of the UI look (presentation) from plug-ins that contribute UI elements like views, editors and perspectives (function). - Make it straightforward to implement a new presentation, using only API types and methods - Although this goal is in keeping with the rest of our APIs, it is worth calling out that this is a strong requirement for M8. LWP is not allowed to modify our implementation (whether API or internals), whether by directly hacking the base or through copy/modify/paste of code. Constraints from related work - Fixed views/perspectives (M8 requirement for LWP): - Maintain ability to configure whether perspective is fixed (can't move, delete or add folders, and initial views are fixed). - Maintain ability to configure whether view is fixed (non-closeable). - "Fixedness" needs to be communicated to the presentation. Hard requirements for 3.0 M8 - Allow pluggable presentations for workbench parts - Use case: LWP has different look than Eclipse SDK (LWP currently uses views only) - Use case: most RCP apps want native look, or at least non-curvy look closer to Eclipse 2.1 (see bug 52892) - Allow different presentations for docked views, fast views, detached views, and editors - Use case: Eclipse 3.0 wants different presentations for views in the 3 states - Use case: Eclipse 3.0 editor drop-down works differently than for views (and has different preferences) - Enable different presentations for different view stacks within the same perspective (and in the same state) - Use case: LWP wants titlebar but no tab for views not in a folder, but tabs and no titlebar for views in a folder (even if only one view in folder). This differs from Eclipse 3.0's presentation. - Use case: LWP has different presentations for different view folders in same perspective. "Views on the left are what we call "Navigator Views"; the views on the right are more or less inbox, folder, and editors. Editors are implemented as views so everything is a view. We will need different presentations for both." - Notes: - This must be done in such a way that the perspective layout itself does not state which presentation applies to which stack. - The association should be done "extrinsically", e.g. via a separate extension point that associates a view or folder with a presentation. - We don't need to provide this mechanism for 3.0 M8, just enable it (i.e. pass enough information to the presentation factory so it can determine the appropriate presentation itself). - Presentation should not hardwire choices of colors and fonts. Enable colors and fonts for presentation to be chosen from the product theme. - Think of this as being similar to externalizing strings. - Enable colors and fonts for presentation to be overridden in different perspectives. - Use case: LWP portlet aggregation (where a page layout of portlets from the server is rendered as a perspective layout of views on the client) needs different colors/fonts for different pages, but same overall presentation. - Notes: - This could be done separately by the themes mechanism. However, the current thinking for 3.0 is that the Workbench will provide only a single, product-level theme, and we will remove the theme attribute from the perspective extension point (keeping with the design goal of not mixing function and presentation). Themes can still be looked up by id and queried though (they're contributed via extension point), so we just need to ensure that the presentation can do the mapping from perspective id to presentation id itself. - Presentation must be capable of using double-click to maximize. - Use case: LWP wants no other affordance for this. See bug 51432. - Note: this should be a no-brainer, but I wanted to capture the requirement anyway. Lesser requirements (i.e. "would be nice" for 3.0 M8) - Allow pluggable presentation for view toolbar - Use case: LWP has different L&F for their toolbars (similar to Notes) - currently they ignore the view toolbar and do it themselves within their view implementations - this will prevent their views from integrating well into other products - Note: if we do the toolbar, we should do the view menu as well. Potential requirements post 3.0 - Allow multiple views to be docked in same detached window. - Use case: toolbox views in WSAD PageDesigner editor Requirements for fixed layouts. Description - Disallow end user from closing, or moving certain views in a perspective (fixed views). - Disallow end user from modifying overall layout of certain perspectives (can't move, delete or add view folders, and initial views are fixed). - Use case: LWP has fixed initial layout of their perspectives. Views which are opened after initial layout are closeable and moveable, but are only moveable within same folder. - For more details, and state of existing implementation, see bug 49811. Design goals - Keep an explicit separation between the functionality (whether a view is closeable or moveable) from its presentation (controls or other affordances for closing or moving the view). Requirements for hiding view title. Description - Prevent title from being shown for a particular view in a particular perspective (whether on titlebar or tab). - This is not just a presentation issue. A perspective may want to hide the title for a view regardless of the product L&F (see use cases below). - This is not just an attribute of the view itself since the choice may depend on which other views are typically present in the perspective. Hard requirements for M8 - Allow view title to be hidden in initial layout of a perspective. - Use case: LWP preview pane is located below their document area (which is done using views) and needs to be grouped tightly with the active document. The title is not necessary; the function of the pane is obvious from its placement and content. The preview pane's titlebar should be hidden regardless of whether this perspective is operating in the LWP app or an SDK app. [Note: This view is also fixed (not moveable or closeable). The preview pane is shown or hidden via some other action (e.g. item on View menu).] - Use case: simple RCP apps with only one or two views and a fixed layout look goofy with the extra view tabs or titlebars. Simple apps should not have to implement their own presentation just to achieve this. - Examples: - RCP Browser example. - Non-Eclipse examples: main content area vs history/folders view in IE/Explorer; main content area and document map in Word Design goals - Keep an explicit separation between the functionality (whether a view has a visible title) from its presentation (how the title appears when visible, or how the view is layed out when not visible).
Created attachment 8389 [details] Revised API for AbstractPresentationFactory, IPageLayout and friends Attached is the revised API for AbstractPresentationFactory, IPageLayout and friends. This does not address all the requirements above, but does cover the primary requirements for M8. Changes: - In IPageLayout and IFolderLayout, replaced addFixedView with a variant of addView with 2 extra args (flagMask and flags), where valid flags are SWT.TITLE, SWT.MOVE and SWT.CLOSE. Did similary for createFolder, where valid flags are SWT.MOVE, SWT.MINIMIZE and SWT.MAXIMIZE. - In AbstractPresentationFactory, made the role of the presentation (editors vs. docked views vs. fast views vs. detached views) be an argument to the factory method instead of having different factory methods. Originally I was going to change the primary dimension to single/multiple parts rather than role, and have 2 different factory methods for these, but this changed later. I originally had: public abstract PartPresentation createPartPresentation(Composite parent, IPartPresentationSite site, int location, int flags, String perspectiveId, String folderId, IPresentablePart); and: public abstract StackPresentation createStackPresentation(Composite parent, IPartPresentationSite site, int location, int flags, String perspectiveId, String folderId); but encountered difficulties when I tried to provide a default implementation of createPartPresentation in terms of createStackPresentation. So I changed it in favour of: public abstract Presentation createPresentation(Composite parent, IPresentationSite site, int location, int flags, String perspectiveId, String folderId); with an extra SINGLE vs MULTI flag, and with the add/removePart methods moved to Presentation. The end result is a single abstract class for presentations. - I then included "Part" in the type and factory method names in case the presentation factory ever evolves to include aspects other than part presentations (e.g. toolbars, overall window layout). - Added perspective id and folder id arguments to allow the presentation to be customized per perspective or folder. For clarification of how these should be used, see the Javadoc. - Added "There is a one-to-one correspondence between an IWorkbenchPart and an IPresentablePart." to the spec for IPresentablePart. Removed isMoveable() and isCloseable() from IPresentablePart since these are attributes of the part's presentation, not the part itself. - Added flags to addPart since some operations apply to the part's presentation, not the presentation as a whole. Moved SWT.CLOSE from createPartPresentation to addPart since this operation applies to the part, not the presentation. Copied SWT.MOVE from createPartPresentation to addPart since this operation applies both to the part and the presentation. Added SWT.TITLE to addPart to meet requirement for hiding view title. - Added @issue to IPresentationSite: // @issue should have getState(), so that the presentation can determine the initial state
Created attachment 8400 [details] Latest presentation code This was last synched with head on Friday morning, so may not be in synch with Nick's latest changes. The code now compiles and (barely) runs, but is still filled with critical bugs (due to cases I haven't coded yet). Please don't tell me about bugs you find here. I already know about them.... but the implementation is much closer to its final form.
I didn't sync on Friday, so my changes are definitely not up to date.
Regarding toolbars: Here is an option we haven't considered: we can provide two view toolbars. The current APIs point to a view toolbar that is associated with the view. The presentation has no control over this toolbar in any way. In addition, we add APIs for a second view toolbar. This toolbar is managed by the presentation, and all contributions in the view MUST either be prepared to handle re-parenting or re-creation. We keep the same semantics for the accessors, so that switching from one toolbar to the other is a one-line change. We move all of our toolbars to use the new presentation-managed system, but all downstream products will continue to use the old toolbar until they get a chance to verify that using the new one doesn't break anything.
While I appreciate the input on Presentation, IPresentatablePart, IPresentationSite, and their subclasses, please don't modify them or assume that their semantics will change. I can't finish the implementation if there is a moving target. If you know of a use-case that I've missed, please let me know and I'll try to take it into account. Unless there is a specific use-case that the current design cannot handle, I'd prefer to avoid changing the classes. Nick, you're free to do what you like with AbstractPresentationFactory, IPageLayout, etc. (I'm intentionally not using it to give you this freedom), but try to work with the current semantics of the rest of the classes in org.eclipse.ui.internal.skins.* if possible.
Re comment #7, no, it's a non-starter to require changes in all views. It should not be necessary to introduce new API for regular views just to open up the presentation. Re comment #8, we can hold off releasing new APIs until you've gotten the implementation working again. However, there may still be changes to the Presentation API that will require some (hopefully minor) refactoring to the implementation. But we'll stage it as you suggest.
Created attachment 8422 [details] Patch is now minimally usable Latest revision of the presentation code. This version is now minimally usable. Drag/drop and the system menu don't work yet, but PartTabFolder and views are now rendered correctly. I'll try to attach another patch with the remaining fixes later tonight.
Okay... the patch is in HEAD. It passes the test suites and seems to be working correctly.
Note: this patch has added some preliminary support for fixed views. Although I haven't tested it yet, the close button and tab drag behavior should be disabled for fixed views. I still need to override the view titlebar drag behavior. Also, the system menu should be moved. Although I'm still using the code in PartPane to generate the contribution items, it doesn't really belong there anymore. The "size" and "fast view" items should be provided by PartTabFolder, and the other items (restore, move, maximize, and close) should be contributed by the presentation.
Why should the presentation be responsible for those operations? I thought it just took care of presentation. Shouldn't these be done on the Workbench side, and notify the presentation of the any changes in bounds and state? For affordances that the presentation itself provides for these operations, it needs to notify the workbench to do the operation. Or are you just saying that the presentation should own what goes in the system menu, and delegates back to the workbench for doing all operations?
Currently the status line has a look&feel but the API for adding elements to the status line can't enforce this L&F. This is a problem that should be addressed by the presentations API.
re system menu, i expected that: 1. the presentation would own the system menu, even contribute items for 'move', 'size', 'close', 'maximize', 'restore' (based on the creation flags of the presentation) and delegate execution of these to the workbench. 2. the workbench could contribute to the system menu as well - those items completely managed outside the presentation. would not 'fast view' be one of these items? the presentation should know nothing of fast views. 3. finally, the presentation might contribute items that are handled entirely within the presentation itself, like '[x] show toolbar'. this functionality is solely for tweaking the presentation itself and the workbench should have no interest in this. (do we still need to consider how presentations persist data like this?)
re #14: this is a good point, not something we considered doing for M8. as for right now, we might ensure that all our current API (related to parts) includes some reference to the term 'part'. For instance, 'IPartPresentationSite' vs 'IPresentationSite', 'PartPresentation' vs 'Presentation', to allow for the possibility of IStatusPresentationSite, StatusPresentation, etc..
after reading nick's comment #4, i feel more confident in my original suggestion that their should be a single factory method 'createPartPresentation' which returns PartPresentation (a class which includes the methods addPart, removePart, and selectPart). i like using the SINGLE v MULTI flag. i don't buy the argument that two factory methods are significantly easier for clients simply because, in general, clients will need to implement the (arguably) more difficult 'StackPresentation' anyway. the second method is simply a degenerate case of this and can be implemented as a call to the first method.
See bug 53748 for the requirement to allow the status line manager to be replaced. There are two different concerns here: 1. Improve the status line manager because its function is not what's wanted (e.g. item 2 in the comment #0 of bug 53748). 2. Allow the presentation of items in status line to be adjusted to be in line with the app's L&F. The changes that we made to the status line contributions in Text are specific to the new look. This should be abstracted out. Components like Text should not have to care about presentation.
Regarding comment 13, yes. That's what I'm saying. The presentation is responsible for how "minimize", "maximize", "restore", "close", and "move" are presented to the user, but it delegates to the workbench to actually perform the operation. Right now the workbench is forcing these items to appear on the system menu, which is a presentation issue.
Regarding comment 15, well said. This is exactly what we should be doing... but I didn't have a chance to implement it yet.
Regarding comment 17, unless we have a specific use-case that requires clients to implement additional methods, we should go with the simpler API. 1. It doesn't make sense to force clients to implement methods that will never be invoked and don't mean anything to them. 2. It should at least be possible for clients to fully initialize their presentation object in its constructor. This eliminates the need to check if the object is fully initialized inside each public method, and eliminates complicated restrictions on methods which can only be called at certain times in the object's lifecycle. 3. It is more complicated to have one factory method uses branching to select what behavior it should use (and takes all the arguments required for both behaviors) than to simply use two methods. These are all measureable reasons why trying to reduce the entire factory interface to one method is not a good idea. Nick's problem with trying to create a default implementation that used a StackPresentation as the default Presentation would have been the only counter-argument, but this is no longer a problem in the current implementation since StackPresentation derives from Presentation and PartPresentation is gone. Therefore there is no good reason to change the current design besides personal preference.
StatusLine should be considered for reworking after 3.0. It is wrong that we need to go to everyone who contributes to the status line to change the look.
While loading the changes, I notice that the skins.newlook package has DefaultStackPresentationSite and PresentableViewPart. If the intent is that the newlook package contains the presentation implementation for the new look, shouldn't these go in the skins package proper (i.e. they're workbench internals, not something different presentations should implement).
Re: comment 23 Good point, Nick. These should definitely go elsewhere. I'll create a new package (org.eclipse.ui.internal.skins.util?) to contain workbench adapters for communicating with presentations.
Although StackPresentation needs to be API, we can still hold off on making "Presentation" API. I'm currently working on pluggable fastview and detached window appearances, and it looks as though they may need a different public interface...
By "adapters" do you mean objects available via IAdaptable (I assume not, since these are still internal classes), or are these classes just the implementations of the interfaces IPresentablePart IStackPresentationSite? If it's the latter, I don't see the need for a new package - they can go in the internal.skins package. The skins package(s) should be renamed to presentations now that Kim has moved her stuff to the themes package. I don't want to confuse this work with other skinning technologies like those for Swing (applies to all controls, doesn't affect which controls are used for certain things), Windows XP (similar), or WinAmp/MediaPlayer (mainly just different choices of bitmaps).
Re comment #25, that's OK for now, but we want to avoid having API types that extend non-API types since it makes it very easy for callers to unwittingly refer to non-API via an API type. It also complicates the subclassing contract.
I just re-read comment 21 and came to the unpleasant realization that I'm being stubborn. As an act of contrition, I will merge Presentation and StackPresentation into one class as suggested... and swallow a live lizard. I would normally claim to have learned something about posting on bugzilla without sleep, but since I'm writing this at 4:00am that would just sound silly. :-) I'm also checking in code that makes use of StackPresentation to render fastviews, which should make them pluggable as well.
re comment 26: I was suggesting making a new package for presentation-related internal classes. Currently, I've moved them into org.eclipse.ui.internal.
*definitely* make a new package org.eclipse.ui.internal.presentations for internal presentation code along with the api package org.eclipse.ui.presentations. (personally, i avoid putting anything in org.eclipse.ui.internal - its wonky enough in there already without my help..)
Re comment #28, if you haven't already, here's a nice one <g>: http://users.ev1.net/~bige2000/texas%20spiney%20lizard.jpg Gotta love Google Images.
I have moved the API classes into org.eclipse.ui.presentations: AbstractPresentationFactory,IPresentablePart, IPresentationSite, IStackPresentationSite, StackDropResult, and StackPresentation. I have moved the internal classes into org.eclipse.ui.internal.presentations: BasicStackPresentation, NativeStackPresentation, PartTabFolderPresentation, and PresentationUtil I have created the RCP/Workbench presentation factory as: org.eclipse.ui.internal.presentations.WorkbenchPresentationFactory I have create the IDE presentation factory in the org.eclipse.ui.ide plugin as: org.eclipse.ui.internal.ide.presentations.IDEPresentationFactory Note: The workbench and IDE presentation factories are currently internal. We can decide later if we want to promote either of these presentation factories as API to be used in aggregation by other presentation factory designers, or even go further and promote individual presentation classes for the same reason (like Stefan's BasicStackPresentation, for instance). Nick, if the naming/location of these presentation factories (rcp vs. ide) is unconventional, let me know. I assume we use 'Workbench' to mean 'RCP' The *skins* and *skins.newlook* packages are gone.
re comment 28: stefan, can IPresentationSite be flattened into IStackPresentationSite now? if so, my next question would be can we then change the word 'Stack' in all the API classes to be 'Part'?
nick, i've put in the AbstractPresentationFactory class from your attachment. applications still need hints to produce different styles of presentations (lotus has more than one for the 'view' role, for instance). i'd like to add the notion of hints as a parameter to this factory method as we had previously discussed (String[] presentationHints). is this ok?
I've moved away from presentation hints coming in from the IPageLayout. We want to avoid regular views, editors and perspectives from having to worry about presentation issues (other than overall layout of the perspective). The new flags that are on IPageLayout methods in my patch are well-defined functional flags, not presentation hints. However, in my patch, I added perspectiveId and factoryId to the factory methods to allow the presentation factory to determine the appropriate presentation for different perspectives and folders, to give LWP and other RCP clients the flexibility they need. There are recommendations for how these should be used to prevent presentations from being hard-wired to particular perspectives/folders. The Workbench itself will provide no mechanism in 3.0 for having different presentations or themes for different perspectives. See the Javadoc in AbstractPresentationFactory in the patch. Stefan and I also just finished discussing the factory class. For detached views, and possibly fast views, he will require different return types, so a single factory method is not going to cut it after all. For example, detached views are being given control over the whole shell, so they will need the parent shell (as a Shell, not a Composite). Also, it's pretty clear that fast views will always contain only a single view, at least for the foreseeable future. Having been in the implementation this morning (I hacked up a prototype-quality native presentation), I can see how knowing this would simplify the implementation. I think the factory class should have the following: 1. Have separate factory methods for the different roles, and remove the role parameter. These may have different return types and site types for 3.0, but for now they'll all be StackPresentation. The fast view case will be spec'ed as having only a single part, the others will be multi (there are new requirements for detached views to be multi). 2. Keep the perspectiveId and folderId, for the reasons stated above. 3. Remove flags from the factory method and move them to is*() methods on the site. 4. Remove flags from StackPresentation.addPart and move them to is*(part) methods on the site (Stefan's already done this). The less passed around as parameters the better.
For the IDE presentation for RCP presentation, I think they can be the same as long as it consults a preference for the initial state of CTabFolder.setSimpleTabs. The default for RCP should be true.
NativeStackPresentation has been released to org.eclipse.ui.internal.skins (since renamed to .presentations), just for playing around. This requires hacking PartTabFolder to use it instead of PartTabFolderPresentation (drop the theme arg in the constructor).
1. PresentationUtil needs to be API (it was written to allow client drag behavior to behave consisently with the workbench). 2. It would be technically possible to merge IPresentationSite and IStackPresentationSite with the current code in CVS... but I don't want to get into any more lengthy discussions about this type of thing (or class/method names). Take this up with Nick. As long as it satisfies all my use-cases, I will go with what you folks recommend.
I've released changes for bug 53748, including IWorkbenchWindowConfigurer.setPresentationFactory(AbstractPresentationFactory), and hooking it up from PartTabFolder. I've also made the default WorkbenchPresentationFactory be API in the public presentations package. Chris, sorry if you were in there concurrently, but I was focussing on this PR today and wanted to complete it. Note: there's some major breakage in the presentation stuff at the moment. See bug 54583.
I've checked in changes to editor management, editors are using the presentation factory for all rendering. TabbedEditorWorkbook is gone, EditorWorkbook largely replaced. Multi/single mode works, can switch on the fly. Preference on appearance page to switch between 'square' vs. 'curved' tabs works. A few minor tasks remain today: pin editor, close others, close all menu items are missing from the system menu. dirty flag not showing in editor drop down. full path not showing in editor drop down in multi-tab mode. also, i've fixed 54583.
Created attachment 8548 [details] Native Stack Presentation on XP This screenshot show's Nick's NativeStackPresentation in action on Windows XP. This looks really nice! This is what I wanted to see in both RCP apps and the IDE.
- pin editor, close others, close all menu items are now on the editor system menu. the latter two should be supported in the presentations package, even if we don't expose them in the PartTabFolderPresentation's system menu. additionally, i'd like to change IStackPresentationSite.close to accept an array of IPresentablePart. - the 'fancy' editor list is in (with text lookup). it always shows full path and it always draws the dirty flag on the right side to fix the sorting/lookup bug. pressing return selects and disposes the shell now. (still no keybinding yet, sorry..) - stefan: i changed PresentableEditorPart and PresentableViewPart to proxy property changed events (the presentations were not receiving any before because of incorrect event source object). - stefan: system menu contributions are not properly disposing themselves. - many bugs fixed, best to just diff..
1. Chris: sweet job with the editors. Unfortunately, some of the editor test suites are failing... can you check if this is related to your patch? 2. Fixed a few object leaks. I've found several caused by listeners which we failed to remove. There are probably more, so everyone please take a quick glance over your sections of the code. In particular, make sure that every add*Listener call has a matching remove*Listener call in your dispose() method. 3. I thought we decided against using one factory method for everything (comment 35). This doesn't make a difference for docked editors and views but it isn't going to work well for detached windows or fastviews. For now, I'm removing them from the API. Until I get a replacement working, I will make both of them default to the docked view appearance (which should be enough for M8). I'm currently working on detached views. 4. I just tracked down the real behavior of LayoutPart.getContainer(). I'm adding JavaDoc so that nobody else has ever has to suffer through what I just went through. I won't go into details about how I figured this out, but I'd compare the experience with being attacked by rabid badgers. 5. I'll investigate the system menu disposal stuff early next week.
Created attachment 8550 [details] old version of PartTabFolder for regression testing I've updated the old (non-pluggable) PartTabFolder to compile with the latest code base. This should be useful for anyone trying to debug regressions. Just overwrite the new PartTabFolder.java with this one and you can see how the old PartTabFolder would have behaved in a situation where the new one is failing.
Re comment #41, Ed, the NativeTabPresentation looks alright at first glance on XP. It isn't so hot elsewhere, e.g. on Win2000. And it has other problems: - it indicates which tab is active in each folder, but there's no indication of which view is active in the window - same problem for editors if editor workbook is split - no close boxes or other easy affordance for closing views (more of an issue for editors than for views) - we'd have to use the right click menu on the tab - alternatively, double-click on the icon to close, but you'd want double- click on the rest of the tab for maximize; while this is similar to how windows behave, I don't think it's a good idea to overload either single click or double-click on tabs since they tend to be small - this is not even possible currently with the SWT API since there's no way of getting the bounds of the tab items (presumably this could be fixed though)
Re comment 45: I've opened bug 54857 to track issues with the native presentation. This bug is to track development on the presentation API and infrastructure.
Added a reference to Bug 54862 which describes the suite failures
See bug 55155 for work on exposing the view menu to the presentation See bug 55156 for work on exposing the view toolbar to the presentation
Will this API be flexible enough so that an application could implement the 2.1 l&f, with view title bars with a close button, docking, square tabs with no close button, view menu and toolbar placement, editor tab compression, etc.? This would make a good example presentation if it's possible (hint, hint).
The intent is that the mechanism be flexible enough to do the 2.1 look, or any other look. There's no requirement that the presentation use a tab folder either. About the only thing blocking us from this is bug 55155 and 55156. Well, plus the fact that the 2.1 CTabFolder is gone from SWT so the -exact- L&F of the tab folder wouldn't be the same (slight bevel to the curves, arrows instead of dropdown, etc). However, the UI team has no plans to do an exact 2.1 replica for 3.0, even if only as an example. This would be an excellent 3rd party opportunity (hint, hint) <g>.
Some work done, more to be done in M9.
this bug is still open, what exactly is left to be done for M9
Need to revisit the factory methods, as well as the proposed changes to IPageLayout and friends (see comment #4).
Nick may have this covered in his previous comment but we still need the ability to define our own look n feel for the view toolbars
Matt, the custom toolbar work had fallen off my radar. Please enter a separate enhancement request for it, and if you could provide a patch for it that would be great. See IPresentablePart.getToolBar() and implementations, and where it's created in ViewPane.createToolBars. Note that it uses an internal subclass of ToolBarManager already, PaneToolBarManager, which overrides relayout to allow the presentation to adjust to changes in the preferred size of the toolbar. Unfortunately, there's currently no public API for tracking changes in the number of items materialized in an IToolBarManager, so that will be one of the challenges here.
I've just released a new extension point for presentation factories: presentationFactories in org.eclipse.ui (first cut was from Andrew). This will be in tomorrow's nightly build. The default presentation factory is defined as an extension, also in org.eclipse.ui. The (hackoid, experimental) native one is in there too, for now. The presentation to use is specified by the preference org.eclipse.ui/presentationFactoryId (see IWorkbenchPreferenceConstants.PRESENTATION_FACTORY). Unfortunately, the primary feature's plugin_customization.ini override mechanism seems to be broken (see bug 58975), but a preference customization file can still be specified on the command line. For example, to use the native presentation (no PRs please), specify: -plugincustomization custom.ini where custom.ini has: org.eclipse.ui/presentationFactoryId=org.eclipse.ui.presentations.native Since the presentation factory can now be specified in this way, I've deprecated the RCP APIs: IWorkbenchWindowConfigurer.get/setPresentationFactory.
Nick will this change make it into the 04/20 integration build? -m@
I've made the following changes in head 1. Presentations now supply the Minimize, Maximize, Restore, Move, and close actions (as per comment 15 and comment 12). 2. StackDropResult now uses IPresentablePart to identify the drop location. This makes it consistent with StackPresentation.addPart, removes the assumption that the presentation is indexes parts in the same way that PartTabFolder does, and makes it harder for the presentation and workbench to get out-of-synch regarding tab order. 3. The flags argument is gone from the factory. This information is now available from the site. 4. Presentations now control the lifecycle of their system menu manager. Rather than implementing getSystemMenuManager() and have the workbench insert actions on creation, the site now provides an addSystemActions method that the presentation can invoke whenever it is ready.
The change in comment 58 might be a breaking change for your presentation, Matt. Let me know if you need any more info.
Created attachment 9666 [details] Proposed patch for PartPane to remove ViewForm I found it confusing that PartPane still wrapped a ViewForm so I changed it to wrap a plain Composite instead and I don't see any ill effects. With the presentation API, the top right, center, and left slots of the ViewForm weren't being used anyway. What do you think of this change? I tried to get rid of the extra composite at the top but there were a number of consumers that were making assumptions that that control was non-null pretty early, so I just punted and left that in for now. So now there's a Composite (instead of a ViewForm) containing nothing but another Composite that contains the actual content of the part. Note the getPane() and getViewForm() methods are not called anywhere but I was hesitant to just delete them because I wasn't sure if deleting protected methods would break binary compatability.
We need the Min and max icons to be done by the presentation instead of CTabFolder. Among other things this will make it easier to use an actual gif image for those icons instead of something hand-coded with gc.drawLine(). Also it will make it possible to put a close button next to them in a view title bar and have min, max, and close look compatible with each other. (Actually I don't think CTabFolder should even need a concept of minimized/maximized. This will make CTabFolder more generic and usable by more than one presentation. The fewer extra methods on CTabFolder as compared to TabFolder, without losing functionality, the better. CTabFolder is already 3400 lines long so it looks like a good candidate for refactoring.)
Regarding comment 60: thanks for the patch. I was hoping to get rid of the ViewForm eventually... but it would be a lot nicer if we could remove the bogus composite entirely. CTabFolder already has some public methods that let you hide its min and max buttons. You should file CTabFolder suggestions as enhancements against SWT.
I've committed Ed's patch from comment 61.
Released the following changes to presentations and perspectives: - AbstractPresentationFactory now has separate factory methods for creating the different kinds of presentations, instead of the role argument. - No longer passing perspective id or folder id to the factory methods. - AbstractPresentationFactory now has default implementations for createStatusLine*. - Added support for standalone views. A standalone view cannot be docked together with other views in the same folder, and can have a corresponding presentation (e.g. without tabs). Standalone views can also indicate whether their title (including titlebar buttons) are shown. This is particularly useful for fixed perspectives with few views, where the title is unnecessary. E.g. the browser example. See IPageLayout.addStandaloneView. There's also a new presentation factory method for this. - Updated the default presentation factory to support standalone views. - TBD: actually disabling the DnD/Move support for standalone views.
I entered bug 62280 to track comment #61.
The presentation API now does everything it was originally designed to do (and significantly more). We should file new PRs for any additional enhancements or bugs.
