Well if we simply ignore the "private session" cookies in the cookie management dialog, then the problem becomes much easier. One will only have to add the concept of "private" cookies to the cookiejar and make sure cookies marked as such are always treated as session cookies and only available to windows that claim to be "private". That is not a difficult thing to accomplish. I have to see how the other browsers handle that situation.

BTW, there is a very big limitation to using QNAM and QNetworkCookieJar to implement "private" browsing mode. Your "private" session is limited to one single window. If you launch a second window in "private" mode, then it will not be able to share the private cookies with the other private window. Dunno if that is a desired behavior for you but I think chrome allows that by default. I dunno what Firefox does, but I am sure its behavior is probably similar.

Anyhow, I am will try to find some time to add "private" browsing mode support for kcookiejar during the upcoming holidays. Otherwise, I will outline how to do it and someone else can take a crack at it.

On Wed, Dec 19, 2012 at 1:05 PM, andrea diamantini <adjam7@gmail.com> wrote:

I though that way, too. My problem was just that implementing my ideas about did not lead to a "working" solution. And I really cannot release another time with a private "non-really-private" incognito mode.
About your difficulties, I can just say that, IMHO, "private session" cookies have to be completely ignored even from the cookie dialog. They cannot be stored on disk. And they have to disappear from memory as soon as the private session ends.

That's because the "empty cookiejar problem" looks similar. And using Qt network classes seems easier.
On QNAM you can create a QNetworkCookieJar on the fly, use and delete it when your session finishes. With KIO you cannot do this as we have just ONE cookiejar kde-wise. So the approach has to be:

- you cannot no more store cookies (dawit just implemented this, I think)
- you cannot no more use old cookies stored (my first attempt here failed)
- you have to manage your session "session cookies" (that is, use in your private session and delete them when it (and NOT kde session) finishes).
2012/12/19 Dawit A <adawit@kde.org>
Well that is not entirely correct. We can definitely implement support for private mode in the cookiejar itself easily. There are a couple of approaches we can take. The difficult part has always been how to handle the "private session" cookies in the cookie management dialogs. Anyhow, I promised to try and implement this for 4.10, but I could not find the time. Perhaps I will find some time during the upcoming holidays.
On Mon, Dec 17, 2012 at 7:18 PM, andrea diamantini <adjam7@gmail.com> wrote:
Yes, I'm obviously trying.
My first attempt was a tiny change in the KCookieServer/KCookieJar API to let people search just for persistent cookies.

But it failed.
I'm currently working on a second attempt following the same approach. If not, I though about implementing a different jar for the private sessions. But this second idea is probably an "hard" change in the kde cookie jar.

I fear that "private sessions" are exactly the opposite idea around what the "monolithic" & "share it with every app" kde cookie jar is builded.
2012/12/17 David Faure <faure@kde.org>

On Sunday 16 December 2012 18:41:31 andrea diamantini wrote:
> - New private browsing mode (NOT based on KIO, as it seems our cookiejar is
> not enough "malleable" for it. At least in kde4)

Are you working on patches to make it "malleable" enough in the future?

If you need something, make it happen, don't just hope for others to do so :)

--
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
--
Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode
--
Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode