Community
Participate
Working Groups
In version 2.2 the notification windows has been changed. (it is looking better now!!). In version 2.1 the notification windows showed up at the same monitor as my Eclipse is running (on my non-primary monitor). Now the notification is showing up at the primary monitor. So this is not the same as in the previous version.
Steffen: can you reproduce?
Yes, this is a new feature :). The notification window now always shows up on the primary monitor. After some discussion we deemed this to be the most common place where notifications are displayed, e.g. other tools such as Outlook or Firefox also use the primary monitor. We can reconsider this policy if that assumption is not correct. Rob also voiced concerns that notifications are not distinguishable and overlap when running multiple instances of Eclipse.
It is fine with me that it is on the primary now if that is as intended. I noticed that it was different with regards to the previous version. That is why I raised this case. Indeed if you have two versions of Eclipse open on two monitors then you don't see where the notifications are coming from anymore. If you get more concerns about this you might think of an configuration option on the workspace where to show the notifications in case of dual monitor.
Thanks for following up. I'll leave this report open to collect further opinions on this.
*** Bug 219191 has been marked as a duplicate of this bug. ***
My 2 cents; I always think of outlook as having "a bug" frankly when it pops up things in the "wrong monitor". I agree that fixing it to the primary has advantages, but somehow I'd like to believe apps can do a bit better when there is an unambiguous better position: IFF the application is /wholly/ contained within one monitor, notifications, etc. should appear on that monitor. I had it maximized and only in my secondary monitor, I think the notifs should have shown there. When you think about it, with monitors larger and larger, its quite a visual jump to look to the bottom-right of the primary monitor to find notifications.
This is a tricky question. The reasoning in comment#6 makes sense and is a good point, but without more input I think that we should stick with the precedents set by other applications, since that's where the user is most likely to expect to see notifications. Our eyes get quickly trained to check various "hot spots" on the screen and there is benefit to maintaining consistency with the primary monitor's hot spot for notifications.
Marking resolved as per comment #7. Please reopen and provide further input if you feel that the current approach is not sufficient.
That's fine. Consistency is a good thing...
*** Bug 330333 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > That's fine. Consistency is a good thing... Sure. Consistent default behavior is a good thing. But allowing people to configure where they want it would be much better. Personally I'd much rather have my notifications on my secondary screen. It just feels more natural that I have them to my far right, instead of currently being glued to the center of my two display setup (as the left screen is my primary). In general I don't really think the whole 'one size fits all' is a good idea for a developer tool. Especially when it happens to be something integrated into an environment as flexible as Eclipse.
Reopening as per comment 11 to discuss on a weekly call.
In the discussion on the weekly call we came to the conclusion that it would generally be best to delegate to the operation system for handling notifications, e.g. through Growl (bug 209911). Most operating system support powerful global settings for configuring notifications and it is much better to reuse those than duplicating them in Eclipse. Since we don't yet have that level of OS integration we could consider extending the current settings page in Mylyn to support setting the notification popup location to: * Primary Monitor * Active Monitor Due to time constraints we are unable to implement this at the moment but the bug has been marked helpwanted to indicate that we would be happy to support a community contribution to resolve it.
The AbstractNotificationPopup is used in the automated error reporting system which is affected by the same problem. For a quick fix it would be nice if getPrimaryClientArea can be made protected instead of private to override the selection of the monitor rectangle. However a concerted solution would be best, adding Marcel for further discussion.
(In reply to comment #14) > For a quick fix it would be nice if getPrimaryClientArea can be made protected > instead of private to override the selection of the monitor rectangle. We could do that if somebody is going to take advantage of it, but my concern is that instead of solving the real problem, we'll just create confusion by having some (mylyn) notifications on the primary monitor and others (error notifications) on the active monitor. But maybe that's ok? Here's the proposed change: https://git.eclipse.org/r/48676 Please comment whether you think this is a good idea.
(In reply to Sam Davis from comment #15) > We could do that if somebody is going to take advantage of it, but my > concern is that instead of solving the real problem, we'll just create > confusion by having some (mylyn) notifications on the primary monitor and > others (error notifications) on the active monitor. But maybe that's ok? > > Here's the proposed change: https://git.eclipse.org/r/48676 Please comment > whether you think this is a good idea. I discussed the problem with Marcel and we agreed to use the same behavior as the other notifications. For a better solution, I would like to contribute the enhancement for the mylyn preferences outlined in comment #13 (if still wanted). The question is what would be the best way for a user to configure the location of the notifications. Some ideas and open points: -New Combobox in the Mylyn-Notifications Preferencepage to select the location -Allow to select each monitor (multi-monitor setup) -Maybe allow the corner of the Eclipse Window as option too? E.g. for users who do not work in fullscreen mode or have multiple instances of Eclipse running. -Configure all notifications simultaneously or allow different locations for different notifications?
That would be great! I think we should keep the preference simple: * dropdown or radio buttons in the Mylyn Notifications preference page * Primary monitor, Active monitor * Configure all notifications simultaneously for simplicity; there doesn't seem to be a need to have different locations for different kinds of notification It might make sense to also allow users to select a specific monitor but then what happens when that monitor is not available (e.g. if they undock a laptop)? Unless there's a clear need for that level of customization I think we should keep it to the 2 options suggested in comment 13.
As an Eclipse RCP application developer, I am extending Mylyn's AbstractNotificationPopup in several places. In most of these cases, the primary monitor is ok although I would still prefer to use the monitor on which the main shell of my application is. I have a closely related issue where I have overridden the initializeBounds() method to change the shell bounds to place the notification below a control to which it applies. Somehow even these overridden bounds are "corrected" to always be on the primary monitor. My use case is to show some information the user must be aware of while he changes the contents of a text control. This should not interrupt the users's workflow so a modal dialog just isn't the right thing. Because this is related to the user's current action in the text control it should be shown nearby it. One could say "just a new class extending Window" but that does not allow me to reuse some of the good code in Mylyn's AbstractNotificationPopup. In fact it is an almost perfect candidate for my use case except for the "monitor correction". The proposed patch of comment #14 would allow me to solve this problem. A less hacky solution for me would be to remove the monitor bounds "correction", though I'm not sure of the consequences for other code that uses Mylyn notifications with custom bounds.
An addition to my comment #18. I may be trying to use a Mylyn notification for something it is not intended for, yet it would still be nice if it would be possible by fixing this bug. For my use case there exists org.eclipse.swt.widgets.ToolTip with style SWT.BALLOON but AFAIK this does not allow adding formatted text/icons/hyperlinks/etc... There also exists org.eclipse.jface.window.ToolTip but it has issues with it automatically disappearing when you move the mouse or focus on another field which is not always what you may want. Plus it is limited to having at most one tooltip visible at a time.
Sorry if my comments aren't really relevant for this ticket. For my use case there already exists JFaces PopupDialog. Also it's not hard to create a custom window using style SWT.TOOL | SWT.NO_FOCUS. Still it would be a nice alternative to be able to use Mylyn for these kind of info-popups.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
