Bug 398325 - Activating window should not activate all the other windows
Summary: Activating window should not activate all the other windows
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 4.2.1   Edit
Hardware: Macintosh Mac OS X
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-16 14:30 EST by David Rees CLA
Modified: 2014-04-24 12:49 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Rees CLA 2013-01-16 14:30:38 EST
If you create additional windows by dragging editors and views externally (vs. create a new window with New Window") then they are all activated any time you activate any one of them. So bringing one window to the front brings all the windows to front, which occludes everything else on the screen. They are being treated as sub-windows rather than windows in their own right.

Instead I should be able want to activate just one of these windows so I can look at it next to other content (e.g. terminal or web page).

The possible alternative of using "New Window" isn't practical because it doesn't support drag and drop as described in Bug 384308. Also, when debugging views are not consistently updated across windows created using New Window.
Comment 1 Paul Webster CLA 2013-01-16 14:47:27 EST
This designed to deliberately do this, but maybe it can be changed.  Eric?  Although I suspect we'd have to make the detached windows full shells with proper trim so they can be found in the task bar.

PW
Comment 2 David Rees CLA 2013-01-16 17:32:21 EST
Interestingly on the Mac they are show grouped together in App Expose, but are show as separate windows in Witch (http://manytricks.com/witch/) (which is what I use most of the time).
Comment 3 William Kilian CLA 2014-04-23 11:37:25 EDT
Running OS X 10.9.2, I have no problem activating only one window by clicking on that window either directly, via Mission Control, or via App Expose. Perhaps OS X behavior has changed since the initial report? If I use Command-Tab, they all activate, but that is standard behavior.
Comment 4 William Kilian CLA 2014-04-23 12:10:45 EDT
(In reply to Paul Webster from comment #1)
> This designed to deliberately do this, but maybe it can be changed.  Eric? 
> Although I suspect we'd have to make the detached windows full shells with
> proper trim so they can be found in the task bar.
> 
> PW

Although allowing detached editors in eclipse 4 is a big improvement over eclipse 3 requiring a full workbench window for editors, I don't understand the rationale to restrict these to 2nd-class shells. I use eclipse all day every day and don't see any advantages, but I do see all the following disadvantages:

* Can't use Alt-Tab (on Windows/Linux) or Command-Backtick (on OSX) to switch between editors
* Open files do not show in Dock/Taskbar
* No menu

Additionally, there is a bug with the 2nd-class shell placement with multiple monitors. Detaching and restoring editors always places them on the same monitor as the main window instead of staying where I had manually moved them. I'll open a separate bug for that.
Comment 5 Eric Moffatt CLA 2014-04-24 11:11:26 EDT
We have other defects regarding this; see bug 96428, bug 223570 points out that the Mac will have issues around the main-menu should we go this route.

Perhaps it's time to revisit this but I expect that we'll run into at least the issue in bug 223570...
Comment 6 Eric Moffatt CLA 2014-04-24 11:12:38 EDT
Sorry my previous comment was unfinished...the reason to even try to revisit this is to see what the various window managers do if everything is a top-level window...multi-monitor setups are quite common now...
Comment 7 William Kilian CLA 2014-04-24 11:53:32 EDT
(In reply to William Kilian from comment #3)
> Running OS X 10.9.2, I have no problem activating only one window by
> clicking on that window either directly, via Mission Control, or via App
> Expose. Perhaps OS X behavior has changed since the initial report? If I use
> Command-Tab, they all activate, but that is standard behavior.

I can reproduce now. Shortly after I opened bug 433324 for DW placement problems I mentioned in comment #4, I discovered that unchecking {System Preferences -> Mission Control -> Displays have separate Spaces} works around that bug. 

Unfortunately, working around that bug exposes this bug. Catch-22.
Comment 8 William Kilian CLA 2014-04-24 12:15:13 EDT
(In reply to Eric Moffatt from comment #5)

Another disadvantage not mentioned in those bugs is bug 123400. Last night I opened my laptop screen on the couch hoping to get a bit done. But the 7 DWs I had open completely covered the WBW. I chose to abandon my attempt vs reconfiguring all my DWs when I returned to the office today.
Comment 9 William Kilian CLA 2014-04-24 12:49:33 EDT
I've narrowed down the behavior a bit more. With {System Preferences -> Mission Control -> Displays have separate Spaces} checked, activating a DW or WBW sometimes activates all the windows on that monitor if those windows have always been kept on the same monitor.

If a DW is dragged to a different monitor, it will thenceforth always (with one exception, below) activate independently of all other windows, even other windows on the same monitor, and even if the WBW or DW are dragged to be on the same monitor.

If a WBW is dragged, DWs normally move with it. If the WBW and DWs are dragged to a different monitor at the same time, they will still all activate together. However, if the WBW is dragged such that it moves to a different monitor but a DW does not move to a different monitor, the DW will become independent as above.

Weird exception: If a "dependent" DW is dragged to a different monitor that already has "independent" DWs, sometimes (not always) some (not all) of the "independent" DWs already there will activate just when the drag is completed. After that they all behave independently.