ok, here is a more precise and correct description of this bug. 
 
See this directory structure (which represents the directory tree on the left side in konq): 
 
Home Directory 
| 
+-Documents 
| 
+-Images 
| 
+-more dirs... 
 
In the folder "Images" you have created an image gallery using the (great!) konqueror plugin. 
The "drag and drop is triggered-bug" actually only happens when you stop watching an image 
gallery by clicking on another directory in the left tree. 
 
Step by step: 
 
1. Click on "Images" 
2. being in "Images", click on the "images.html" file (which has been generated by the image 
   gallery-plugin) 
3. The image gallery isd being shown. 
4. Click on the "Documents" directory, but keep the mouse over the "Documents"-icon. 
   this "closes" the image gallery and konqueror now shows the directory listing. 
5. Now move the mouse slowly away from the "Documents" folder, and you will see that you 
    actually drag it, 
   and this is the bug! 

ok, more info: 
 
it does not only happen when konqueror display an image gallery, but also when it displays 
a html page. 
I think it happens for everything except a directory listing. 

I can confirm this bug as well. 
System: KDE 3.1.2, Debian unstable. 

using CVS HEAD and trying very, very hard to reproduce this bug on a PII400 (so not 
exactly a speed demon; i'm even compiling kdelibs at the moment) i can not reproduce 
this. i've followed the instructions to the letter and everything works as it should. 

I can't reproduce this on cvs-head... what widget style are you using? Styles can 
override the distance it takes for a drag event to occur.  

I use Keramik. Once at home, I'll try with another style and tell the results.

You should try the following to reproduce the behavior:

- Start Konqueror
- Open some folders in the navigation tree
- Preview a file (i prefer some Text-, Java- or XML-File) in embedded editor
- While previewing the file click on a folder in the navigation tree
- Now it should be in drag-mode.


I use SuSE 8.2 (KDE 3.1.1) on an AMD Athlon 600 box.
I tried Keramik, KDE-Standard-Style
I tried Double Click/Single Click mode for the mouse in YaST-Control-Center
None of this configurations helped me solving the problem.


Greetings
Manfred

I can confirm that the selected style does not influence this behaviour. I tried
"Keramik", "Highcolour Default" and "Light 3rd revision".

regards,
Yves

OK, I had this bug also a few times and I think that I have the reason why itś
here. 

I've found out that this bug appears when installing the QT libraries after the
KDE libraries.

The reason I found this was because the bug reappeared after I've updated my Qt
from 3.1.2-something to 3.1.2-something-else. Yesterday I did a stupid job to do
rm -r * command in my /opt dir (I running SuSE 8.2). So I had to reinstall
KDELIBS  3.1.2 and after I found out that my KDE was working liek before, I've
found that also the drag-drop-bug in Konq was gone. So KDE is working even
better now.

The bottomline is: If you have the bug, try a reinstall of kdelibs (I did all
the rpm's). If you don't have the bug, but you want the bug (to test), reinstall QT.

Can someone confirm this/

I updated from SuSE 8.2's original kdelibs version to kdelibs3-3.1.1-52. I did
not change anything on QT. Bug is still there.

I'm avoiding an update to KDE 3.1.2 and a newer QT, because i read about a new
anoying bugs in QT 3.1.2 (multi select files and copy/move via drag'ndrop ->
only one file is copied).

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

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

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

Well updating the libraries can't also always be done.
Why not? 
Well I am using the Knoppix CD and in that case it's 'ro'.
Did an install to hd but I am dependend on Debian while the 
KnoppixCD is build on it.
But updating with it can/will break the installation as Knoppix
has done.
So if I want to update/reinstall I have no idea from who to get it.
Knoppix, Debian or KDE and to find the right version.

I am recompiling kdelibs once a week, bug hasn't gone away. 
QT3.1.2 KDE3.1.3CVS 
 

I have this bug, and it goes away if I delete my .kde and start over!  I don't 
know which dotfile is doing it tho.... 

Ok, I found that if I delete .kde/share/config/klipperrc the problem goes 
away. 
 
Contents with problem: 
 
[General] 
ClipboardData=.kde/share/config/klipperrc,Total votes: 6, ,: 61,Who\nNumber of 
votes\n\n\ndatschge@gmx.de \n1 \n\n\nyg@mind.lu \n20 \n\n\nmanfredhardt@gmx.de 
 \n20 \n\n\nleif@dkstat.com \n20 \n\n\nTotal votes: ,Total votes: 
61,http://www.google.com/,0,konqueror,kana 'KI' then small 'E') seems a 
strange thing to in 
clude - can anyone give an example of a word it's used in? (There may be a 
really obvious one but I can't t, Also\\, 'kye' (katakana 'KI' then small 'E') 
see 
ms a strange thing to include - can anyone give an example of a word it's used 
in? (There may be a really obvious one but I can't think of any off the top of 
 my head)\n\n\n\nBack to top\n\n \n\n\n\n\n\n\nDisplay posts from previous:   
\n\n\n\n   \n   lrnj.com Forum Index -> Game Features\nAll times are GMT\n 
\n\n 
\nPage 1 of 1\n\n\n\n  \n \n\nJump to:  \n\nYou can post new topics in this 
forum\nYou can reply to topics in this forum\nYou cannot edit your posts in 
this 
forum\nYou cannot delete your posts in this forum\nYou cannot vote in polls in 
this forum\n\n\n\n Powered by phpBB 2.0.5 © 2001\\, 2002 phpBB Group\n \n,Doe 
s anyone use 'wi' or 'we' for anything these days? Or are they just included 
in the game for completeness? \n \n Also\\, 'kye' (katakana 'KI' then small 
'E') 
 seems a strange thing to include - can anyone give an example of a word it's 
used in? (There may be a really obvious one but I can't think of any off the 
to 
p of my head),can, are very simple\\, but the gameplay is very deep\\, and it 
has a good handicapping system so people at different skill levels can still 
pl 
ay interesting games and both will have a chance to win. \n \n,Go has 
absolutely nothing to do with Project LRNJ. I just like playing. \n \n Its 
rules are ve 
ry simple\\, but the gameplay is very deep\\, and it has a good handicapping 
system so people at different skill levels can still play interesting games 
and 
both will have a chance to win. \n \n Learn the rules: 
http://playgo.to/interactive/index.html \n Most basic tactics: 
http://senseis.xmp.net/?BasicInstinct \ 
n Where to play: http://igs.joyjoy.net/ \n Game samples and strategy 
instruction: http://gobase.org/,rules,-3D graphics: I intend to keep the 
system requirem 
ents to a minimum \n \n,nsidering: \n -voice samples \n -stroke-counting and 
radicals \n -online gameplay elements \n -parts of the game with dialog 
entirely 
 in Japanese \n -more talking bugs \n \n, Definite Features: \n -coverage of 
all common-use kanji \n -Japanese words (implemented as the magic system) \n 
-gr 
ammar essentials (probably enhanced in the registered version as minigames) \n 
-music and sound effects (registered version only) \n -a higher story to mater 
ial-covered ratio (it won't always revolve around level grinding) \n 
-instructions on how to use a native-language Japanese dictionary \n 
-non-slime enemies 
\n \n,I agree\\, there isn't much point in not including the pronunciation of 
words when you'll be writing a half-paragraph on each kanji anyway.,there, 
ther 
e,Would,that,I am not that far into the game but for me so far its: \n \n Blue 
slime: Katakana \n Red Slime: Hiragana \n Green Slime: Kanji \n Magic Slime (g 
reen ones wearing a rather fetching point hat and carrying a rather camp 
looking wand): Any - Can be Katakana\\, Hiragana or Kanji (not sure about the 
last o 
ne havent got that far). \n \n It sounds to me like the green slimes you are 
describing are Magic slimes. \n \n I may\\, however\\, be completely 
wrong....pr 
obably Nindalf should clear this one up. 
 
 
I also want to note that this bug is hard to reproduce.  I have to click on 
the treeview and VERY QUICKLY move the mouse.  It's sort of like the drag code 
doesn't notice I depressed the mouse.  Maybe the ordering of events or 
something causes the bug. 
 

I have the error even with a clean .kde .  
 
Reproducable here with: 
Open Konqueror in filemanagement mode, sidebar enabled, open a html-document, 
then click on a folder in the sidebar, dnd triggered. 
 
I have gcc2.95.3 glibc2.2.5 KDE_3_1_BRANCH QT312. 
 

Ok, I found that if I delete .kde/share/config/klipperrc the problem goes 
away. 

Does not apply to me.
I had the problem first with the Knoppix CD (no klipperrc available)
Now I have SuSE 8.2 and still the same.

This was the way I found it anyway.
A way to produce this effect can be as follows
In the Konqueror make shure you have the root tree on the left with all the
directories in it.
Click on i.e. /dev to open it and click on a device that will give a error.
Anything else in the tree is also o.k. it must just give a error.

It is just that you need to get a error popup.
In this case there can be no problem with timing as mentioned earlyer.

If the error dialog pops up then the focus was comming from the tree and is on 
the error dialog. 
For the programer: 
treeview_nodeclick(node) {
  ok=eval(node.path) // what can be done with it?
  // to keep it simple, show the content in the listview
  // is it a directory?
  // oeps this directoy can't be shown for some reason
  // i.e. empty floppy drive but mounted anyway
  if (!ok) { 
    // some error has occured
    drag_operations=must_stop
  } else {
    drag_operations=may_start // I say MAY but nost MUST!
  }
}
treeview_lostfocus(){
  if (mousebutton=up) { // in this case there can't be a drag/drop any more!
    drag_operations=must_stop
  }
}

When the mouse comes over the tree the little attached icon will apear.
If you click on a different folder/directory then you get the message about 
move or copy also.

Just found this behaviour in a reproducable way

In Konqueror goto:
ftp://ftp.kde.org/pub/kde/stable/server/kolab- 1.0/www.erlangen.de
click on the index.html file
Now you get a nice web page of course.
Wait till page is ready.
Now you can click on the 'bilder' directory.
Move your mouse and you see the icon attached to it.
Please goto the right side list and click there. 
If you click you will get the copy/move/link and cancel menu, choose the cancel.
My KDE version=3.1.1 from the SuSE 8.2 distro.

ron

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

Wel now it is gone.
What is gone?
KDE (QT), SuSE8.2 and Linux.
This fucking error just damaged my installed system with this behaviour.

May be I come back when KDE 3.99 is there with almost all the bugs are fixed.
Than I do only have to look for a distro that does not fu.... ..p KDE as SuSE 
8.2 is doing with there im(de)provements.

BTW 
The version on SuSE 8.2 for KDE is 3.1.1 (21 jul 2003) so it could be fixed in 
3.1.2 what is not true, the Knoppix CD has 3.1.2 and the problem was there to.

Happy my old win98se still working but I come back. No XP in my house! 
As told by M$ you need XP or better. So I go to Linux,KDE and ??? distro.



 

 

$ kde-config --version 
Qt: 3.2.1 
KDE: 3.1.3 
 
Removing .kde/share/config/klipperrc fixed this 

here not... on debian unstable 
 
yves@Valhalla:~# kde-config --version 
Qt: 3.2.1 
KDE: 3.1.3 
kde-config: 1.0 

Subject: Re:  drag and drop triggered in konqueror when clicking on tree

On Thursday 18 September 2003 22:06, you wrote:
> > ------- Additional Comments From yg@mind.lu  2003-09-18 20:57
> > ------- here not... on debian unstable
> >
> > yves@Valhalla:~# kde-config --version
> > Qt: 3.2.1
> > KDE: 3.1.3
> > kde-config: 1.0
>
> That's strange I'm running debian unstable too and all I did was quit
> klipper, delete ~/.kde/share/config/klipperrc and then restart
> klipper and konqueror and the problem had disappeared.

mmm... I never had klipper running. I tried however to delete it's 
configfile, but after that I can still reproduce the bug, with klipper 
running or not.

But there is a relation between klipper and this bug, because with 
klipper running I can more easily reproduce the bug by only changing 
directories by clickin on the tree, _without_ moving the mouse to the 
mainframe....
Strangely it only happens with some directories, but not all...

This bug is ugly... Could it not be found by looking at all the signals 
emitted while reproducing the bug?


> Nick

Shutting down Klipper got rid of it for me - using debian unstable, kde 3.1.3.
Fortunately I never used Klipper to begin with, it was just on by default, so
now I have disabled it and all is well. Bastard of a bug though.

As of KDE 3.1.4 on FreeBSD this bug is still quite alive, and perhaps even more 
annoying than 3.1.3.  Click on any directory in the tree and if you do not wait 
a full second before moving your mouse it kicks into drag and drop.  As others 
have stated, shutting down Klipper appears to correct the problem. 
 
I should also note that this is a reasonably fresh .kde directory in use.  I 
had some migration issues from 3.1.3 that forced me to create a new one here. 

Same problem with Slackware 9.1, Qt 3.2 and kde 3.1.4

Close down klipper and it all goes away !

I still have this bug in SUSE 3.1.4 packages even with klipper off.
Heres how I can reproduce error:
Click on services tab and then click on audio CD Browser with no CD in so it says:
An error occured while loading audiocd:/:
Could not read /

Then click on devices or printers or any other tree in sidebar and you get drag n drop.

It seems to happen when it first has a page it can not display then clicking another tree icon, I can reproduce this also when i first click on lan browser instead of audiocd since I dont have lisa running and it cant display lan.

Cant reproduce this in suse 3.2 beta 1 rpm's. Seems fixed for me at least compared to 3.1.4.

I also cannot reproduce the bug with 3.2beta1 built with konstruct on debian testing.
Even importing my old .kde and using klipper cannot reproduce it. 
What about a backport to 3_1_BRANCH?

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

So at least three people do NOT see this bug anymore with KDE 3.2 Beta 1 anymore. Is there anyone who DOES see it with KDE 3.2 Beta 1 (or newer)?

void KonqSidebarTree::contentsMouseMoveEvent( QMouseEvent *e )
{
    KListView::contentsMouseMoveEvent( e );
    if ( !m_bDrag || ( e->pos() - m_dragPos ).manhattanLength() <= KGlobalSettings::dndEventDelay() )
        return;

    m_bDrag = false;

    QListViewItem *item = itemAt( contentsToViewport( m_dragPos ) );

    if ( !item || !item->isSelectable() )
        return;

    // Start a drag
    QDragObject * drag = static_cast<KonqSidebarTreeItem *>( item )->dragObject( viewport(), false );
    if ( !drag )
	return;

    const QPixmap *pix = item->pixmap(0);
    if ( pix && drag->pixmap().isNull() ) {
        QPoint hotspot( pix->width() / 2, pix->height() / 2 );
        drag->setPixmap( *pix, hotspot );
    }

    drag->drag();
}

void KonqSidebarTree::contentsMouseReleaseEvent( QMouseEvent *e )
{
    KListView::contentsMouseReleaseEvent( e );
    m_bDrag = false;
}

***************************
Maybe i am not right but in the last function m_bDrag is set to false to prevent the dnd operation.
In the above it is also done but I beleave it should not do the '//Start a drag' anymore.
Just as the following
 if ( !item || !item->isSelectable() )
        return;
This does also not alow the dnd if there is no item.
In short I try to explain how I see it should work.

This is the current behaviour in 3.1.4
void KonqSidebarTree::contentsMousePressEvent( QMouseEvent *e )
Here is the m_bDrag set to true

void KonqSidebarTree::contentsMouseMoveEvent( QMouseEvent *e )
Here is tested if is selectable and if it can then the drag is started
 
void KonqSidebarTree::contentsMouseReleaseEvent( QMouseEvent *e )
Here the m_bDrag is reset

My view,
In the first event the m_bDrag may not be set because it depends on a offset of the press position, here must only the x and y position saved for the move event in the future
Also the list view is updated and if the AudioCD or floppy or the object for mouse down create an error messagebox the mouse moves and goes up .This will start the drag in the move event first and the release does not apply here to cancel the drag. The mouse is down and up on the message box so the release event is done in the treeview to cancel.

In the move event the m_bDrag can be set if the left mouse button is still pressed and
the move of the mouse passed the x and y press position by a space of i.e 4 pixels (to protect mouse move durring the button down action).
If the test if it is selectable and can dragged the m_bDrag can be set.
The cursor/pointer can show visual there is a drag in process but the active drag is not done here. 

In the mouse release event the drag operation drag->drag() can be done if the m_bDrag is set and the receiving object accept it.


void KonqSidebarTree::slotMouseButtonPressed()
Here the m_bDrag should be set always to false.
This prevent the dnd popup message I now get when i click in the treeview after clicking the error messagebox away or after the listview is filled  with items for the down event in the treeview.

Code view from version 3.1.4 Konstruct download in 
/data4/usr/src/konstruct/kde/kdebase/work/kdebase-3.1.4/konqueror/sidebar/trees/konq_sidebartree.cpp

I hope this make sence.
Greetings Ron

There is really not much sense to analyze the 3.1.4 source code to say anything about it being fixed in HEAD/KDE 3.2 or not. HEAD doesn't use contentsMousePressEvent, contentsMouseMoveEvent and contentsMouseReleaseEvent at all.

I can not reproduce this either. Using CVS Head from 20031119.

Cheers JO

Thanks for reply.

I know there can be difference between 3.1.4 and upcomming 3.2 but 
not what excactly that is.
It was only a suggestion because I do have still this problem with 3.1.4.

Also I can not say I am a advanced user of C and KDE but means HEAD here?
It was analyzed to understand the effect why it happens in my 3.1.4 based 
on experience in assembly programming for dnd .
As is posibble gone in 3.2 I will see it as closed subject till I have 3.2.x.

I am unshure to try 3.2 beta now because with my install of 3.1.4 i lost in 
helpcenter a part of the KDE  help and for the general setup of my linux box
I depended on the SuSE way of doing untill I have more expirence. 
Distro is SuSE 8.2 and I am afraid they messed up the orginal layout of KDE.
They have the menu layout changed and some installs expect the KDE layout 
and then the applications are not in the menu as SuSE definied and I have to 
change to KDE layout but then the SuSE installs are not in the menu. 
Same with Helpcenter interception but I can't find a place for help on it.

Many greets/thanks Ron.

Hello,

had the same problem on my LFS-5.0 system.

I think the problem is the interaction between fam and Konqeror. After killing fam the problem went away.

Hope this helps.

Dieter

Argh,

should've tested this a bit more thoroughly. Sorry. Not fams fault. Error occured again.

Dieter

I'm also suffering (a lot) from this bug, as reported on http://bugs.kde.org/show_bug.cgi?id=56017 which was claimed to be resolved... NOT :(

using kde 3.1.4 and qt 3.2.3 on arch linux

Nobody sees this with KDE 3.2 Alpha 1 or newer (>=konq_sidebartree.cpp 1.35).

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

Still have in KDE 3.2_beta1

Had bug 59113 with Konqueror 3.1.4 (SuSE 9.0)
Suppressed Klipper+reboot and placed it back.
The bug dissappeard.

That bug's status was: RESOLVED ... but I had to do a
lot of reading to find a solution among those comments.
Is there a shorter way to find the solution for a
RESOLVED bug? 

Perry

Ooops, bug is back, will not go away anymore
Perry

I cannot reproduce it anymore. Tested with 3.2-rc1 in slackware with a fresh profile.

Have had this annoying problem since 3.1.3 on two machines, one a Powerbook running Gentoo (kde 3.1.5) and an Intel clone also Gentoo (kde 3.2 stable).  The problem is still there.  It definitely has something to do with klipper.  Turn klipper off, problem goes away and stays away.  Clear klipper history, problem goes away for a while, then comes back.  It is sporatic and does not seem to have any pattern (other than being related to klipper).  I've changed all my sensitivity settings, drag distance, drag time.  Nothing helps.

Help!!

I can also reproduce this. KDE 3.2, qt 3.3.0, SuSE 9.0.

Users report it is not fixed.

I am still having this bug under Debian/unstable, with 3.1.5-2 and xlibs 4.3.0-0pre1v5.  Someone with Debian said that the bug is not a Konqueror bug but an xlibs one (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214475 )  I have had this bug persist through many versions of Konqueror and xlibs.  Usually after an upgrade the problem will seem to go away for a short time, and then start occuring again.
While the problem occurs persistently, it is not easy to reproduce with an exact sequence of cursor movements and mouse clicks.
I did mention in one bug report that there might be some issue with respect to how IceWM handles window focus and raising issues (I use IceWM).  There are configurable options for IceWM such as ClickToFocus, FocusOnAppRaise, RaiseOnFocus, FocusOnClickClient, RaiseOnClickClient, etc.   Note that the automatic folder selection that occurs with Konqueror does not occur consistenly within Konqueror itself and has not occured at all with any other X applications that I have used.

Whatever the cause, this bug renders Konqueror difficult to work with consistently as I must keep one finger above the <Esc> key to immediate unselect folders that get selected for dragging automatically.  In fact, when I use other file managers like Nautilus and EndeavourII I now anticipate the folders to drag automatically.  It has conditioned me.

For me the bug went away in 3.2, and for most others as well, but the post above points at something important: IceWM

When I had the problem with 3.1 I was also using IceWM, but now I'm using the nice plastik theme so I'm no longer using IceWM and I expect a lot of others did this as well

I too was using IceWM and when I saw this I changed to Quartz to see if this would fix it. I'm still using 3.1.5 (Debian/unstable) and have also had this bug across several versions. This is the second day of using Quartz and the bug has reappeared. It appears to disappear with a reboot and then worsen as uptime increases (same behaviour as with IceWM). After about three days it will drag every file that is clicked on whereas at the moment it is just every now and again. Perhaps when 3.2 is released for Debian I will finally be rid of this... 

I add some interesting behaviour from klipper: I don't normally use it but after reading others' comments I started it up and immediately exited. This got rid of the bug, I could not reproduce it no matter how hard I tried. However it returns, again after a little while.

I can also reproduce this. KDE 3.2, qt 3.3.0, SuSE 9.0. 

What is IceWM?
I'm using KDE in his full glory.
When there is something outside Konqueror it can be klipper
however I do not use this thing and have the problem.
The main point to link to is the time needed after a click in the sidebar and a mouse
move after that and konqueror is analizing what to do in the right pane for the click in the sidebar.

It prepares the drag on mouse up instead of mouse down and cancel this if the mouse go up without mouse move, because konqueror found a error during this analizing and gives a mesage box, or filling it with a the file list.

This start for drag on mouse up starts now and because I move the mouse to click on the mesage box, it thinks it is a drag and drop operation.
After filling the list it is he first time the dnd is canceld.
Normal this is going fast enough not to do (it is triggered) a real dnd, but directories with many files or slow kpart actions by the analize delays this to much.

Klipper is also stealing time to handle his clipboard and so this can be importand to be involved with the problem but it is for shure not the reason of it.
Prove? Set the View for the right panel to text and it occurs less. No icons to get, almost only clean text to handle and much quicker a list of the files.

Nero

Well I think we can exclude klipper as well, since I never use this (unless it is running somewhere in the background) and I did have the bug...

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

Have this same exact problem in two systems - one a desktop P-3 500MHz and the other a laptop P-4M 2.2GHz - and using fully updated Fedora Core 1 operating systems.  The KDE version is 3.1.5...

Whatever the problem was, I've been using 3.2 for a week now and the bug is definitely gone! So there's the solution... (using Debian/unstable)

I can confirm that the bug is gone in 3.2

and thus I mark it as resolved

I have KDE 3.2.0-xx-SuSE but still have it.
I assume you mean 3.2.1 ?
Or maybe you can be specific witch version-build
SuSE at install time had i.e. kdelib3-3.2.0-8.rpm
then 2 weeks later kdelib3-3.2.0-32 and now kdelib3-3.2.1-xx

Upgrading is not the biggest problem but I had .avi to xine player 
and after each upgrade this is changed to noatun.
SuSE is everytime re-arranging the file associations to what 
they find the best one for the RMB and embedded viewer. 
That one plays also but it's also with .pdf files

This way it isn't an upgrade of the libraries but installing as 
if I have nothing of KDE. Or is there a way to do a save replace only.

Jacques: 
Version 3.2.0 or 3.2.1 as I beleave 1 week ago was already 
available for some distro's. Debian in your case SuSE mine.

'So there's the solution... (using Debian/unstable)' 
Do you mean i must use that one?
Mr X installs debian version x.x-1 nine days ago and you x.x-2 seven days ago.
Mr X have the problem, you don't. 
An exact version can be importand to say "So there's a solution".

The provider of the distro can sneaky add a fix.
Let be optimistic this is not the case but....

Yves:
May be 'resolved for 3.2.1-23 or later' is better.
SuSE has only 3.2.1-2 today in the regal, I have to wait till they 
pass the -23 version.

Last thing I miss.
When I want to report a bug I need to give some details, distro etc.
Why can't I see in the added reports witch they are using?
May be it is a fault of the compiler of the distribution 
and not in the KDE sources at all.

Ron

Yeah sorry about that, it is 3.2.1 (specifically version 4:3.2.1-1 in the debian packaging system) and no I didn't mean it to sound like I meant you have to use Debian/unstable, I was just adding that as some extra information at the end. I'm not a zealot yet;)

Smile :)

I'm feeling sorry for the guy's to find a so instable bug.
I wait now a few weeks before upgrade any furter till my 
distro is higher. 3.2.0 is now already a pleasure.

Thanks guys

Ron

I still have this bug, although now it happens only 5-10% of the time instead of 95-100% of the time. I have KDE 3.2.1, in debian/unstable (4:3.2.1-1).

Marcus, is it klipper related in your case?

In mine it *never* was, and disappeared when I first used 3.2 (version 3.2.1 in fact)
I never used 3.2.0 since it never was in "official" unstable.

One of the ways I could use to create this problem was selecting the floppy drive without floppy in it.
I get a error/warning popup end after click ok and returning the mouse in the left treeview the drag was started in most cases.

I'm using 3.2.0 (KDE 3.2 BRANCH >+20040204) SuSE and I get the error popup now 2 times (other bug?).

Started Klipper and go to a picture directory witch I used several time a day the past 2 weeks without the problem and it happens 1 time now. It contains about 10000 stamp pictures. The other directory has the same amount and type files.

This is the only link I have, the amount of files and type (image preview enabled,icon view instead of detail view) when the listview is build up. 
I think in background there is a file list build witch is used for this listview and used when you come again in this directory, the listview is then the second time quickly filled. 

When this list is outdated or the cache for it is full and used for another directory then on return on this directory it had the problem again.

It happens in my version 3.2 a very few times a day and is not so irritating as in 3.1.4 where it was almost every big directory i.e. switching between the two directories did it every time.

Solved? Almost 99%, I can't reproduce it so easy as in the past.
Now looking forward for 3.2.1

I'm using Debian unstable with the 3.2.1 KDE packages.

It took about three days of usage before I noticed this bug again.  It's certainly not happening at the rate it used to, but it is happening.  I've had it three times in the past couple of hours.  The machine's been on for two days, it's under extreme (near-100% load), and klipper is running.  In the past I've killed klipper and noticed very little change as far as the recurrence of this bug goes.

I'd suggest we bring this back out of resolved, particularly since no one seems to be able to point at a bit of the code yet that was identified as causing this (or rather, a bit that was changed that was thought to have fixed this).

Annoyingly enough you are right, the bug has not completely dissapeared. I had been using 3.2.1 for over a week now and hadn't noticed it but upon reading your message I clicked many times on the folder list until eventually it did happen. At least it is certainly at a tolerable level now, easily less than 5%.

If I run klipper I can reproduce it about 5% of the time, but when klipper isn't running it's down to less than 1% of the time (I have only tried to reproduce it about 100 times and it has never occurred when klipper isn't running).
I don't think I can live without klipper, though, unless I find some replacement for it.

In my experience, it appears to be copy related.

I never run Klipper. In one session, the bug had become repeatable. Following the lead in this thread, I launched Klipper, clicked "Clear Clipboard History", closed Klipper, and the bug was gone.  I know I had done a good amount of coy/pasting in that session. Maybe getting this bug to show itself is a matter of using the Clipboard a lot (I know, "how much is a lot?")

So is the Clipboard an entity separate from Klipper?

Is filling the Clipboard just one of the things that can cause Konqueror to miss the 'click up'?

I've now reproduced (and refined a little) the behavior I posted in comment #70.

All it took was a bunch of Ctl-C's on different words, lines or groups of lines (I had a document open in KDevelop), then go back to Konqueror and click on a folder and move the mouse horizontally off the folder icon (I used the /usr/src folder for consistency).  The bug was cleared by simply launching and closing Klipper (didn't have to clear clipboard history).

I restarted Linux and tried it again, this time performing the Ctl-C's on a document in KEdit - same results.

I have the same problem mentioned by bug reporter, but in my case the drag and drop is triggered if i click in any directory during 10 seconds after konqueror is started and i have to click several times in directory icon to select it and view it's files and subdirectories...

Problem is *NOT RESOLVED* - I'm using KDE 3.2.2 on Slackware 9.1 with QT 3.3.1

Directories with a large number of files, samba shares or when browsing directories that are actually symbolic links to other directories seem to be the main culprits.  The klipper "solution" has no effect on my visibility of this annoying bug.

Simply browse the directory tree for a few minutes and this problem will jump out at you (very embarrasing when you are trying to convince someone to use Linux / KDE)