Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Nebula » [CompositeTable] UI and design questions
[CompositeTable] UI and design questions [message #34362] Tue, 08 May 2007 05:17 Go to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Dave Orme is currently offline Dave OrmeFriend
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 Go to previous message
Roland Tepp is currently offline Roland TeppFriend
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 Go to previous message
Dave Orme is currently offline Dave OrmeFriend
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 Go to previous message
Roland Tepp is currently offline Roland TeppFriend
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
Previous Topic:CompositeTable and item groups...
Next Topic:CDateTime border
Goto Forum:
  


Current Time: Sat Sep 19 16:36:48 GMT 2020

Powered by FUDForum. Page generated in 0.06378 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top