[PATCH] juk: save TagEditor's configuration on exit.

Γιώργος Κυλάφας (Giorgos Kylafas) gekylafas at gmail.com
Sun May 1 10:29:38 BST 2011

2011/4/30 Michael Pyne <mpyne at kde.org>:
> On Friday, April 29, 2011 11:48:34 Î“Î¹ÏŽÏ Î³Î¿Ï‚ Κυλάφας wrote:
>> I noticed that every time I restarted Juk, I had to re-select
>> View-->Show TagEditor for the latter to show up.
>> After investigation, I found out that the TagEditor's configuration
>> was not saved upon exit, becausePlaylistSplitter::m_editor was never
>> delete-d in PlaylistSplitter's dtor, so TagEditor::saveConfig() was
>> never called.
> This is actually not true. If you put a kDebug() call into
> TagEditor::saveConfig() you'll see that it is called.

Hmmm, I am almost certain I _did_ put a kWarning() there which did not
show up. However, now that I test it again, it does indeed get called!
Oh well...

> The reason it gets called is because TagEditor is a QObject subclass, which is
> indirectly descended from PlaylistSplitter (look at where m_editor is
> initialized in playlistsplitter.cpp, near line 184, and you'll be able to
> verify this by tracing the ancestry chain).
> However, the children of QObjects that have not already been destroyed do not
> get destroyed until right after the parent's destructor has run, and they get
> destroyed in an essentially random order.
> Your patch ensures the config is written out while all of the KActions are
> still valid, and so /does/ seem to fix the error... just not for the reason
> you think. ;)

Thanks for the explanation, it would be hard to understand what really
happens without it. :-)

Γιώργος Κυλάφας (Giorgos Kylafas)
kde-multimedia mailing list
kde-multimedia at kde.org

More information about the kde-multimedia mailing list