Categories

rekonq 2 merged in rekonq main repository

Hi all,
just a brief announce here saying that finally rekonq 2 code has been
merged in rekonq main repository. It's really not 100% new code, but I'll
be glad you can find one moment to review it.
Keys news I'll be glad to hear comments and hints about are:
- kwebapp remove and code reorganization to use the same web classes in all
the situations (check the webtab/ dir about)
- kmainwindow remove and session reimplementation (copied from kmainwindow)
in the "rekonqwindow" class (based now on qwidget, "ready" for the QML
transition, tabwindow/ dir).
- New private browsing mode (NOT based on KIO, as it seems our cookiejar is
not enough "malleable" for it. At least in kde4)

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.

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.

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).

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 Tuesday, December 18, 2012 23:14:01 Dawit A wrote:
Is this the same issue that we can't set an empty cookiejar on the webview?
This issue bit me a while ago when using kdewebkit for an oauth
implementation, I need an empty cookiejar there because I don't want to
authenticate an already logged in user. This didn't seem possible, and I think
the problem still exists. afiestas ran into the same issue.