Akademy hotels and hostels - book now
Hi all, Just a reminder: if you're planning to attend Akademy this year, please book you hotel or hostel room asap. Late June and July is high season in Tallinn and you might have trouble finding a hotel room if you want to book last minute. A list of recommended hostels and hotels can be found here: http://akademy.kde.org/accommodation Cheers, Claudia -- Claudia Rauch Business Manager KDE e.V. Linienstr. 141 10115 Berlin Germany
Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas afies...@kde.org wrote: After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Well actually it is a little bit simpler than that to get to what you want. Keeping only the portion of my patch that deals with disabling cookie handling in kio_http along with you setting your own custom cookiejar through QWebPage::networkAccessManager()-setCookieJar should be sufficient for what you are trying to do. However, to properly fix the issue of private browsing mode for more complex scenarios like allowing two separate instances of web browsers to share cookies as it is done in other browser implementations (I checked Chromium) requires a little bit more involved fix. We would need to use the cookiejar and that means we need a way to mark such cookies as private to the cookiejar. The trick is to do that without having to modify any of the KDE cookiejar code. I will see what I can do about that... Regards, Dawit A.
Re: Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote: On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas afies...@kde.org wrote: After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Well actually it is a little bit simpler than that to get to what you want. Keeping only the portion of my patch that deals with disabling cookie handling in kio_http along with you setting your own custom cookiejar through QWebPage::networkAccessManager()-setCookieJar should be sufficient for what you are trying to do. I will try to provide a patch, thanks for the support ! However, to properly fix the issue of private browsing mode for more complex scenarios like allowing two separate instances of web browsers to share cookies as it is done in other browser implementations (I checked Chromium) requires a little bit more involved fix. We would need to use the cookiejar and that means we need a way to mark such cookies as private to the cookiejar. The trick is to do that without having to modify any of the KDE cookiejar code. I will see what I can do about that... I have been willing to do a small app to load a single KDED for months now,though I wanted to do it for ease the development of a KDED that very same app could be used to execute another instance of KCookieJar. Flow should be something like: 1-User actiavte's private browsing 2-rekonq executes a custom KCookieJar -This could be done automatically within kdewebkit but we are in freeze -Once we fix the Be able to use custom CookieJars with KWebkit rekonq could write one to use this custom KCookieJar instance 3-Once private browsing is deactiavted, the small app is closed deleting all its content. Something I really like from that approach is that we keep things phisically separated, kded4 will handle real cookies while the new instance will handle private-browsing cookies. At the same time, if wanted we should be able to have multiple private browsing sessions.
patches too big for kdelibs 4.8?
Hello, I have kjs patches that I think are too big for KDE/4.8. Now I wonder... where should I commit them to? As far as I know kdelibs currently has 3 branches. master: which I was told is like dead KDE/4.8: bug fixes only framework: KDE5 Well, you could call these patches bug fixes as they fix some missing javascript functionality and make some websites work. But you could also call them new features as you now can use more javascript functionality. Personally I think calling them bugfixes feels somehow sneaky, to just get them in KDE/4.8. So is frameworks the correct branch for me? I think no, as framework does not have a fixed release date it too far away before it reaches the user. I would love to have a KDE/4.9 branch, but looks like it is not planned. As I plan to further hack on kjs there might be more patches coming and if possible I would love to keep the kdelibs-my kjs patches distance close. After all the helpful review and the intense ecmascript testsuite I feel rather confident that these patches work. But as you might know the web is big ;-) So big that it is impossible for to surf on all existing websites. And again 5.0 might be far away, beside from the fact that the topic in #kde-devel says no new features in kdelibs. So as I am a bit lost here, back to my basic question, where should I commit to? Or how should I continue? regards, Bernd
Re: patches too big for kdelibs 4.8?
El Dimecres, 25 d'abril de 2012, a les 20:31:37, Bernd Buschinski va escriure: Hello, I have kjs patches that I think are too big for KDE/4.8. Now I wonder... where should I commit them to? As far as I know kdelibs currently has 3 branches. master: which I was told is like dead KDE/4.8: bug fixes only framework: KDE5 Well, you could call these patches bug fixes as they fix some missing javascript functionality and make some websites work. That's a bugfix in my book. Cheers, Albert But you could also call them new features as you now can use more javascript functionality. Personally I think calling them bugfixes feels somehow sneaky, to just get them in KDE/4.8. So is frameworks the correct branch for me? I think no, as framework does not have a fixed release date it too far away before it reaches the user. I would love to have a KDE/4.9 branch, but looks like it is not planned. As I plan to further hack on kjs there might be more patches coming and if possible I would love to keep the kdelibs-my kjs patches distance close. After all the helpful review and the intense ecmascript testsuite I feel rather confident that these patches work. But as you might know the web is big ;-) So big that it is impossible for to surf on all existing websites. And again 5.0 might be far away, beside from the fact that the topic in #kde-devel says no new features in kdelibs. So as I am a bit lost here, back to my basic question, where should I commit to? Or how should I continue? regards, Bernd
Re: patches too big for kdelibs 4.8?
On Wednesday 25 April 2012 20:31:37 Bernd Buschinski wrote: I have kjs patches that I think are too big for KDE/4.8. [...] Well, you could call these patches bug fixes as they fix some missing javascript functionality and make some websites work. Every bug fix enables a feature which should have been there in the first place, so I agree with Albert that these should go to the 4.8 branch after review. Maybe do not push them a day before the tagging, so that we have a full month's time to check and test more intrusive changes. Let me add that I am very happy to see that you are improving Konqueror. Be assured that there are still users who did not ditch it yet ;) Thanks! Christoph Feck (kdepepo) KDE Quality Team
Re: Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Wed, Apr 25, 2012 at 1:05 PM, Alex Fiestas afies...@kde.org wrote: On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote: On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas afies...@kde.org wrote: After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Well actually it is a little bit simpler than that to get to what you want. Keeping only the portion of my patch that deals with disabling cookie handling in kio_http along with you setting your own custom cookiejar through QWebPage::networkAccessManager()-setCookieJar should be sufficient for what you are trying to do. I will try to provide a patch, thanks for the support ! If you wait a litte while I am going to fix this issue once and for all since I want to add proper support for Private browsing mode in kwebkitpart. I am sure the reKonq guys/gals will appreciate that as well. However, to properly fix the issue of private browsing mode for more complex scenarios like allowing two separate instances of web browsers to share cookies as it is done in other browser implementations (I checked Chromium) requires a little bit more involved fix. We would need to use the cookiejar and that means we need a way to mark such cookies as private to the cookiejar. The trick is to do that without having to modify any of the KDE cookiejar code. I will see what I can do about that... I have been willing to do a small app to load a single KDED for months now,though I wanted to do it for ease the development of a KDED that very same app could be used to execute another instance of KCookieJar. Flow should be something like: 1-User actiavte's private browsing 2-rekonq executes a custom KCookieJar -This could be done automatically within kdewebkit but we are in freeze -Once we fix the Be able to use custom CookieJars with KWebkit rekonq could write one to use this custom KCookieJar instance 3-Once private browsing is deactiavted, the small app is closed deleting all its content. Something I really like from that approach is that we keep things phisically separated, kded4 will handle real cookies while the new instance will handle private-browsing cookies. Why unnecessarily waste memory ? I personally do not like this idea. For every application that starts its own private browsing mode there will be a separate instance of kcookiejar ? That is completely unwarranted. Plus there will most definitely be unforeseen consequences for having multiple instances of kcookiejar running. For example, you cannot predict how the cookie management dialog would behave under such circumstances. I personally believe there are easier ways to deal with this without having to change any code in kcookiejar. However, I won't be able to know that for sure until I try it and see if it passes all test cases. I will do that soon as I want to have this functionality in for KDE 4.9 at least.
Extra KDE Telepathy modules moving to Extragear
We would like to move 2 more KDE Telepathy modules to Extragear, to join our existing code. KTp Call UI [1] Provides a GUI for making video calls in telepathy. For details see [2][3] Telepathy Logger Qt [4] This provides Qt bindings for Telepathy-Logger a daemon that logs all text messages received. This is an optional dependency for ktp-text-ui which allows us to show a backlog and a way to view old log messages. This was imported from Collabora's git repository. I moved it into KDE playground where I'm maintaining it after Collabora seemed to lose any interest in keeping it up to date or making a release. This has been discussed on their mailing list. [5]. Thanks in advance David Edmundson [1] https://projects.kde.org/projects/kdereview/ktp-call-ui [2] http://gkiagia.wordpress.com/2012/03/29/video-calls-in-kde-telepathy/ [3] http://community.kde.org/Real-Time_Communication_and_Collaboration/Components/Call_UI [4] https://projects.kde.org/projects/kdereview/telepathy-logger-qt [5] http://mail.kde.org/pipermail/kde-telepathy/2012-January/005064.html
Re: Review Request: Fix wrong time zone abbreviation being returned for early dates
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104599/#review12909 --- This review has been submitted with commit 192b43ce1f6a474564f4cc0be20f97a5fa53fc5a by David Jarvie to branch KDE/4.8. - Commit Hook On April 14, 2012, 7:30 p.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104599/ --- (Updated April 14, 2012, 7:30 p.m.) Review request for kdelibs. Description --- KTzfileTimeZone, and therefore time zones provided by KSystemTimeZones, returns the wrong time zone abbreviation for dates earlier than the start of time zone data in the time zone configuration file. This patch fixes that, but requires a new variant of the setPhases() method to be added to KTimeZone. The existing variant of setPhases() will be marked as deprecated. Note that this method is only for use by classes derived from KTimeZone, so the number of users of these methods will be very limited (as far as I know, only ICalTimeZone in kdepimlibs). Diffs - kdecore/date/ktimezone.h f591747 kdecore/date/ktimezone.cpp 076d459 kdecore/date/ktzfiletimezone.cpp 1ebca9d kdecore/tests/ktimezonestest.cpp 3a2402e Diff: http://git.reviewboard.kde.org/r/104599/diff/ Testing --- KTimeZone unit test now works after removing the temporary bodge put in because of this bug. Thanks, David Jarvie
Re: Review Request: More kio_sftp login related fixes
On April 21, 2012, 9:05 a.m., Andreas Schneider wrote: Did you also test if keyboard-interactive still works correctly? Dawit Alemayehu wrote: No, because I do not even know how to enable that functionality in my ssh config and was lazy to search and find out. Just looking at the code though I immediately see a problem where it sets the error message in the first dialog box which will cause the retry dialog to be shown. I dunno if that was intentional, but it is wrong. The user will not only see the message sent from the ioslave, but also gets the question Do you want to retry?. BTW, I take back what I stated in the description of problem #1. It is not my last patch that caused the bug. It is there prior to my patch as well since I checked out and tested v4.8.0 to see if that was the case. Anyhow, I can try to see if I can figure out how to enable keyboard interactive mode and test that too. For the record I did not actually set out to fix these issues in kio_sftp. It resulted from my work on fixing problems in kpasswdserver. I needed someway to test those changes and the ssh server happens to be something that is already up and running on my system. Lucky kio_sftp. ;) Andreas Schneider wrote: Normally password authentication is turned off in the ssh server (default for openssh) and keyboard interactive is used. There are some flaws in password authentication and keyboard-interactive is a much more flexible way. So if you have current Linux distribution then password authentication is turned of and you have keyboard-interactive authentication connecting to localhost. Thanks for all the fixes. I don't have time for libssh and kio_sftp lately. There are other projects I need to drive forward right now :) Well I finally had the time to figure out how to activate keyboard interactive and completely cleaned up the sftp login code to make it more readable. I removed the usage of the go to statement to avoid iterating through all the authentication methods just to retry password authentication. However, for the life of me I cannot figure out how the authenticateKeyboardInteractive is supposed to work. For me it does not work at all because it does not prompt me for the password. I read documentation you provided at http://api.libssh.org/stable/libssh_tutor_authentication.html. What I gathered from reading the documentation is that, in keyboard interactive mode, the server can send a challenge for which the user is supposed to provide an answer. The server indicates that it is sending such challenge prompt by setting the echo parameter to 1. Is that correct ? If it is, how that is then handled is rather befuddling to me. For example, the errorMsg parameter of the openPassword function is always set to the same text. That will cause the retry dialog to be shown with the Do you want to retry? question mark. Was that intentional ? What is being achieved by that. I would have tested it myself I had known what option to set in sshd_config to make the server send such challenge. I am sure if The scenario I was able to test on my system is where the echo parameter is set to 0 and the prompt is set to Password. In that case for some reason, the user is never prompted to enter the password. Instead the value of mPassword is assigned to it. Was that because the other password dialog (one used for authentication) was used to prompt for username and password already ? Anyhow, I have attached the latest incarnation which cleans up all the previous authentication related changes I made. It is much cleaner and easier to understand the flow of the authentication code now. - Dawit --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104642/#review12748 --- On April 26, 2012, 3:42 a.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104642/ --- (Updated April 26, 2012, 3:42 a.m.) Review request for KDE Runtime and Andreas Schneider. Description --- This is the last one of the sftp login fixes series and addresses the following problems: #1. Correctly handle login failure that results from a different username being used when setting the SSH_OPTIONS_USER option and calling ssh_userauth_password. I think this might have been due to a regression caused by my previous patch. Nonetheless, this patch addresses it. #2. Changed public key authentication so that incorrect public key passwords generate a retry dialog instead of simply continuing to the next available authentication method. Diffs -
Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104631/ --- (Updated April 26, 2012, 3:48 a.m.) Review request for KDE Base Apps, kdelibs and David Faure. Changes --- Added a screen shot of the config option. If there are no objections, I am going to commit this in a couple of days. Hopefully the khtml guys will implement this option there as well. Description --- A patch to make that provides an option to disable the offer to save website passwords. Note that for this patch to take effect this option will have to be used at at the browser engine level. Those patches are separate to this one. This is just the GUI configuration. Diffs - konqueror/settings/konqhtml/htmlopts.h 69f36d8 konqueror/settings/konqhtml/htmlopts.cpp e5d6deb Diff: http://git.reviewboard.kde.org/r/104631/diff/ Testing --- Screenshots (updated) --- Option for disabling KWallet integration http://git.reviewboard.kde.org/r/104631/s/544/ Thanks, Dawit Alemayehu
