Subject: Re:  New: Icons placing is a nightmare

> Try to drag and drom an icon for a short distance and it will go back to its place

A qt-copy patches fixes this:
cvs co qt-copy/0021-qiconview-dragalittle.patch

Index: src/iconview/qiconview.cpp
===================================================================
RCS file: /home/kde/qt-copy/src/iconview/qiconview.cpp,v
retrieving revision 1.49
diff -u -p -r1.49 qiconview.cpp
--- src/iconview/qiconview.cpp  1 Jul 2003 23:06:42 -0000       1.49
+++ src/iconview/qiconview.cpp  23 Jul 2003 05:19:28 -0000
@@ -4770,7 +4770,7 @@ void QIconView::contentsDropEvent( QDrop

     QIconViewItem *i = findItem( e->pos() );

-    if ( !i && e->source() == viewport() && d->currentItem && !d->cleared ) {
+    if ( (!i || i == d->currentItem) && e->source() == viewport() && d->currentItem && !d->cleared ) {
        if ( !d->rearrangeEnabled )
            return;
        QRect r = d->currentItem->rect();

Not applied to Qt yet though, it seems.

The patch in fact solves the problem of the short distance dragging (and this is already a great thing!!).
However the shape which you drag has still problems, i.e. when dropping, the icon is not placed on the same position the shape was...

Created attachment 4969 [details]
first patch, might break something.

Warning, There must be a reason for this code, otherwise why did someone write
it.  I don't understand what it is, so I'm not sure if it is valid thinking or
not.  If this is the direction we want to go, the code should be cleaned up.

Created attachment 4971 [details]
Second patch, less invasive

This patch is mutually exclusive of the first patch.   Overall I prefer doing
the earlier one, but this one shouldn't break anything else so it might be
preferred.

Note that these patches only address the part where the icon is placed in a
position offset from where it is dropped.  The other problem (small drags) is
better handled by the earlier bug.

On Monday 08 March 2004 19:37, Henry W. Miller wrote:
> Note that this is two completely seperate patches, and not a single two
> part patch.  Apply only one or the other.  Applying both will result in
> the same problem, but in reverse.

The first patch (turning offset into 0,0) looks good to me (after testing).
(I didn't test the other solution though).

> konq_iconviewwidget.patch fixes the root cause, but I can't imangine
> someone writing the code that I basicly backed out for no reason so I
> don't recomend it, I'm sure IT WILL BREAK SOMETHING, but I don't know
> what.

Well it won't break much. Here's the reason why it was done:

$cvs ann konq_iconviewwidget.cc | grep '\-10'
1.248        (firebaug 02-Aug-03):     QPoint offset(-10,-10);

$cvs log -r1.248 konq_iconviewwidget.cc
revision 1.248
date: 2003/08/02 04:17:39;  author: firebaugh;  state: Exp;  lines: +6 -8
Don't obscure the drag target
===

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?

John, do you see a problem with this offset being turned into 0,0 ?

On Mar 18, 2004, at 9:24 AM, David Faure wrote:
>
> Well it won't break much. Here's the reason why it was done:
>
> $cvs ann konq_iconviewwidget.cc | grep '\-10'
> 1.248        (firebaug 02-Aug-03):     QPoint offset(-10,-10);
>
> $cvs log -r1.248 konq_iconviewwidget.cc
> revision 1.248
> date: 2003/08/02 04:17:39;  author: firebaugh;  state: Exp;  lines: +6 
> -8
> Don't obscure the drag target
> ===
>
> 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.

-John

On Friday 19 March 2004 21:41, John Firebaugh wrote:
> 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.

I start to see the issue. But I don't see how (-10,-10) does anything real
about this. If I click in the middle of an icon, which is 32x32, the icon moves
(10,10) to the bottom right, the mouse cursor is still completely over the icon,
and obscures any drop target just the same.

> > 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 see your reasoning. But pushing this to the extreme, it would mean that
when dragging an icon, the icon should be moved far away from the mouse
cursor so that the cursor isn't above the dragged icon, but above the
drop target. This would look VERY weird, of course...

> 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.
Now that's a good idea. Hmm, not that I'd know how to do that ;)

> 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.
?!?!?!?!? It doesn't reposition. With 0,0 it remains at the same offset
as where the mouse was when you clicked. This allows precise
positioning. Please try it, I fear that you misunderstand the effect of
setting the offset to 0,0.

> 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.
I am rather against a difference between konqueror and kdesktop, for
consistency reasons, although I agree with you that the common use
case is different. But I'm confident there's a good solution that fits
both konq and kdesktop :)

My current proposal is to go for (0,0) offset and ask on kde-core-devel
how we could make a transparent dragged icon.

[Pascal: beginning of discussion is at bug #67140]

On Friday 19 March 2004 3:09 pm, David Faure wrote:
> On Friday 19 March 2004 21:41, John Firebaugh wrote:
> > 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.
>
> I start to see the issue. But I don't see how (-10,-10) does anything real
> about this. If I click in the middle of an icon, which is 32x32, the icon
> moves (10,10) to the bottom right, the mouse cursor is still completely
> over the icon, and obscures any drop target just the same.

Ah, I see. It used to work how I described it, but was broken in revision 
1.261 by Pascal Létourneau (commit message: Fix dragging of multiple items in 
KonqIconView CCMAIL:64706-close@bugs.kde.org).

> ?!?!?!?!? It doesn't reposition. With 0,0 it remains at the same offset
> as where the mouse was when you clicked. This allows precise
> positioning. Please try it, I fear that you misunderstand the effect of
> setting the offset to 0,0.

Yes, I misunderstood what 0,0 did. That's the third best solution, then, in my 
opinion (after transparent and the behavior I described).

> > 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.
>
> I am rather against a difference between konqueror and kdesktop, for
> consistency reasons, although I agree with you that the common use
> case is different. But I'm confident there's a good solution that fits
> both konq and kdesktop :)
>
> My current proposal is to go for (0,0) offset and ask on kde-core-devel
> how we could make a transparent dragged icon.

That's a great solution, if it is technically possible.

-John

*** Bug 75478 has been marked as a duplicate of this bug. ***

*** Bug 74335 has been marked as a duplicate of this bug. ***

*** Bug 82212 has been marked as a duplicate of this bug. ***

I was just about to file a bug report on this myself. The fact that the icon gets placed to the left and above the expected position(*) is _utterly_ annoying, and leaves the user with the feeling he is not in control. 

The 10,10 offset stuff should not stay on the desktop _or_ in the file manager. Please resolve this issue! (And since it just seems to be about removing two digits from the code it's very easy).

Thanks in advance.

---

(*) Expected position based on the position of the shape that follows the mouse pointer during the movement

*** Bug 80099 has been marked as a duplicate of this bug. ***

*** Bug 88914 has been marked as a duplicate of this bug. ***

CVS commit by mkoller: 

BUG: 67140
removed the -10,-10 offset when dragging an icon (ok from jf)


  M +3 -7      konq_iconviewwidget.cc   1.313


--- kdebase/libkonq/konq_iconviewwidget.cc  #1.312:1.313
@@ -940,5 +940,4 @@ KonqIconDrag * KonqIconViewWidget::konqD
     //kdDebug(1203) << "KonqIconViewWidget::konqDragObject" << endl;
 
-    QPoint offset(-10,-10);
     KonqIconDrag * drag = new KonqIconDrag( dragSource );
     QIconViewItem *primaryItem = currentItem();
@@ -954,7 +953,7 @@ KonqIconDrag * KonqIconViewWidget::konqD
           id.setData( QCString(itemURL.latin1()) );
           drag->append( id,
-                        QRect( it->pixmapRect(false).topLeft() - m_mousePos - offset,
+                        QRect( it->pixmapRect(false).topLeft() - m_mousePos,
                                it->pixmapRect().size() ),
-                        QRect( it->textRect(false).topLeft() - m_mousePos - offset,
+                        QRect( it->textRect(false).topLeft() - m_mousePos,
                                it->textRect().size() ),
                         itemURL );
@@ -963,8 +962,5 @@ KonqIconDrag * KonqIconViewWidget::konqD
 
     if (primaryItem)
-    {
-       // Set pixmap, with the correct offset
-       drag->setPixmap( *primaryItem->pixmap(), m_mousePos - primaryItem->pixmapRect(false).topLeft() + offset );
-    }
+       drag->setPixmap( *primaryItem->pixmap(), m_mousePos - primaryItem->pixmapRect(false).topLeft() );
 
     return drag;

This seems to be the good way, but after applying this patch and one file is selected and u right-click in an empty space, the file continues selected, but when i say empty space please pay attention, because is not the empty space in front of files, because there the file stays deselcted, so what i mean with empty space is in bottom.

Of course this is only possible when the folder haves a few files and there empty space in the bottom, cause when for example in dir /usr/bin you dont have emptry space in bottom, only in front of files.

My english isnt good, but i hope u can understand what i mean.

Forgot to say that this only happens in View detailed in list and Info 

Bug closed. Kdesktop is no more mantained.