Bugzilla – Full Text Bug Listing
| Summary: | [Intro] IIntroPart.standbyStateChanged() is called at wrong time. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mazen Faraj <mfaraj> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | dejan, michaelvanmeekeren |
| Version: | 3.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 65763 | ||
|
Description
Mazen Faraj
The event is fired on view zoom state changes. When the maximzed view is closed, it is first unzoomed. The same thing happens on shutdown. I might be able to supress this behaviour... deferring, does not seem wise to change this at this time. Michael, this one is important. Its not a feature. imoh, its a bug. Its not just a matter of not wanting to get these events. But the API contract does not state that standbyStateChanged() is called when intro view is closed and when the workbench is shutdown. It doesnt even make sense to get notified during these events. You can not distinguish between a real standby change, and a close event. This is where the Intro plugin code tried (unsuccessfully now) to do some performnace code. I agree here. From the API point of view, we don't want to know that this is a view. We are contributing a class that implements IIntroPart and the contract for 'standbyStateChanged()' is limited to changes from active to standby mode. We expect to be notified of the part closing by being asked to dispose. Otherwise, all kinds of layout, loading and paint changes may be initiated only to fail half way because the part is immediately closed after that. Michael can't reply if he isn't on the CC list... pinging... I forgot that I even opened this defect :-) Why is Intro being notified of a standby state changed on a close of the view? Can we please revisit this now? I just rehit it doing some performance tests. another scenario: try this: open intro view. open PDE Log view. Make both view maximuzed. close Intro. (you get no standbyStateChanged event here. First issue) open Intro. (you get two standbyStateChanged event here. Second issue) 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. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie. |