Community
Participate
Working Groups
There is an extra, empty, column in some tables. This column clips the content of the last real column, so it is very annoying. I see this in the History View, both the graph and file list and the file list in the comit dialog. Googling for this issue in Eclipse on OS X gives me discussions from five years ago.
(In reply to comment #0) > There is an extra, empty, column in some tables. > > This column clips the content of the last real column, so it is very annoying. This is just how it is if columns are used with set widths. If weights were used then they would be "guaranteed" to take up 100% of the space although the column resize behaviour can look a little strange as the table may refuse to grow horizontally depending on how you resize the columns. Personally, I'm not sure why the file listing needs two columns. Couldn't we just have one column and have that one column show an image next to the file's path instead of having them split up explicitly?
(In reply to comment #1) > (In reply to comment #0) > > There is an extra, empty, column in some tables. > > > > This column clips the content of the last real column, so it is very annoying. > > This is just how it is if columns are used with set widths. If weights were > used then they would be "guaranteed" to take up 100% of the space although the > column resize behaviour can look a little strange as the table may refuse to > grow horizontally depending on how you resize the columns. > > Personally, I'm not sure why the file listing needs two columns. Couldn't we > just have one column and have that one column show an image next to the file's > path instead of having them split up explicitly? I have pushed http://egit.eclipse.org/r/#change,2002 to Gerrit which merges the two columns of the file listing into one.
merged http://egit.eclipse.org/r/#change,2002 as 833f678b98cd4740dce486fcaccf74c1508e5271 This does not yet auto-resize the only table column to grab the available space.
(In reply to comment #3) > merged http://egit.eclipse.org/r/#change,2002 as > 833f678b98cd4740dce486fcaccf74c1508e5271 > > This does not yet auto-resize the only table column to grab the available > space. While technically possible by registering a ControlListener and reacting on resize events, I don't think that auto-resizing of columns in tables makes sense, as it would invalidate changes the user might have done. Instead, we should try to save some real estate in the commit graph: 1) shorten the SHA-1 in the ID column 2) make the columns to be shown configurable (so that the user can hide, e.g. ID and Commiter) 3) save the column configuration (visible columns and size/weight) so that they survive a restart. Does this make sense?
(In reply to comment #4) > (In reply to comment #3) > > merged http://egit.eclipse.org/r/#change,2002 as > > 833f678b98cd4740dce486fcaccf74c1508e5271 > > > > This does not yet auto-resize the only table column to grab the available > > space. > > While technically possible by registering a ControlListener and reacting on > resize events, I don't think that auto-resizing of columns in tables makes > sense, as it would invalidate changes the user might have done. Instead, we > should try to save some real estate in the commit graph: > > 1) shorten the SHA-1 in the ID column > 2) make the columns to be shown configurable (so that the user can hide, e.g. > ID and Commiter) > 3) save the column configuration (visible columns and size/weight) so that they > survive a restart. > > Does this make sense? Not from the perspective I had when writing this bug report. The issue I had was that horribly stupid annoying extra column that appears or grows when I resize the window containing the table. The last column should be auto-extended somehow. A possible solution would be to remember window sizes, since in some cases that extra column *only* appears when resizing.
(In reply to comment #4) > (In reply to comment #3) > > merged http://egit.eclipse.org/r/#change,2002 as > > 833f678b98cd4740dce486fcaccf74c1508e5271 > > > > This does not yet auto-resize the only table column to grab the available > > space. > > While technically possible by registering a ControlListener and reacting on > resize events, I don't think that auto-resizing of columns in tables makes > sense, as it would invalidate changes the user might have done. Instead, we > should try to save some real estate in the commit graph: > > 1) shorten the SHA-1 in the ID column > 2) make the columns to be shown configurable (so that the user can hide, e.g. > ID and Commiter) > 3) save the column configuration (visible columns and size/weight) so that they > survive a restart. > > Does this make sense? As an improvement in general this makes size.
I've attached a change set to Gerrit but the resize behaviour may not be what you guys want. http://egit.eclipse.org/r/#change,2013
(In reply to comment #7) > I've attached a change set to Gerrit but the resize behaviour may not be what > you guys want. > http://egit.eclipse.org/r/#change,2013 Per the summary, I've only changed the graph table. For the file listing I think we can just forget about them and do away with the columns completely. I mean, it's pretty obvious that (single) column is the 'Path' column.
(In reply to comment #8) > (In reply to comment #7) > > I've attached a change set to Gerrit but the resize behaviour may not be what > > you guys want. > > http://egit.eclipse.org/r/#change,2013 > > Per the summary, I've only changed the graph table. For the file listing I > think we can just forget about them and do away with the columns completely. I > mean, it's pretty obvious that (single) column is the 'Path' column. Good point. I pushed http://egit.eclipse.org/r/#change,2079 for this.
merged http://egit.eclipse.org/r/#change,2079 as 836ddd1e70f16c209fee3cfac70249b12b85b5ba now the file list is nicely resizing :-)
Created attachment 184802 [details] Screenshot Attached screenshot shows that data get lost when the total size exceeds the available space. Since there is not scrollbar, these date will not be visible.
So Mathias asked (in Gerrit) what should be done if the resize problem(s) in patch set 1 of change I8abf7baa could not be worked around. I think we have to look at our available options and then just decide which one we want to do. 1. Maintain status quo and do nothing. 2. Merge patch set 1 of change I8abf7baa in and live with it. 3. Use some assortment of resize listeners to try to size each column appropriately. 4. Use some assortment of resize listeners to try to only size the last column so it takes up all of the remaining space. Maybe only one listener is needed, I'd have to actually try implementing this to be sure. 5. Implement comment 4. 6. Call pack() on all but the first column so that the text is guaranteed to be readable. Calling pack() on the first column is useless because the content is custom drawn. You'd have to react to the SWT.MeasureItem event to get the column to size right I believe. 7. Keep brainstorming.
I can not reproduce the problem mentioned in comment 11 as there is a scrollbar if the contents do not fit. Resolving as fixed.
