Community
Participate
Working Groups
Build ID: 3.5m7 Steps To Reproduce: If a product provides their own org.eclipse.ui.statushandlers.AbstractStatusAreaProvider implementation then the dialog displayed as a result of the call to StatusManager.getManager().handle(...) isn't centered to the parent shell using the entire width of the resulting dialog. Instead, it is centered based on the width of the dialog portion minus the status area section. As a comparison, the JFace ErrorDialog is centered correctly to the parent shell using the entire width (error dialog width + status area width).
Screen cap pls?
Created attachment 135387 [details] JFace ErrorDialog is OK
Created attachment 135388 [details] StatusManager dialog is not centered well
Ah, I understand now thanks. Does this force the dialog to get clipped on the RHS or is this just a small annoyance? Trying to understand severity wrt. 3.5.
If I move my Eclipse shell so the right-side of it is on the right-hand side of the screen then yes, the StatusManager dialog does get clipped off the side of the screen and part of my status area dialog is not visible. It is a minor annoyance as the dialog can easily be moved so I understand if it's not fixable for 3.5 - but it does look ugly :)
Created attachment 135783 [details] possible patch Here's a possible patch that corrects this problem. I think the problem is that the tray is opened after the dialog is opened (which you can see happen quickly - a separate problem) so as a result the Dialog#initializeBounds() call has already happened. If you call this method again after the tray portion is opened then the dialog is centered properly. Ideally, it would be nice to have the TrayDialog opened automatically when the Dialog is opened. The reason I ask this is because if you pay close attention then what happens right now is: 1) Dialog opens (only visible for a very short period of time) 2) Tray is opened 3) Dialog resizes / moves position it doesn't look very clean because it is possible to see steps 1 and 2 happen (although it's done very quickly). I suspect this is a feature enhancement request as I think the solution would be something like adding new API TrayDialog#open(boolean, tray) that would automatically open the specified tray depending on the state of the boolean parameter when the dialog opens.
Good digging and thanks for the patch. The patch is pretty harmless, we could put it immediately for 3.5 or maybe better consider it for 3.5.1 so we have time to discuss (latter is my pref). Maybe along the lines you were thinking, a better solution still would be to add the tray prior to open() and thus get correct sizing and position from the start. There's lots you can do to widgets without needing the thing open (and the shell), but I've not looked at our code to see how easy a change that is.
(In reply to comment #7) > The patch is pretty harmless, we could put it immediately for 3.5 or maybe > better consider it for 3.5.1 so we have time to discuss (latter is my pref). Btw, I'm assuming from a product point of view you'd be picking up 3.5.1 not 3.5, right?
Yep, 3.5.1 works for me.
Kevin , can you approve this bug for 3.5.1 or I need to ask someone else?
(In reply to comment #10) > Kevin , > > can you approve this bug for 3.5.1 or I need to ask someone else? Sorry for late response, was on vacation. +1 but I don't think my vote counts, believe you need PMC approval (McQ).
(In reply to comment #11) > +1 but I don't think my vote counts, believe you need PMC approval (McQ). My error, you only need component lead approval, which is Boris.
Created attachment 145332 [details] Test
Created attachment 145333 [details] Fix I am afraid fix cannot simply move the dialog to center after tray is opened. Opening tray on open dialog causes weird effect (you can observe this on slow machines), but opening tray and moving the dialog gives terrible experience. It is necessary to create (and not open) the dialog before opening tray, and open the dialog after. No more flickering. But the patch changes the way in which the dialog works. It caused 2 additional issues (both covered in the patch). I would like to not to take a risk of releasing this patch into 3.5.1 and target it into 3.6M2, and if everything is fine => release into 3.5.2.
(In reply to comment #14) > But the patch changes the way in which the dialog works. It caused 2 additional > issues (both covered in the patch). I would like to not to take a risk of > releasing this patch into 3.5.1 and target it into 3.6M2, and if everything is > fine => release into 3.5.2. Makes sense to me. Troy, is this item critical for 3.5.1?
(In reply to comment #15) > > Makes sense to me. Troy, is this item critical for 3.5.1? > No, it's definitely not critical (just a UI annoyance)... 3.5.2 is fine with me.
Troy, did you mean to change the bugzilla Component to "Website"?
opps, no I did not (must have miss-clicked on it). sorry! I put it back to UI.
Patches released into HEAD. Let's wait right now...
Boris, It seems that the patch did not caused any negative effect. Will it fine to release it into 3.5.x stream?
(In reply to comment #20) > It seems that the patch did not caused any negative effect. > > Will it fine to release it into 3.5.x stream? The bar should be set very high for maintenance releases - basically, stop ship kind of bugs like loss of data, major regressions, crashes, or things that would make us look really stupid. In this case, what I understand is that the dialog comes up and can be moved if it does not fit on the screen, but does not open off-screen for example. In the most likely case, the dialog would be completely visible even without moving it, just not centered with respect to the parent shell. I can live with that for 3.5.2, especially when compared to the complexity of the code change. With any code change, there is always an opportunity for new regressions. So overall, I am not comfortable with releasing the changes into 3.5 maintenance.
Changing target (the patch was released into 3.6M2). Closing as fixed.
verified. the dialog is centered correctly.
