Bug 67140

Summary: Icons placing is a nightmare
Product: [Unmaintained] kdesktop Reporter: palantir
Component: iconsAssignee: David Faure <faure>
Status: CLOSED FIXED    
Severity: normal CC: axelotto, finex, ico, selecter, wackysalut, yuzyk
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: first patch, might break something.
Second patch, less invasive

Description palantir 2003-11-03 21:39:11 UTC
Version:           v1.9.8 (using KDE 3.1.93 (CVS >= 20031028), compiled sources)
Compiler:          gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
OS:          Linux (i686) release 2.4.21-1.ll.acpi

This is somehow a duplicate of Bug 35203 but I think that things have gone ways worse!! Try to drag and drom an icon for a short distance and it will go back to its place. You need to move it at least the same amount of pixel as the icons itself is. Moreover (and this is worse) when the icon is dragged, the mouse cursor changes to the icon's shape. But when you release the mouse button, the icon is _not_ placed in the place the shape was before but it goes a few pixels away... alignin icons becomes a real nightmare!
Comment 1 David Faure 2003-11-03 22:03:50 UTC
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.

Comment 2 palantir 2003-11-07 15:44:50 UTC
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...
Comment 3 Henry Miller 2004-03-02 02:26:04 UTC
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.
Comment 4 Henry Miller 2004-03-02 02:54:52 UTC
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.
Comment 5 David Faure 2004-03-18 18:24:28 UTC
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 ?

Comment 6 John Firebaugh 2004-03-19 21:41:36 UTC
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

Comment 7 David Faure 2004-03-20 00:09:15 UTC
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.

Comment 8 John Firebaugh 2004-03-31 04:32:51 UTC
[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

Comment 9 Benoit Walter 2004-04-12 20:42:38 UTC
*** Bug 75478 has been marked as a duplicate of this bug. ***
Comment 10 Benoit Walter 2004-04-15 22:21:23 UTC
*** Bug 74335 has been marked as a duplicate of this bug. ***
Comment 11 Benoit Walter 2004-05-30 21:43:57 UTC
*** Bug 82212 has been marked as a duplicate of this bug. ***
Comment 12 Olov B 2004-08-13 11:20:28 UTC
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
Comment 13 Martin Koller 2005-01-02 01:56:01 UTC
*** Bug 80099 has been marked as a duplicate of this bug. ***
Comment 14 Martin Koller 2005-01-02 20:45:36 UTC
*** Bug 88914 has been marked as a duplicate of this bug. ***
Comment 15 Martin Koller 2005-01-07 21:03:16 UTC
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;


Comment 16 2005-01-19 23:16:09 UTC
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.
Comment 17 2005-01-20 07:23:55 UTC
Forgot to say that this only happens in View detailed in list and Info 
Comment 18 FiNeX 2009-01-02 20:25:40 UTC
Bug closed. Kdesktop is no more mantained.