Community
Participate
Working Groups
This issue surfaces in resizable content assist. Using SWT.ON_TOP | SWT.RESIZE for the content assist shell allows content assist to be resizable on windows. However, this does not work on X. Resizing on X is controlled by the window manager. If the flag SWT.ON_TOP is set, the window manager does not reparent the window, which includes the trimming. The result is that the shell cannot be resized on X. If the flag SWT.ON_TOP is omitted, we run into another platform specific behaviour, which is the can of worms labled with 'focus events'. The focus is taken by the content assist and all keystrokes are eaten by the shell rather than the editor. SWT.NO_FOCUS is another platform specific flag which does not help in this case. The only solution which comes to my mind is to add widgets (at least in the case of gtk or motif) to allow resize of content assist. It would be nice if there was a better solution to this.
*** Bug 11660 has been marked as a duplicate of this bug. ***
*** Bug 9352 has been marked as a duplicate of this bug. ***
This particular problem has cause lots of grief in the past. On Motif (and GTK), the only way to get a shell to stay on top of all other windows is not use an "override shell" (a special kind of shell that the window manager does not attempt to reparent, hence no trim). Using an "override shell" also affects getting and setting focus for every widget in the shell. The NO_FOCUS is applied. On Motif, this is the mechanism that is used to stop focus from going to a widget (and all children) when tabbing and when clicking. On Windows it is not possible to stop focus from changing in a native control when the user clicks but it is possible to control focus when tabbing. So the NO_FOCUS flag is only intended to be used on leaf widgets of both platforms. Unfortunately, "override shell" and NO_FOCUS have to be used on Motif to get the effect that we want. There is no other mechanism. All of this adds up to a bunch of platform specific behavior that we cannot easily work around. One possibility is to enforce the Motif ON_TOP trimming on Windows. I really hate to do this because the window manager trimming is a hint anyways, it may not be honoured. This is a case where Windows honours it but Motif does not. On the other hand, this is a an area that has caused lots of portability problems so it may be worth it to restrict Windows. As for the NO_FOCUS problem, I'm not sure what to do about this. Grant?
Steve, Can you elaborate on what you mean by "enforce the Motif ON_TOP trimming on Windows"? Grant, any ideas on this topic?
We need a solution for this (see blocked PR). It seems that the only way is to add a custom widget for SWT implementations based on X. A problem is that this can't be done in a platform conformant way. There are two possibilities: 1) add the custom resize widget/decoration to jface.text 2) add the custom resize widget/decoration to swt I would opt for 2) since this would keep platform specific code out of the above layers.
Enforcing the Motif trimming on Windows would mean that when you specified SWT.ON_TOP, we would ensure that there was no trim on the Window, just like what X does. It would be consistent but would not solve your problem. It would mean that your custom resize code would be needed everywhere. As far as I know, there is no way to get a top level shell to have window trim and stay on top and not take focus at the same time on X. GG to investigate resources in the Motif shell that talk about "explicit focus". Maybe these would help?
Notes: - The explicit focus resource (VendorShell.XmNkeyboardFocusPolicy) isn't helpful - With my window manager it's not possible to make a shell resizable without the wm adding full trim - The NO_FOCUS bit isn't meant to work on SWT shells (see the javadoc comment in Composite)
(from Steve) Even if we could get a shell on Linux to have resize handles and not take focus, the window trimming are only a hint. For example, specifying only RESIZE trimming gives full trim (including a title bar) under many Window Managers. This means we can never use the platform window trimming on platforms other than Windows because we have no idea what trimming we will get. There are two possible solutions: 1) use SWT.RESIZE and have a Windows only solution (providing we do not change the current SWT.ON_TOP behavior as described in this PR) (my vote) 2) write your own resizing code (as described by you in this PR). You could put in a DCR for an SWT Custom Widget but this would probably be low priority.
(from Grant) Following is an attached snippet that shows the approach for faking this. Inappropriate pointer warping results from a couple of Tracker bugs.
Created attachment 2414 [details] snippet with "resizable" ON_TOP shell
Kai, Take the pick: Which solution do you prefer? I feel indifferent about this.
Changing to P3.
*** Bug 36128 has been marked as a duplicate of this bug. ***
A solution for this would really be good. It would not only allow to resize the code assist window but also allow to present Ctrl+O and Ctrl+T in the same light-weight manner as under Linux i.e. without shell title bar.
*** Bug 12238 has been marked as a duplicate of this bug. ***
Will SWT fix this for 3.4? We need a solution for the sticky hovers story, and if we don't get a fix in SWT, we will have to cook our own for 3.4.
We're currently taking a final look at this - we will post our findings.
We have some rough code that will address this issue but we have found another issue. It doesn't seem possible to consistently have a resizable window without any additional trim under all window manages. We've tried the following window managers requesting only the resize trim and we get: Metacity - title bar + resize KWin - title bar + resize XFce - (nothing - just the window. It seems that you really need the title bar + trim to resize) MWM - resize only TWM - title bar + resize
Any news here?
Created attachment 87031 [details] Makes a shell resizable on Linux
(In reply to comment #20) > Created an attachment (id=87031) [details] > Makes a shell resizable on Linux We solved the problem by adding mouse listeners to the shell and implementing the resize behavior manually. You need to call makeShellResizeable(shell) for the shell created by the BrowserInformationControl. You have to add some border to the shell so that you can grab it with the mouse. Setting shell background will make the border look nicer. Example: BrowserInformationControl browserInformationControl = new BrowserInformationControl(parent, shellStyle, style); // unfortunately it's private so we have to get the shell with reflection final Shell shell = (Shell)ReflectionUtils.getFieldValue(browserInformationControl,"fShell"); ((GridLayout)shell.getLayout()).marginHeight = 5; ((GridLayout)shell.getLayout()).marginWidth = 5; shell.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_WIDGET_BACKGROUND)); makeShellResizeable(shell);
*** Bug 215385 has been marked as a duplicate of this bug. ***
Steve, this would really be good to have from SWT (see my comment 14 and all the dups).
Steve, do you want to comment on the implementation strategy in comment #21?
FYI: I "solved" our most problematic case (Javadoc hovers) in 3.4 by manually drawing a resize grip (bug 219139) and adding mouse listeners that allow to resize and move the popup. But this is only available for resizable text editor hovers that extend org.eclipse.jface.text.AbstractInformationControl and show a toolbar.
You get following (SWT:18294): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height 275 When trying to resize the sticky hover so it width is zero. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=259540) (In reply to comment #25) > FYI: I "solved" our most problematic case (Javadoc hovers) in 3.4 by manually > drawing a resize grip (bug 219139) and adding mouse listeners that allow to > resize and move the popup. But this is only available for resizable text editor > hovers that extend org.eclipse.jface.text.AbstractInformationControl and show a > toolbar. >
*** Bug 271347 has been marked as a duplicate of this bug. ***
I just want to give a workarround for this bug. I resized the content assist popup window on a Mac OS X and then get the piece of XML written by eclipse in order to save the new size. By setting this piece of XML into an Linux installation of Eclipse, you get the same result. The XML to change is : ${myWorkspaceDir}/.metadata/.plugins/org.eclipse.jdt.ui/dialog_settings.xml Add this section (be carefull, it might already exist but it's then sould be empty) : <section name="completion_proposal_size"> <item value="800" key="size.x"/> <item value="300" key="size.y"/> </section> You can of course change the values. regards
>I just want to give a workarround for this bug This is not a workaround for this bug but only for a concrete instance you're seeing it.
Philippe, thank you VERY much for posting this very helpful hint. I searched on my own and couldn't find this. Good work! Christian
Thanks Philippe, the workaround has helped me put up with this bug. I think that until resizing gets implemented elegantly, it would be a good idea to expose completion_proposal_size in Eclipse Preferences (Java -> Editor -> Content Assist) as it probably require much less analysis, design and implementation (from what I can see the resizability issue is an epic problem). Also, even when resizability finally works on all platforms, some users may still be unaware of this possibility and look in the Preferences for content assist's size controls. It just seems more natural for some people accustomed to less dynamic user interfaces.
(In reply to comment #31) Such a preference field for the size does not fit the spirit of Eclipse. But I heard you, and for 3.6, I released a hand-made resize support for content assist popups and hovers that use the infrastructure from org.eclipse.jface.text. See attachment 138950 [details] in bug 62652. But an SWT fix on GTK would still be very much appreciated! If no SWT fix is in sight for 3.6, we could even consider making the workaround API in JFace. It's not super-clean, since it's not possible for clients of SWT to implement this in a completely transparent way (we can't subclass Shell, and there's no way to hide the innards of composite widgets). But it's not that bad either, and it helps easing a major pain point.
Fixed the SWT.ON_TOP | SWT.RESIZE case in GTK.
Unfortunately, the version in HEAD does not really work for me. 'rpm -q gtk2' says: gtk2-2.2.4-125.17. 1. I cannot make the shell bigger. When I grab an edge, the shell only properly resizes while the mouse is inside the 3px border. It feels like mouse move events are only processed in that area, and if I move the mouse too far out of or into the shell, then only a single last event can also be processed with mouse coordinates outside the border area. 2. The cursor always keeps the direction of the position where the mouse entered the border area. When I e.g start in a corner and then move the mouse away inside an edge trim, the cursor always stays the same, no matter how far I move. 3.(Minor) The corner cursor appears within 10px around the corner. For resizable shells with a title bar, the area in which I the corner cursor is more like 20px. I normally use this machine via VNC, but I verified that it behaves the same when working directly at the machine.
(In reply to comment #34) I verify the problem on our RedHat 4 machine (1) and (2) are fixed in HEAD (old version of GTK don't like OS.GDK_POINTER_MOTION_HINT_MASK) (3) is also fixed, i changed from 9px (border * 3) to 29px (border + 16) Markus, please check if now it works for you. Thank you.
Note that as of the eclipse 3.6 stream that gtk 2.4.x is the oldest gtk version supported by swt. RHEL4 has gtk 2.4.13 (or newer), but Markus is possibly seeing the OS.GDK_POINTER_MOTION_HINT_MASK issue since he's on gtk 2.2.
Resizing works great for me now, thanks. Just two minor caveats: a) When the shell gets very small, the bottom-right resize mode should have precedence over the others (top-left as second choice). That's also what the window manager on my machine does for windows with a title bar. Currently, top-left and top-right get precedence. (WinXP always prefers top-left, but that shouldn't matter here.) b) When I grab the top-right corner and then whirl around the mouse wildly, the bottom edge of the shell is sometimes moved vertically (I think it only happens when I move the mouse across the bottom edge). Likewise, when I stir the bottom-left corner, the shell's right edge can move horizontally. I even managed to move the right edge off-screen, with no way to recover.
(In reply to comment #37) > Resizing works great for me now, thanks. I fixed the first problem. The second one I don't have a fix (in my machine, I have to resize the shell *very* fast to see the problem, low priority).
> I fixed the first problem. Almost. On the right side, top-right still wins over bottom-right. With lines 917 and 918 swapped like this, it's more like what the window manager does: } else if (x >= width - border) { mode = OS.GDK_RIGHT_SIDE; if (y >= height - border - 16) mode = OS.GDK_BOTTOM_RIGHT_CORNER; else if (y <= border + 16) mode = OS.GDK_TOP_RIGHT_CORNER; } ... > 37.(b) low priority Agree (and I wouldn't open a bug if it stays as it is ;-).
(In reply to comment #39) > > 37.(b) low priority > Agree (and I wouldn't open a bug if it stays as it is ;-). It is worse in motif. I think I can fix it by using the strategy you used (saving the bounds and location in mouse down). I initially didn't want to do that because I didn't want to increase memory usage. The way I did (getting the bounds during mouse move) runs in to synchronization problems. I'll refix this...
Fixed in HEAD > 20091113 Fixed the ON_TOP+RESIZE case for GTK and Motif. I think I fixed all the little problems detected by Markus. Thanks. Please open separate reports for other problems that you need fixed (I saw references to NO_FOCUS and some other types of Shell in old comments).
I am seeing this on Version: 2023-03 (4.27.0) on Linux. The window is very small and I can't resize it.
