Community
Participate
Working Groups
From the javadoc I expected TableEditor would track a cell size and resize its editor automatically whenever the cell is resized, especially when setting grabHorizontal and grabVertical to true and when using a TableColumnLayout on the composite containing the table. According to https://bugs.eclipse.org/bugs/show_bug.cgi?id=289319#c3, it is intended that the TableEditor does not automatically resize. But I wonder if that’s right? The javadoc about TableEditor states: “A TableEditor is a manager for a Control that appears above a cell in a Table and tracks with the moving and resizing of that cell.” And according to https://bugs.eclipse.org/bugs/show_bug.cgi?id=134003 the table editor seems to be supposed to track (some) resize events. How to properly use a table editor? Could the javadoc be clarified? Here is a sample code that exhibit a table editor’s control being not initially of the right size (this is just an example of the kind of problems that may occur however, the bug report I pointed at exhibits other examples). Display display = new Display(); Shell shell = new Shell(display); TableColumnLayout tableColumnLayout = new TableColumnLayout(true); shell.setLayout(tableColumnLayout); Table table = new Table(shell, SWT.MULTI | SWT.BORDER | SWT.FULL_SELECTION); table.setLinesVisible(true); table.setHeaderVisible(true); TableColumn c1 = new TableColumn(table, SWT.NONE); c1.setText("c1"); tableColumnLayout.setColumnData(c1, new ColumnWeightData(1, 100)); TableColumn c2 = new TableColumn(table, SWT.NONE); c2.setText("c2"); tableColumnLayout.setColumnData(c2, new ColumnWeightData(1, 100)); TableItem item1 = new TableItem(table, SWT.NONE); Text text = new Text(table, SWT.NONE); TableEditor tableEditor = new DebugTableEditor(table); tableEditor.setEditor(text, item1, 0); tableEditor.grabHorizontal = true; tableEditor.grabVertical = true; shell.setSize(1000, 200); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose();
(In reply to Olivier Cailloux from comment #0) > Here is a sample code that exhibit a table editor’s control being not > initially of the right size (this is just an example of the kind of problems > that may occur however, the bug report I pointed at exhibits other examples). Hey ya, I tried the snippet (with a few modifications), the table seems to resize itself, including the editable part? Can you clarify, in detail the steps to reproduce, the expected behaviour and what is not working with you? A screenshot would be beneficial. Which version of Gtk are you on, which OS & version of Eclipse are you running? (I usually find 'gtk' in my package manager).
Created attachment 267532 [details] At opening time. The text control bounds are incorrect: the control is not visible.
Created attachment 267533 [details] After having wait a bit. The editor has called layout after the timer has expired. The text control bounds are now correct.
Here is a replacement for the second half of the code above, that shows clearly the problem. text.setText(String.join("", Collections.nCopies(50, "a"))); final TableEditor tableEditor = new TableEditor(table); tableEditor.setEditor(text, item1, 0); tableEditor.grabHorizontal = true; tableEditor.grabVertical = true; shell.setSize(1000, 200); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { Thread.sleep(3000); display.sleep(); } } display.dispose(); You should see that at opening time, the editor control is not visible. It only becomes visible when the timer internal to the table editor expires, which triggers a re-layout. (See attached screenshots.) Here is a replacement for the second half of the code above, that exhibit the problem as log statements and permits to understand better what’s happening. text.setText(String.join("", Collections.nCopies(50, "a"))); TableEditor tableEditor = new TableEditor(table); tableEditor.setEditor(text, item1, 0); tableEditor.grabHorizontal = true; tableEditor.grabVertical = true; shell.setSize(1000, 200); shell.layout(); tableEditor.layout(); LOGGER.info("Text bounds: {}.", text.getBounds()); shell.open(); LOGGER.info("Text bounds after opening: {}.", text.getBounds()); tableEditor.layout(); LOGGER.info("Text bounds after opening and re-layout: {}.", text.getBounds()); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); On my machine this shows: INFO i.g.o.pdf_number_pages.App - Text bounds: Rectangle {2, 1, 1, 17}. INFO i.g.o.pdf_number_pages.App - Text bounds after opening: Rectangle {1, 1, 488, 17}. INFO i.g.o.pdf_number_pages.App - Text bounds after opening and re-layout: Rectangle {2, 29, 488, 26}. As you can see, the text bounds change thanks to the second call to layout to the tableEditor. If you remove the second call, the text bounds are incorrect when the shell opens. In the bug I linked to in my original comment it is explained that this behavior is (supposedly) expected. Hence, this bug report is not so much about the behavior observed in this code snippet per se, but rather a request for better documentation about how table editors are supposed to be used and what can be expected about their behavior.
$ apt-show-versions | grep libgtk libgtk-3-0:amd64/jessie 3.14.5-1+deb8u1 uptodate libgtk-3-bin:amd64/jessie 3.14.5-1+deb8u1 uptodate libgtk-3-common:all/jessie 3.14.5-1+deb8u1 uptodate libgtk-vnc-2.0-0:amd64/jessie 0.5.3-1.3 uptodate libgtk2-perl:amd64/jessie 2:1.2492-4 uptodate libgtk2.0-0:amd64/jessie 2.24.25-3+deb8u1 uptodate libgtk2.0-bin:amd64/jessie 2.24.25-3+deb8u1 uptodate libgtk2.0-cil:amd64/jessie 2.12.10-5.1 uptodate libgtk2.0-common:all/jessie 2.24.25-3+deb8u1 uptodate libgtkglext1:amd64/jessie 1.2.0-3.2 uptodate libgtkhtml-4.0-0:amd64/jessie 4.8.5-1 uptodate libgtkhtml-4.0-common:all/jessie 4.8.5-1 uptodate libgtkhtml-editor-4.0-0:amd64/jessie 4.8.5-1 uptodate libgtkmm-2.4-1c2a:amd64/jessie 1:2.24.4-1.1 uptodate libgtkmm-3.0-1:amd64/jessie 3.14.0-1 uptodate libgtksourceview-3.0-1:amd64/jessie 3.14.1-1 uptodate libgtksourceview-3.0-common:all/jessie 3.14.1-1 uptodate libgtkspell0:amd64/jessie 2.0.16-1.1 uptodate libgtkspell3-3-0:amd64/jessie 3.0.6-1 uptodate $ uname -a Linux Saucisson 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux Eclipse Version: Neon Release (4.6.0) Build id: 20160613-1800 This is a maven project with standalone access to SWT. I use the official 3.105.2 SWT library from Maven Central (http://search.maven.org/#search|ga|1|g:%22org.eclipse.platform%22%20a:%22org.eclipse.swt%22)
Working code on this repo: https://github.com/oliviercailloux/swt-tests . See the code here: https://github.com/oliviercailloux/swt-tests/blob/master/src/main/java/io/github/oliviercailloux/y2017/swt_tests/TableEditorApp.java . The code itself generates two screenshots that show the text control jumping from its original position (wrong) to its correct position, see https://github.com/oliviercailloux/swt-tests/blob/master/swt-start.png and https://github.com/oliviercailloux/swt-tests/blob/master/swt-later.png .
There were fixes for TableEditor in 4.8. Can you reproduce the issue on GTK3.22?
Exactly the same observable behavior with 3.105.3 on my machine having libgtk 3.22.11-1. (Code has been updated on GitHub to reflect the new SWT version.) I think we should first clarify the intent of the code. This will permit to know whether the bug is about the documentation being incorrect (or incomplete) or the behavior being incorrect. (And it’s a good thing to do anyway.) The javadoc about TableEditor states: “A TableEditor is a manager for a Control that appears above a cell in a Table and tracks with the moving and resizing of that cell.” Thus, I feel entitled to deduce that TableEditor would track a cell size and resize its editor automatically whenever the cell is resized, especially when setting grabHorizontal and grabVertical to true and when using a TableColumnLayout on the composite containing the table. Is this deduction correct? Is it mandatory to set grabHorizontal and grabVertical to true and use a TableColumnLayout on the composite containing the table for the tracking to happen? Or is it simply not supposed to happen? According to https://bugs.eclipse.org/bugs/show_bug.cgi?id=289319#c3, it is intended that the TableEditor does not automatically resize. That contradicts the javadoc. On the contrary, according to https://bugs.eclipse.org/bugs/show_bug.cgi?id=134003, the table editor seems to be supposed to track (some) resize events.
