Notes on ListGrid, what is your opinion PLZ?

[jzaruba]

I have couple of "issues" with ListGrid, but I feel like sanjiv.jivan must be becoming my fan by now because all of my "complaints" on Google Code. :)
So I would like to read also other developers' opinion...
For me designing a GUI and GUI-components development belong surprisingly to those more challenging jobs in programming, so please keep in mind that this is not meant as bashing on the SmartGWT.

A removal is not a selection.
Clicking a removal column should not select the row. (Currently this fires SelectEvent for that row.) One could answer "clicking a row just selects it", but from a user's point of view there is a significant difference between clicking to select and clicking something what appears to be a removal button/icon. When user is clicking 'delete' icon he is not selecting, hence the additional SelectEvent is kinda odd here.
It would be nice if the grid selection remained unchanged (when removing a row that is not selected obviously), but there (!is) should be an easy workaround for that.

Clicking is a cause, selection is a result.
When clicking a row SelectEvent for this row should be fired after RecordClickEvent.
This BTW further complicates the first issue, when within a RecordClickEvent you could store current selection and restore it later based on what column has been clicked (i.e. whether user actually intended only to select a row or not)...

You should know when selection changes.
Removing selected row should also trigger SelectEvent, well, because the selection got changed.

I am sorry if this looks like I don't have better stuff to do than nit-picking on SmartGWT/ListGrid, but I think the above mentioned behaviours go against predictability of the GUI and natural order of its events, which inevitably complicates some tasks...

[Isomorphic]

Actually, mousedown is the cause of the selection change, as it is in all typical UIs, since it's legal to mouseDown and drag without ever mousing up to
complete the click. Hence the SelectEvent properly precedes ClickEvent.

However it is an interesting question whether row removal should move the selection, we'll think about that.

[jzaruba]

Well, I'm glad now I haven't filled the bug report. :)

But then, shouldn't selection be made/altered by Click, instead of MouseDown? (Genuine question! :)
B/c, if my understanding is right, when you MouseDown on one of selected records, to drag'n'drop them elsewhere, your selection is gone.

As for "removal is not selection"... It looks kinda weird when you click the remove-field, and before the removal is processed the actions hooked to SelectionEvent are performed.. Which quite often means that some panel with details gets displayed & populated with data, only to get dismissed again instantly.