Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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
base: narwhal
Choose a base branch
from

Conversation

kjamieson
Copy link

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.

@Me1000
Copy link

Me1000 commented Nov 8, 2011

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

@kjamieson
Copy link
Author

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
Copy link

Me1000 commented Nov 15, 2011

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
Copy link

cappbot commented May 9, 2012

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

@ghost
Copy link

ghost commented May 21, 2012

#needs-confirmation
+AppKit
+feature

@cappbot
Copy link

cappbot commented May 21, 2012

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

@ahankinson
Copy link
Contributor

-#new
milestone=Someday

@cappbot
Copy link

cappbot commented Feb 15, 2013

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

@enquora
Copy link
Contributor

enquora commented Dec 22, 2023

This needs review in light of Aristo3 work.

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

Successfully merging this pull request may close these issues.

None yet

5 participants