Community
Participate
Working Groups
20040317 We need to be able to allow an IPresentablePart to opt out of showing bold when it is done. Currently any part that is not the focus part will show bold when it is done. For the marker views in particular this is only desired when the markers change.
From Nick: The current code in PartTabFolderPresentation.updateGradient only sets the font if the part is active and not busy. This doesn't seem to handle all the cases. There doesn't seem to be anybody setting the default font for the initial case anymore (independent of activation). It's also not clear to me that we're handling the multiple concurrent jobs case. Also, PartTabFolderPresentation is only used for views. Need to ensure that this works for editors too, in EditorPresentation too. The font logic there now is different than for PartTabFolderPresentation. We want to maintain the following invariants, for both views and editors: - if any jobs running in the part, then font is italic - else if any jobs were running, but have all completed, and part not yet activated, then font is bold - else font is plain I suggest having a common updateFont(IPresentablePart) method in PartTabFolderPresentation, calling this from the subclasses for the initial case and when the busy state changes. This will require maintaining a separate latch for the "all jobs completed but part not yet activated" state, for each part. Any logic that is independent of how the busy state is presented should be encapsulated in IPresentablePart. That is, it should be easy to move to using colours rather than fonts to show the busy state without having to worry about the logic above. I suggest changing IPresentablePart.isBusy() to be a 3- valued int getBusyState() method (not busy, busy, and done), and maintaining the latch there.
My comments above are really independent of the subject of this PR. Whether or not parts can opt out, we still need to handle the busy state presentation properly, and have the proper separation of presentation and non-presentation aspects.
Created Bug 55167 to track the other issues
Added jean-Michel and John. I think what might be the easiest opt out for the view developer is to change ViewPart.showBusy() to return a boolean with true indicating that we should bold the viewer and let the viewer decide what to do. This is a breaking change so we should hold off until early M9 if we want to do it this way.
The Workbench should not refer directly to ViewPart or WorkbenchPart. IWorkbenchPart and IViewPart are the API types. WorkbenchPart and ViewPart are just conveniences, on the client side of the fence. It would be better if it was just API on the part's job service, rather than adding API to the generic part interfaces that is specific to a particular service. E.g. setShowBusy(boolean), int getBusyState() and addPropertyListener for busy state changes.
This needs to be decided on once and for all in M9.
This needs to be resolved for M9
Please see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/responsive-ui/M9proposal.html for the proposed solutions to the outstaning progress issues in M9.
The proposal still mentions adding API to WorkbenchPart. Please see comment #5.
IPresentablePart already has a "isDirty" flag that indicates that it contains interesting changes. Views can choose to set this when their contents change and clear it when they become visible. This seems to be exactly what is needed here. This isn't a "done" state. A view may have interesting new changes that did not involve running a background job. The workbench may decide to display an "are you sure?" dialog before closing a dirty part. There don't seem to be any changes necessary in the presentation API.
Careful. The isDirty flag is used to capture the dirty editor state, i.e. a user-initiated change to the content shown in the editor. Views can also get exactly the same semantics via ISaveablePart (this used to be used by the Sync view in 2.1, but is not currently used in the SDK in 3.0). isDirty should not be overloaded for showing busy/completed state.
This was my feeling too. It turns out that the requirement the dynamic tea came up with was different anyways - we need a way to say showUpdatedContent() which would then forward to the presentation which would (in our case) make the tab bold. I currently intend to implement this on IWorkbenchSiteProgressService and not touch the ViewPart at all.
Fix released. IWorkbenchSiteProgressService now has a method warnOfContentChange which calls site.getPane().showHighlight() (from the internal class). This in turn sends a property change event which the IPartPresentation listens to. BasicStackPresentation now highlights for this. The main change this has is that bolding does <not> happen by default now. I have hooked up the marker view to do the same thing as before - I will make it smarter in the upcoming days.
This has been added. By default all views opt out of this state and can get it back by calling getProgressService().warnOfContentChange();
