CPTableView / CPClipView does not scroll when dragging

[dtsitses]

If method [CPTableView tableView: validateDrop: proposedRow: proposedDropOperation:] sets the drop row to be a few rows > or < than the current visible rows, then dragging the row towards the visible bounds of the table does not auto-scroll to the next available drop position.

Result: it is not possible to drop the row to a valid index

How to replicate:

• Create a table with 20 rows, and adjust its height so that only half of the rows are visible.
• Configure scrolling to allow drops on every row, by setting [aTableView setDropRow:row dropOperation:CPTableViewDropAbove];
• Notice that when dragging beyond the table's visible bounds, the table scrolls correctly
• Now, set the table to allow drops every 3 rows, like so: [aTableView setDropRow:row+3 dropOperation:CPTableViewDropAbove];
• Scroll to the middle of the table, so that there are 5 invisible rows above, and 5 below
• Pick a row and start dragging towards the bounds of the table.
• Notice that the table no longer scrolls to the next valid index, in either direction

Tested on *master with code pulled on 2010-04-12

[cacaodev]

I don't see the bug when dragging down, only up. But in both cases, in the code, we should definitely scroll by ±= _rowHeight instead of scrolling to the next targeted row.

[boucher]

Duplicate of http://github.com/280north/cappuccino/issues#issue/296 but I'm closing that one since this is more descriptive.

[dtsitses]

I did some further investigation on this, it appears that on a simple table that just allows items to be dropped every 3 rows, i.e. when (row % 3 == 0), the problem does not appear (unless the table's height is about 100px, with cells 45px tall - in that case, autoscroll while dragging upwards doesn't work).

The table which I originally observed the problem on uses variable view types per row, which views also implement [drawRect:]. There are also some other complexities on that table. When testing on that table, autoscroll when dragging only works if the allowed drop position is a cell away into the clipped area. However when the allowed drop position is further away, i.e. when (row % 3 == 0), then the drag won't autoscroll. Dropping the item in the desired position is impossible.

I'll investigate further when I get the chance, and will try to isolate the configuration that's causing the problem to surface. I'll update the issue again and include a test table demonstrating the problem.

[Me1000]

Is this still a problem?

[dtsitses]

just tested after a fresh pull, problem persists

[boucher]

since there seems to be a lot of ambiguity here, can you please just provide some sample code for testing purposes?

[dtsitses]

I managed to isolate the problem - apparently it is very simple to replicate and does not require any of the steps described above, the fact that it was occurring on a table of the described structure and functionality was a coincidence.

To replicate, just create a table with a bunch of rows and set [scrollView setHasVerticalScroller:NO]; Now dragging an item below or above the visible rows does not cause auto-scroll.

Now this obviously sounds kinda dumb… why would I expect a table with no scroller to auto-scroll?? Well, up to now I hadn't even realized that there was no scroller: the thing scrolls with my mouse wheel and with touch gestures, so when I drag an item I also expect it to scroll. I suppose the question is, what does setHasVerticalScroller:NO mean? Does it mean that there is no vertical scroll functionality, or just that the scroller is not visible. Current user experience feels like that latter I think.

Have a .zip sample app demonstrating the issue, will find a place to upload it if required

[cappbot]

Milestone: 1.0. Labels: #needs-confirmation, #needs-patch, AppKit, bug. What's next?

• This issue needs a volunteer to write and submit code to address it.
• This issue needs a volunteer to independently reproduce the issue.

[daboe01]

a scroll view without a scroller should indeed not autoscroll.
so this is not an issue, isn't it?
+#wont-fix

[cappbot]

Milestone: 1.0. Labels: #wont-fix, AppKit, bug. What's next? A reviewer or core team member has decided against acting upon this issue.

[cappbot]

Milestone: 1.0. Labels: #wont-fix, AppKit, bug. What's next? A reviewer or core team member has decided against acting upon this issue.