Community
Participate
Working Groups
TableLayout doesn't follow the expected protocol of a layout. 1. It only lays out once, and ignores subsequent changes in size. 2. Setting a Table to size A followed by size B will result in a different layout than setting it to size C followed by size B. (Layouts should be purely a function of the current size, and should not be affected by previous sizes) 3. If the widget is never given a nonzero size, it will never initialize the column widths. This layout behaves more like a deferred column initializer than a layout, causing bug 86329 in the problems view and bug 41800 in the PDE error view. Both views now contain workarounds, but it would be nice if this extra code was not necessary.
*** This bug has been marked as a duplicate of 94467 ***
This is not really a duplicate of bug 94467. There is a real problem with TableLayout. There is a lengthy discussion of this problem in Bug 13467.
*** Bug 95030 has been marked as a duplicate of this bug. ***
Should this be marked as an enhancement? This seems like a real issue we should deal with for 3.1.
I flagged it as an enhancement to avoid a debate about what is a bug and what is permissable intended behavior. Boosting severity to minor.
Upping to normal since my bug was marked as a duplicate although I'm starting to think that this is actually fairly major. Getting tables to layout shouldn't be as difficult as it is now. We have some overly complicated table column code in Team/CVS preference pages all because the table weighting doesn't work.
I agree. I actually logged quite a few bugs this release relating to bogus table layouts...
*** Bug 96057 has been marked as a duplicate of this bug. ***
Can we please get an indication of the plan on this bug for 3.1. The Ant preference pages were working and then the layout stopped working. So either this is a breaking change OR a guide should be provided on what we were doing wrong and why that no longer works and how to fix it.
*** Bug 96285 has been marked as a duplicate of this bug. ***
And just to add my 2c. This small issue makes playing with CVS tagging and branching quite dangerous, as you may not be able to see the full tag names (when you have long tage names) and therefore ruin your branching/tagging.
We haven't made any significant changes to this since 2003 (Nick added some trim code for Bug 90712). Veronika is there potentially some SWT Table changes causing this?
TableLayout has always been used as a deferred column initializer, not a true layout. I don't think we should change it for 3.1, since existing clients expect the initial layout only. Stefan, since TableLayout has not changed in 3.1 (except for the trim thing), can you explain what changes led to the regressions in the Error Log and Ant pref pages? I understand that bug 75945 explains the marker view cases, but what about the others?
It seems like views using TableLayout should not persist the column widths if they are 0 (i.e. TableLayout hasn't done its thing yet).
The bugs this was marked as a dup of are different - this is a behavioural change request rather than a layout error. The layout error is described in Bug 96440
As mentioned in Bug 13467, you can not really use a Layout to get proportionally sized columns. The problem is that the sizing has to occur before the parent has changed size. This is necessary to avoid scrollbars appearing then disappearing when the columns are resized. By the time the layout is invoked on the Table it is too late. As described in Bug 13467, the solution is to add a Resize listener to the parent of the Table and resize the columns in the resize listener. The code showing how to do this is in Bug 13467. SWT is not planning to make any changes to Table that would change this.
Interesting. Is it possible that the TableLayout in JFace only worked for the initial table layout and not for resizes? It turns out that JDT rolled their own solution for this (org.eclipse.jdt.internal.ui.util.TableLayoutComposite). I've tried it out in a few of the CVS scenarios and it works. The only problem is that the class works when used as the parent composite. I'll look into the possibility of incorporating the component resize listener into TableViewer so exisiting clients will be fixed without writing additional code.
Yes - that is the gist of the original part of this report.
BTW Veronika can you explain why the Ant Runtime page was getting an acceptible size in M6 and aren't now? Was it an SWT change or a change in thier code?
See Bug 96440 for a description of the sizing issues I am seeing. I have just checked and there has been no significant change to either the TableLayout or AntPage since M6.
Tod, many of the problems we have seen have been with preference pages. Was there a change in how preference pages are created? Could it be possible that in M6, they were being created at an initial size that made the tables appear OK but in M7 they were originally created small and then resized which would surface the shortcomings of TableLayout?
As discussed in Bug 94467, there was a resize event even though the client area was still of size (0,0). I believe this was introduced after M6 and has been fixed for M7. The TableLayout code does not guard against an initial resize event to a width that is too small to be usable - it never has.
Actually, TableLayout.layout has had the following for quite some time (since rev 1.1): int width = table.getClientArea().width; // XXX: Layout is being called with an invalid value the first time // it is being called on Linux. This method resets the // Layout to null so we make sure we run it only when // the value is OK. if (width <= 1) return;
Ha!!! I changed that line to this and it works! if (width <= 1 || table.getClientArea().height <= 1) return; Not sure how valid it is but it may be something.
Oops, sorry, ignore my last post. I had a bunch of changes in my workspace so it was something else that worked (but not entirely). I'll shut up now and stop bombarding people with spam.
Assigning to Tom and adding myself to the cc. I did an initial pass of this in Bug 13467 which Tom has tidied up.
Created attachment 51696 [details] Implementation from bug #13467
Created attachment 51697 [details] Snippet to test
Created attachment 51698 [details] Fixed copyright
Patch released for build >20061010. I renamed the class to TableAdapter as it is not really tied to the TableLayout but is a subclass of the ControlAdapter. I have also added a reference to TableAdapter in the TableLayout class comment.
Thanks! Is there plans to release a TreeAdapter as well? I assume its just a matter of changing the TableAdapter to work with a Tree and TreeColumns.
I'll look into it my feeling is that TableAdapter should be renamed to ColumnAdapter and work for both Table and Tree.
That would depend on time to work on it (I had already written most of this when Tom finished it up for me). If you wanted to do the Tree version and submit a patch I would be happy to review it (in a seperate Bug).
(In reply to comment #32) > I'll look into it my feeling is that TableAdapter should be renamed to > ColumnAdapter and work for both Table and Tree. Yes, I was looking for something like that.
(In reply to comment #34) > (In reply to comment #32) > > I'll look into it my feeling is that TableAdapter should be renamed to > > ColumnAdapter and work for both Table and Tree. > > Yes, I was looking for something like that. > Please look in bug #160505 to see a widget independent implementation.
(In reply to comment #35) > (In reply to comment #34) > > (In reply to comment #32) > > > I'll look into it my feeling is that TableAdapter should be renamed to > > > ColumnAdapter and work for both Table and Tree. > > > > Yes, I was looking for something like that. > > > > Please look in bug #160505 to see a widget independent implementation. > Great! Would be nice to have it added to M3 :)
Tom, could you have a look at TableLayoutComposite (part of org.eclipse.jdt.ui)? It seems JDT/UI already had something like this, but not as API. Their code was written three years ago, so it's probably well tested. We should at least look at bugs referenced in the revision history of this file, as well as go through their code and comments to see if there is anything we haven't thought of yet.
(In reply to comment #37) > Tom, could you have a look at TableLayoutComposite (part of > org.eclipse.jdt.ui)? It seems JDT/UI already had something like this, but not > as API. Their code was written three years ago, so it's probably well tested. > We should at least look at bugs referenced in the revision history of this > file, as well as go through their code and comments to see if there is anything > we haven't thought of yet. > I'll look at it and try to find out what's done there.
