Community
Participate
Working Groups
4.4.2 and 4.5 (master / I20150512-2100) OS X 10.10.3 (didn't test earlier OS versions, but probably a new problem) A FileDialog/DirectoryDialog with SWT.SHEET is misplaced after the slide-down animation. The sheet dialog gets centered horizontally and slightly higher than the center of the screen vertically. Can be reproduced in the ControlExample, or in Eclipse, e.g. in File > Import... > Archive File > upper Browse... button. The lower Browse... button opens a custom Shell with SHEET. There, the sheet shell stays where it should. Does not happen in the Save... sheet dialogs in TextEdit.app and Terminal.app. However, the bad location of SWT's sheet dialogs looks the same as the location of the (non-sheet) Open... dialogs in TextEdit/Terminal.
*** Bug 467397 has been marked as a duplicate of this bug. ***
Is there anyone giving attention to this? I recommend increase the importance of this issue otherwise they will never fix this... It is always the same story...
*** Bug 478927 has been marked as a duplicate of this bug. ***
(In reply to Rafael Karst from comment #2) > Is there anyone giving attention to this? The bug is targeted for 4.6 and we are already working on this.
That is Great! Thanks for the reply Lakshmi! =] (In reply to Lakshmi Shanmugam from comment #4) > (In reply to Rafael Karst from comment #2) > > Is there anyone giving attention to this? > > The bug is targeted for 4.6 and we are already working on this.
New Gerrit change created: https://git.eclipse.org/r/58786
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/58786 The patch fixes the misplaced SHEET problem in FileDialog. Same thing has to be done to DirectoryDialog. The one part that is not working currently is that the patch doesn't capture user's response from the Sheet. That requires finding a way to use a objective-c block from Java code for the completion handler. Will continue to work on this for M4.
This change requires the build setup to move to OSX 10.6 or higher. Targetting for M5.
Build machine has not yet moved up, need to defer to M6.
(In reply to Lakshmi Shanmugam from comment #9) > Build machine has not yet moved up, need to defer to M6. Opened Bug 489305 to move builds to the EF build machine. If that doesn't work before M7, we'll move the builds to the local OSX 10.7 build machine.
*** Bug 492249 has been marked as a duplicate of this bug. ***
Will try for RC1.
Unfortunately couldn't complete this due to the work involved in the HiDPI related bugs. Will take it up for 4.6.1.
@Lakshmi, given the late date, I am assuming this bug will not make 4.6.1. Can you confirm?
(In reply to Steven Darnell from comment #14) > @Lakshmi, given the late date, I am assuming this bug will not make 4.6.1. > Can you confirm? Hi Steven, Lakshmi is away for the next few months and I'll continue the work on this bug, but as you guessed it right, that won't happen in time for 4.6.1. Moving the target to 4.6.2.
@Arun, thanks for taking on the mantle of this issue.
@Arun, with the 4.6.2 release data about 60 days away, can you comment on the likelihood this issue will be addressed for its current target milestone?
(In reply to Steven Darnell from comment #17) > @Arun, with the 4.6.2 release data about 60 days away, can you comment on > the likelihood this issue will be addressed for its current target milestone? Hi Steven, I had started looking into this issue but could not complete the fix yet due to a few other issues that cropped up in between. Its already too late for 4.6.2 (RC3 tomorrow) but I'll try to prioritize this for a fix in 4.7 M4 which will then be backported into 4.6.3.
*** Bug 508927 has been marked as a duplicate of this bug. ***
Taking it up for 4.6.3
*** Bug 493080 has been marked as a duplicate of this bug. ***
More work is required in getting the native block code to work. Keeping it for 4.7.
(In reply to Lakshmi Shanmugam from comment #22) > More work is required in getting the native block code to work. Keeping it > for 4.7. Wanted to fix this for 4.7, but had to look into other issues. Will target 4.7.1.
Gerrit change https://git.eclipse.org/r/58786 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a99439d30a7b8da847601ddd9043ac241ce028e9
The above commit is pushed to the master branch for 4.8. The fix involves native changes and needs some good testing as part I-builds before it can be merged to the maintenance branch for 4.7.1.
\o/ Looking forward to testing it out!
Verified with Build I20170813-2000 from (http://download.eclipse.org/eclipse/downloads/drops4/I20170813-2000/) Looking forward to some community testing before backporting to 4.7.1.
Created attachment 269839 [details] Directory dialog is detached Great, seems to work fine. It turns out that there are a number of places that don't use SWT.SHEET that initially threw me off: - New Java Project's location > Browse - Import Maven Projects > Browse Will file bugs.
New Gerrit change created: https://git.eclipse.org/r/103139
(In reply to Brian de Alwis from comment #28) > Created attachment 269839 [details] > Directory dialog is detached > > Great, seems to work fine. > > It turns out that there are a number of places that don't use SWT.SHEET that > initially threw me off: > > - New Java Project's location > Browse > - Import Maven Projects > Browse > Thanks for testing, I too noticed that several dialogs don't use the SHEET style. > Will file bugs. Thanks!
Gerrit change https://git.eclipse.org/r/103139 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=222c313bde4b7033115feac66138c1c9ed95b090
Fixed for 4.7.1 & 4.8M2.
Verified in M20170823-1700
Verified with I20170911-2000.
