If target view of a drag and drop is a CPTableView, set inset bounds based on the row height of the table #1372

Open
wants to merge 1 commit into
from

5 participants

@kjamieson

My application utilizes a CPTableView with relatively large (height-wise) rows (holding image thumbnails), and dragging and dropping rows within a CPScrollView is quite painfully slow.

This change adjusts the inset bounds for the scroll area from a hard-coded value of 30 pixels to be dependent on the row height of the CPTableView, if the target of the drag-and-drop is a CPTableView.

This works quite well for my application and seems relatively close to the Cocoa behaviour (subjectively, as I haven't been able to track down any documentation describing how this is actually implemented in Cocoa), but I'm open to alternative suggestions if this doesn't seem like the right approach.

There was an earlier discussion on this some months back (see https://groups.google.com/group/objectivej/browse_thread/thread/ec4adf67a5fdadb3) that resulted in an increase of the inset bounds from 10 to 30 pixels, but I find that insufficient for my application's needs.

Kevin Jamieson If target view of a drag is a CPTableView, set inset bounds based on …
…the row height of the table
b349f0a
@Me1000

The once concern I have here is in the case of variable row height. How exactly does Cocoa handle this situation?

@kjamieson

I'm not sure what the Cocoa behaviour is in the case of variable row height. Perhaps a Cocoa developer can chime in.

This patch does not modify the existing behaviour for variable row height tables, which will continue to use the current default inset bounds.

@Me1000

I don't believe that's true... for variable row height it will still be whatever MAX(30, rowHeight) is. Granted, it's not likely to be that big of a deal, but it's a case that could easily be forgotten and cause some awkward behavior. I'm perfectly willing to accept this the way it is, but I'd like to have this auto scroll behavior documented in the tableview when it's merged.

@cappbot

Label: #new. What's next? A reviewer should examine this issue.

@schipmolder

#needs-confirmation
+AppKit
+feature

@cappbot

Labels: #needs-confirmation, #new, AppKit, feature. What's next? This issue needs a volunteer to independently reproduce the issue.

@ahankinson

-#new
milestone=Someday

@cappbot

Milestone: Someday. Labels: #needs-confirmation, AppKit, feature. What's next? This issue needs a volunteer to independently reproduce the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment