From kfm-devel Sat Mar 20 14:55:29 2004 From: Henry Miller Date: Sat, 20 Mar 2004 14:55:29 +0000 To: kfm-devel Subject: Re: [Bug 67140] Icons placing is a nightmare (fwd) Message-Id: <200403200855.30820.hank () black-hole ! com> X-MARC-Message: https://marc.info/?l=kfm-devel&m=107979454412280 On Friday 19 March 2004 14:30, John Firebaugh wrote: > On Mar 18, 2004, at 9:24 AM, David Faure wrote: > > > > I can't see the reason for it though, I mean whichever offset is > > chosen there's always a > > chance the dragged icon will obscure the drop target, isn't there? > > Not true. The drop target is determined by the cursor hotspot. > Therefore (until we get workable transparency), the space around the > cursor hotspot must not be covered up by the drag icon -- offset down > and to the right is much better than 0,0. > > > John, do you see a problem with this offset being turned into 0,0 ? > > Yeah: it's really annoying to not be able to see what folder you are > about to drop a file into because the icon is sitting beneath the > cursor hotspot, obscuring the target. > > I agree that this poses a problem for icon positioning. The best > solution would be to make the drag icon ~80% transparent and > non-offset. 0,0 is the worst of both worlds -- if you click and drag > from the center of the icon, it shouldn't reposition itself to (0,0), > it should either get out of the way entirely, or remain at the same > offset as when you pressed down the mouse button. > > I could accept making the desktop a special case, i.e. using the offset > at mouse down time, because I more often want to reposition icons than > move them into folders, but please don't do it in general. My other patch would make the desktop move icons by the offset when dropped, basically undoing the offset at drop time. Not quite the same desktop special case, but does the same. Either way though, when we get true transparency we need to remember to undo all these places. Note that this problem also happens in Konqueror, but it is obscured because snap to grid is typically on so you don't realize it is happening. I don't think we should worry about it there though. However anything (is there anything else?) inheriting from konq_iconviewwidget needs to check if this is an issue and do something about it if so. -- Henry Miller hank@black-hole.com