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

List:       kde-core-devel
Subject:    Re: KDirWatch bug and the analysis. Help is welcome!
From:       Frank Reininghaus <frank78ac () googlemail ! com>
Date:       2013-08-01 11:24:19
Message-ID: CAFoZWWjZACZtc8s7f=kTBunjC+enK1hEPHTY9mYfmhfjD9=Hzg () mail ! gmail ! com
[Download RAW message or body]

Hi,

2013/8/1 Thomas L=FCbking:
> On Donnerstag, 1. August 2013 12:44:57 CEST, Frank Reininghaus wrote:
>>
>> Hi,
>>
>> 2013/8/1 Thomas L=FCbking:
>>>>
>>>> We could, however, fix this by filtering out hidden files ("dot files"=
)
>>>> in
>>>> the KDirWatch inotify event handling, optionally.
>>>
>>>
>>> What doesn't help you when listing them as well.
>>>
>>> Questions:
>>> 1. why does dolphin update the .directory file *intantly* and esp. whil=
e
>>> still showing the dir. Why not when eg. leaving it or when closing down
>>> (bearing the risk to loose the update when "closing down" is a segfault=
)
>>
>>
>> I'm not quite sure (I haven't implemented the .directory thing), but
>> if the modified settings were stored when leaving the directory, then
>> splitting the view, opening a new tab, or a new Dolphin/Konqueror
>> window *before* leaving the directory would still show you the
>> directory with the "old" view properties.
>
>
> Singleton cache to lookup?
> Like QHash<QString, DirSettings>
>
> class DirSettings {
>   QDateTime timeStamp;
>   bool showHidden;
>   Foo bar;
>   ....
> };
>
>
> Would work for at least single process cases.
> (Though dolphin is no more KUniqeApplication? Spawns new processes instea=
d
> of windows here)

Peter changed that quite some time ago already because the
KUniqueApplication thing caused quite a few problems (like modal
dialogs blocking all Dolphin windows, for example).

Cheers,
Frank
[prev in list] [next in list] [prev in thread] [next in thread]