Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 329372 - Purpose of bringToTop(IWorkbenchPart) call in LogView unclear
Summary: Purpose of bringToTop(IWorkbenchPart) call in LogView unclear
Status: CLOSED WONTFIX
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: PDE-UI-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-03 12:46 EDT by Remy Suen CLA
Modified: 2019-09-09 02:20 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Remy Suen CLA 2010-11-03 12:46:30 EDT
In LogView's asyncRefresh(boolean) method, an asynchronous runnable is scheduled to bring the view to the top.

First of all, it seems to me as though this should be a WorkbenchJob since it should only be doing something when the workbench is actually up and alive.

However, more importantly, it seems to be retrieving the active workbench window and asking it to bring the view to the top.

Is the intent of this method to display the error log to the user? I presume so, but what if there are two different workbench windows? What if I have window B activated and window A is the one with the view in it? The method call essentially becomes a no-op since window B can't bring the view to the top since the view doesn't exist in window B. Is this desirable? Yes, I would think the view shouldn't magically be shown in window B, but what should happen in window A in the background where the view lives? When I now activate window A, what should I be seeing? Should the view have stayed obscured behind another part if it was or should it have been brought to the top?
Comment 1 Curtis Windatt CLA 2010-11-03 12:57:04 EDT
The javadoc makes it quite clear that we don't know what the purpose of the method is or why it was designed that way :)
Comment 2 Remy Suen CLA 2010-11-03 13:03:30 EDT
(In reply to comment #1)
> The javadoc makes it quite clear that we don't know what the purpose of the
> method is or why it was designed that way :)

Is the term "Z order" the problem here? Please open a bug describing the problem with the Javadoc so we can un-confuse it. :)
Comment 3 Eclipse Webmaster CLA 2019-09-06 16:07:34 EDT
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.
Comment 4 Julian Honnen CLA 2019-09-09 02:20:09 EDT
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.