[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdesktop problem, some investigation
From:       Michael Brade <Michael.Brade () informatik ! uni-muenchen ! de>
Date:       2001-09-04 8:49:54
[Download RAW message or body]

Hi!

On Tuesday 04 September 2001 01:21, aleXXX wrote:
> I had the strange kdesktop bug. I moved one icon on the desktop, the icon
> jumped back, and kdesktop kept refreshing with the rate of KDirWatcher.
>
> The bad thing about this bug is that after inserting and removing (!) some
> debug output the bug doesn't appear anymore. :-/
> So I couldn't find out whether my suspicion might be right:
>
> the rearranging happens if  m_hasExistingPos is false. m_hasExistingPos is
> set to true if (m_dotDirectory!=0). m_dotDirectory is new'ed in
> KDIconView::slotStarted(). This is connected to KDirLister::started().
> KDirLister::started() is emitted in KDirLister::openUrl() after a
> listDir-job is created and its signals are connected.
>
> void KDirLister::openURL( const KURL& _url, bool _showDotFiles, bool _keep
> ) {
> ...
>   m_job = KIO::listDir( _url, false /* no default GUI */ );
>   d->jobs.insert( m_job, QValueList<KIO::UDSEntry>() );
>
>   connect( m_job, SIGNAL( entries( KIO::Job*, const KIO::UDSEntryList& ) ),
>            SLOT( slotEntries( KIO::Job*, const KIO::UDSEntryList& ) ) );
>   connect( m_job, SIGNAL( result( KIO::Job * ) ),
>            SLOT( slotResult( KIO::Job * ) ) );
>   connect( m_job, SIGNAL( redirection( KIO::Job *, const KURL & ) ),
>            this, SLOT( slotRedirection( KIO::Job *, const KURL & ) ) );
>
>   emit started( _url.url() );
> }
>
> slotEntries() emits newItems(), this is connected to
> KDIconView::slotNewItems(). And in this function m_hasExistingPos is set to
> true of m_dotDirectory exists.
>
> Now I suspect that it might be possible that immediatly after the job is
> created (see lines above) it already emits entries(), which in turn causes
> KDIconView::slotNewItems() to be called. And this might perhaps happen
> *before* the line "emit started();" is reached. In this case the described
> bug could appear, since then slotNewItems() would be called *before*
> slotStarted(). (or is this nonsense ?)
> So moving the emit started() line directly below the line
> m_job=KIO::listDir(); might perhaps help.
Well shit, that's exactly what I feared when I wrote this code. But moving 
the emit started() below KIO::listDir() would mean to loose an entries() 
signal in this case, right? And moving it above the KIO::listDir() means that 
in the slot that is connected to the signal you can't use KDirLister::job() 
which is bad, even if nobody ever tried this ;), so both are no option.

*But*: IMHO it is _not_ possible that some other code (throwing any signals) 
is executed after the return of the call to KIO::listDir() and before the end 
of openURL() or am I wrong here? I don't know the internals of Qt that well...

Ciao,
  Michael

PS: reading >7000 Mail after 2 weeks of vacation is *really* evil, much more 
than this problem ;-))

-- 

       Some operating systems are called `user friendly',
             Linux however is `expert friendly'.

[prev in list] [next in list] [prev in thread] [next in thread]