Community
Participate
Working Groups
3.0 RC3 On some platforms (or with large font etc), the size required to show all the options that can be set on a widget is larger than the monitor. Some of the buttons to set values are clipped and can not be accessed. Possible solutions: Use a Scrolled Composite for the widget and parameter area so that you can scroll to the items rather than have them badly clipped. Have a tabbed folder with one tab for each parameter type. In this case, maybe it makes more sense to put the parameters below the example widgets. Maybe there should be a sash between the Listeners area and the top part.
*** Bug 81247 has been marked as a duplicate of this bug. ***
Created attachment 90641 [details] Fix This bug makes the ControlExample unusable on our Linux test box (remote access with a small screen). Here's a fix that wraps the control group into a ScrolledComposite and ensures that the listener output area keeps a minimal size. Adding a sash above the listeners area would also be nice -- I just fixed the immediate problem that was blocking me.
I just had to apply the patch again. Luckily, it still worked without conflicts:-)
Ping ;-)
Hi, guys. Sorry I didn't get back to you before. There were a couple of reasons that I didn't want to just go with this patch. The most important reason is that we didn't want to have any reference to org.eclipse.swt.custom in ControlExample. i.e. the custom controls are based on the swt (native) controls , and not the other way around. I played around with adding a sash a while ago, but I had some problem on the Mac - can't recall what it was. Then I ran out of time. I'll try again for an hour or so today. Please tell me which controls are clipped on your Linux test box - is it just the listeners area? Is it the tabfolder at the top? Or something else? If possible, please attach a snapshot or two. Thanks!
Created attachment 164097 [details] Screenshot The screen is just too small. You can easily reproduce exactly the same problem under Windows when you just make the shell smaller. A sash alone won't help. We need scrollbars around the "Parameters" group, otherwise the listeners area is not visible (that's the case in HEAD) or the parameters are cut (if you just set a min height to the listeners area).
Created attachment 164102 [details] Patch to add horizontal sash above listeners group I see. If there are a lot of "Control Group" controls on a page (like on Tree, Table, and Text tabs) then you can't even *reach* the sash that I just added. Here is the "sash patch", just so that I don't lose it. It needs a bit more work (need to determine the minimum height of the "example" and "control" groups and not let the user go past that). Also needs to be tested on Mac and GTK. It would only help you with your problem for some of the tab pages, but not the biggest ones. I am pretty sure that my patch would break your patch (because my Sash doesn't know about your ScrolledComposite), so I am not going to commit it yet. <g> I will speak with SSQ about having a custom.ScrolledComposite in the ControlExample. Or maybe I will try to hack up a vertical scrollbar without a ScrolledComposite. But not today (sorry). I have to get back to work now. :)
Reimplementing SashForm and ScrolledComposite to solve this bug sounds wrong.
> Reimplementing SashForm and ScrolledComposite to solve this bug sounds wrong. Not really. :) I think it's important not to have any custom controls in the ControlExample. Besides, the Sash patch is only about 14 lines of real code... The vertical scrollbar code might not be too bad either. I'll check it out when I'm less swamped.
I strongly need this to be fixed for my Linux machine. Most of the times, I am not able to see the 'Listener console output area' as my laptop screen couldn't accomodate the ControlExample (for tabs such as Table, Text, Tree are worse as they have more options to display). Is there any possibility or plans for this to be fixed in the current stream 3.6 ?
Ping. ControlExample is still unusable without a huge screen.
This must be fixed now. Easiest fix is the patch from comment 2 (still does the job, just had to use it again).
(In reply to comment #12) > This must be fixed now. Easiest fix is the patch from comment 2 (still does > the job, just had to use it again). Yes please just do it :-)
Markus, we don't want to have any custom controls in the ControlExample. Do you want to have a crack at fixing this without using custom controls? Perhaps take only the relevant pieces of ScrolledComposite and reuse them.
(In reply to comment #14) > Markus, we don't want to have any custom controls in the ControlExample. What's the problem of *using* it so that the "normal" controls can be tested? I don't get the point of that (yet).
>> Markus, we don't want to have any custom controls in the ControlExample. > What's the problem of *using* it [...]? Yeah, sounds like saying "we don't want to use GridLayout in the ControlExample" -- which you didn't do for good reasons. > Perhaps take only the relevant pieces of ScrolledComposite and reuse them. Then I'd rather copy the whole class, so that it can at least be updated easily.
In reply to comment 15: Because it should be possible to completely remove extra packages like the custom controls and use SWT in a stripped-down version on small devices. We have been very careful since the beginning to make sure that has always remained true. i.e. there are no references to custom controls within the regular swt packages. If we allow a ScrolledComposite in the ControlExample, then the example wouldn't work at all for testing a stripped-down version of swt. Also, it's a conceptual thing - there's a ControlExample and a CustomControlExample, and we want them kept separate. SSQ says it should be possible to do this relatively simply with one parent (of the main tabFolder) with scrollbars. Snippet9 (http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet9.java) should have some clues for how this might be done. Sorry I originally got hung up on using a sash to fix this. I just looked again at the snapshot in comment 6 and I see that sash would not be as useful as scrolling the whole window. Better to have scrollbars appear when needed. All yours, Markus. :)
In reply to comment 16: > Yeah, sounds like saying "we don't want to use GridLayout in the > ControlExample" -- which you didn't do for good reasons. I don't understand? GridLayout is all through the ControlExample. >> Perhaps take only the relevant pieces of ScrolledComposite and reuse them. > Then I'd rather copy the whole class [...] Actually, please try the simple thing first. :)
> I don't understand? GridLayout is all through the ControlExample. Exactly my point. GridLayout is in the org.eclipse.swt.layout package and it's still used in the ControlExample and not only in LayoutExample? That means a stripped-down version of SWT that doesn't use layouts can't run the ControlExample. ScrolledComposite is similarly basic as GridLayout, and it's used everywhere in UI code. It's even more necessary on small devices, as this bug shows. The basic problem is that ScrolledComposite is in the wrong package from an API client's point of view. I'm sure this could even have been implemented with native APIs on some platforms, so it could just as well have gone into the widgets package. A stripped-down version of SWT should actually include ScrolledComposite, so I'd even call it a feature that the ControlExample makes this apparent. > Actually, please try the simple thing first. :) ScrolledComposite does exactly what we need. Snippet9 always shows scrollbars, even if they're not necessary -- not particularly nice in a showcase app...
In reply to comment 19: > a stripped-down version of SWT that doesn't use layouts [...] I would almost argue that you are right and we should take all layouts out of ControlExample. <GRIN> Actually, we have always considered the layout package to be one of the more basic ones. :) ScrolledComposite doesn't belong in the controls package because it is not native. Its API is arbitrary. It was created to solve Eclipse problems. I will grant you that it is useful, but it is not strictly necessary. > Snippet9 always shows scrollbars, even if they're not necessary Here is Snippet9 rewritten to only show scrollbars as-needed. This satisfies the constraint of not using a custom control. Hope this helps. /******************************************************************************* * Copyright (c) 2000, 2004 IBM Corporation and others. * All rights reserved. This program and the accompanying materials * are made available under the terms of the Eclipse Public License v1.0 * which accompanies this distribution, and is available at * http://www.eclipse.org/legal/epl-v10.html * * Contributors: * IBM Corporation - initial API and implementation *******************************************************************************/ package org.eclipse.swt.snippets; /* * Composite example snippet: scroll a child control automatically * * For a list of all SWT example snippets see * http://www.eclipse.org/swt/snippets/ */ import org.eclipse.swt.*; import org.eclipse.swt.events.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.widgets.*; public class Snippet9 { public static void main (String [] args) { Display display = new Display (); final Shell shell = new Shell (display, SWT.SHELL_TRIM | SWT.H_SCROLL | SWT.V_SCROLL); final Composite composite = new Composite (shell, SWT.BORDER); composite.setSize (700, 600); final Color red = display.getSystemColor (SWT.COLOR_RED); composite.addPaintListener (new PaintListener() { public void paintControl (PaintEvent e) { e.gc.setBackground (red); e.gc.fillOval (5, 5, 690, 590); } }); final ScrollBar hBar = shell.getHorizontalBar (); hBar.addListener (SWT.Selection, new Listener () { public void handleEvent (Event e) { Point location = composite.getLocation (); location.x = -hBar.getSelection (); composite.setLocation (location); } }); final ScrollBar vBar = shell.getVerticalBar (); vBar.addListener (SWT.Selection, new Listener () { public void handleEvent (Event e) { Point location = composite.getLocation (); location.y = -vBar.getSelection (); composite.setLocation (location); } }); shell.addListener (SWT.Resize, new Listener () { public void handleEvent (Event e) { Point size = composite.getSize (); Rectangle rect = shell.getClientArea (); Point location = composite.getLocation (); if (rect.width > size.x) { hBar.setVisible(false); } else { hBar.setVisible(true); hBar.setMaximum (size.x); hBar.setThumb (rect.width); int hPage = size.x - rect.width; int hSelection = hBar.getSelection (); if (hSelection >= hPage) { if (hPage <= 0) hSelection = 0; location.x = -hSelection; } } if (rect.height > size.y) { vBar.setVisible(false); } else { vBar.setVisible(true); vBar.setMaximum (size.y); vBar.setThumb (rect.height); int vPage = size.y - rect.height; int vSelection = vBar.getSelection (); if (vSelection >= vPage) { if (vPage <= 0) vSelection = 0; location.y = -vSelection; } } if (hBar.getVisible() || vBar.getVisible()) { composite.setLocation (location); } } }); shell.setSize(600, 500); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } }
ScrolledComposite and comment 20 look bad on Windows due to bug 234649.
The code in comment 20 is a bit simplistic. I think that when you are deciding whether to hide a scrollbar, you will also need to account for the width of the other scrollbar. See ScrolledComposite.needHScroll/needVScroll() for sample code.
Markus, are you still planning this for RC1?
> Markus, are you still planning this for RC1? Yes, unless someone else finds a free hour to implement it. Since the simple fix (comment 2) was not accepted, the fix will be to copy ScrolledComposite and remove stuff that's not needed in the control example.
The snippet in comment 20 is very close. It just needs a few more lines of code as mentioned in comment 22.
Note that we fixed bug 234649 for you. :)
Moving out of 4.7. Markus, please re-target as required.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
