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

List:       kfm-devel
Subject:    Re: Clear Web History and KDE Control Center
From:       "Maksim Orlovich" <mo85 () cornell ! edu>
Date:       2007-12-25 21:49:10
Message-ID: 10358.24.58.159.73.1198619350.squirrel () webmail ! cornell ! edu
[Download RAW message or body]

> On Sunday 23 December 2007, Maksim Orlovich wrote:
>> <snip a very helpful report I am not sure of how to best to address at
>> the
>> moment, not having had my morning tea>
>>
>> > void KonqHistoryManager::notifyClear( QCString )
>> > {
>> >     clearPending();
>> >     m_history.clear();
>> >     m_pCompletion->clear();
>> >
>> >     if ( isSenderOfBroadcast() )
>> > 	saveHistory();
>> >
>> >     KParts::HistoryProvider::clear(); // also emits the cleared()
>> signal
>> > }
>> >
>> >
>> > if you remove line "if ( isSenderOfBroadcast() )" history is saved as
>> it
>> > should, but I don't know if that line is used for something else.
>>
>> The point of that line is so that when one clears the history, only one
>> browser instance saves it. That's obviously important for things like
>> adding a history entry (people already dislike konqueror saving history
>> to
>> often -- and imagine if every single process did it!), in which case the
>> instance responsible for the entry is the instance saving it. Perhaps
>> for
>> clearing this can be removed, though, since it's hardly a background
>> operation. An alternative is perhaps to change the check to:
>>
>> if ( isSenderOfBroadcast() ||
>> !callingDcopClient()->senderId().startsWith("konqueror") )
>>
>>
>> but then one would have the same multi-write stampede from the KCM,
>> anyway.
>
> Yeah. I think the best solution would be a new DCOP (DBus) method call
> that the KCM calls in one konqueror instance. Then that instance would do
> the above
> and take care of the saving.
>
>> I suppose then the best thing for would indeed be to just remove
>> the check as suggested... Seems like 4.0 behaves the same.
>
> Actually I can't find the "privacy" module anywhere in trunk !?!?

Good point... I only looked at konq/libkonq code. This happened:
http://lists.kde.org/?l=kde-commits&m=112789066730068&w=2
and then this:
http://lists.kde.org/?l=kde-commits&m=112881565227914&w=2



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