[PATCH] Spring loading folder behaviour (redux)

David Faure faure at kde.org
Mon May 24 13:06:30 BST 2004


On Sunday 23 May 2004 03:37, Kévin 'ervin' Ottens wrote:
> From what I've understood KStaticDeleter is obviously for static pointers. I 
> was not using pointers...
But that was exactly the problem. Static objects lead to lots of problems
due to undefined order of construction/destruction. With pointers you can
control when things are being created and destroyed.

> Morevoer I've not found where it is stated that static objects are not 
> allowed.
I don't know where we should say it. In the developer FAQ? or rather in mistakes.html?
History of the KDE project is full of problems due to those - like a recent
crash report on kde-pim...

> [...]

This patch looks quite good.
One thing I'm wondering, is whether we could save a bit of memory by
getting rid of the SpringLoadingManager instance at the end of a dnd operation.

Would it be enough to do "deleteLater(); ms_self=0;" in finished()?
The deleteLater avoids deleting the object from a slot.
In fact if we do this we don't really need the staticdeleter anymore, since one
has to stop a dnd before exiting Konqueror anyway :)

But what happens on a timeout? The dragFinished slot will be called
after the timeout cleaned up everything, so finished() is effectively
called twice? Then my idea of "destroying in finished()" would lead
to slotDragFinished() creating the manager again, just to destroy it again...
Not too wise, I guess it could check SpringLoadingManager::exists() then,
which would be a static bool exists() { return ms_self != 0; }

(BTW static variables are usually called s_* in KDE, no 'm')

> +    emit view->extension()->setLocationBarURL( url.url() );
Should be url.prettyURL()  (to hide passwords etc.)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kfm-devel mailing list