| [CompositeTable] UI and design questions [message #582045] |
Tue, 08 May 2007 05:17 |
 Nigel
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
I am currently in the process of preparing for submission a patch to
CompositeTable. This patch will add support for variable sized and dynamic
sized rows. Because so much of the scrolling logic assumes all rows to be
the same size, this has unfortunately ended up being a re-write of the
scrolling logic.
I have been trying to keep the behavior the same as much as possible.
However, it is not clear to be what behavior is by deliberate design and
what behavior is just because that is what come out of the code.
I decided to take a look at a couple of Windows applications for comparison.
These being Outlook 2002 and Quicken 98.
scroll bar: One of the complications in CompositeTable is what happens when
the selected row is scrolled out of view using the scroll bar.
CompositeTable moves the selected row to another row in order to keep the
selected row visible. Both Outlook and Quicken allow the selected row to be
scrolled out of view, but it remains the selected row. I believe some
complications in the CompositeTable would be avoided if we did the same
behavior. Does anyone have any views on this?
sorting: Outlook will keep the selection during sorting. The table is
scrolled so that the selected row is the top row in the visible area.
Quicken did not support sorting. I believe CompositeTable should do the
same. See bug 174041
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=174041). It is suggested in
this bug that the user programmer should have to clear the selection before
sorting and then reset it. I believe CompositeTable should handle the
selection, and no selection change event (arrive or depart) should be fired
when a sort happens. This will not be difficult to do, but I wanted to
check that this behavior is ok with the community.
If a new row is inserted into the underlying model (by someone outside the
CompositeTable) then the only way the user programmer can update the table
is to call setNumRowsInCollection. This causes a complete refresh, losing
the current row selection and so on. Does anyone else need to update the
table from the model input, and how do you solve this problem? It seems to
me that we need methods to do these updates (insert row, delete row, and
update row), unless I am missing something.
Is there any reason to have both currentVisibleTopRow and topRow fields? It
seems to me these are the same and these appear to be used interchangably.
Also numRowsVisible and rows.size() would appear to be the same.
That is probably enough for now,
Nigel Westbury
|
|
|
Powered by
FUDForum. Page generated in 0.02413 seconds