Home » Eclipse Projects » Nebula » [CompositeTable] UI and design questions
| [CompositeTable] UI and design questions [message #34362] |
Tue, 08 May 2007 05:17  |
Eclipse User |
|
|
|
Originally posted by: h3.miegel.org
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
|
|
|
| Re: [CompositeTable] UI and design questions [message #34497 is a reply to message #34362] |
Thu, 10 May 2007 14:21  |
 Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
I'm supportive of the work Nigel is proposing but I also want to hear
what the community thinks. (Thanks Nigel!)
Dave Orme
Nigel wrote:
> 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
>
>
|
|
|
| Re: [CompositeTable] UI and design questions [message #34997 is a reply to message #34362] |
Wed, 16 May 2007 11:50 |
Roland Tepp
Messages: 336
Registered: July 2009 |
Senior Member |
|
|
Hi Nigel,
Nigel kirjutas mulle midagi seesugust:
> 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.
Nice work (can't wait to see what you've done...)
If you've been fixing the scrolling logic, maybe you'd also like to take
a look at the minor scrollbar layout bug I recently discovered. When
CompositeTable is created with SWT.BORDER style, the scrollbar is
positioned about 2 pixels behind the border. I assume this is because
the layout manager does not consider clientArea of the CompositeTable
when laying out widgets, but uses getBounds instead... (thus not taking
into account any trims the widget might have)
> 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?
Definitely, the selected row should be allowed to be scrolled off the
visible area. I would even go so far as to suggest that the selected row
item should not be reused until another row has been selected, thus
greatly simplifying any selection dependent code (e.g. color changes)
that currently needs to be written.
> 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.
I would expect that CompositeTable would handle and manage row item
selection, but leave the model selection management (and binding) up to
the higher level APIs.
As such I don't see any reason CompositeTable should be aware of sorting
or filtering, as strictly speaking, those are operations on the model
and not view.
> 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.
Again, these operations should probably be the domain of presentation
model or controller logic rather than CompositeTable.
--
Roland Tepp
|
|
|
| Re: [CompositeTable] UI and design questions [message #582143 is a reply to message #34362] |
Thu, 10 May 2007 14:21 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
I'm supportive of the work Nigel is proposing but I also want to hear
what the community thinks. (Thanks Nigel!)
Dave Orme
Nigel wrote:
> 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
>
>
|
|
|
| Re: [CompositeTable] UI and design questions [message #582404 is a reply to message #34362] |
Wed, 16 May 2007 11:50 |
Roland Tepp
Messages: 336
Registered: July 2009 |
Senior Member |
|
|
Hi Nigel,
Nigel kirjutas mulle midagi seesugust:
> 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.
Nice work (can't wait to see what you've done...)
If you've been fixing the scrolling logic, maybe you'd also like to take
a look at the minor scrollbar layout bug I recently discovered. When
CompositeTable is created with SWT.BORDER style, the scrollbar is
positioned about 2 pixels behind the border. I assume this is because
the layout manager does not consider clientArea of the CompositeTable
when laying out widgets, but uses getBounds instead... (thus not taking
into account any trims the widget might have)
> 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?
Definitely, the selected row should be allowed to be scrolled off the
visible area. I would even go so far as to suggest that the selected row
item should not be reused until another row has been selected, thus
greatly simplifying any selection dependent code (e.g. color changes)
that currently needs to be written.
> 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.
I would expect that CompositeTable would handle and manage row item
selection, but leave the model selection management (and binding) up to
the higher level APIs.
As such I don't see any reason CompositeTable should be aware of sorting
or filtering, as strictly speaking, those are operations on the model
and not view.
> 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.
Again, these operations should probably be the domain of presentation
model or controller logic rather than CompositeTable.
--
Roland Tepp
|
|
|
Goto Forum:
Current Time: Tue Apr 23 13:52:05 GMT 2024
Powered by FUDForum. Page generated in 0.03378 seconds |
] 
Search
Help
Register
Login
Home
