Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror
> On April 26, 2012, 5:09 p.m., Albert Astals Cid wrote:
> > If i understand you correctly you are suggesting to create a bug (option
> > that does nothing)?
> >
> > Doesn't make much sense.
>
> Dawit Alemayehu wrote:
> Huh ? I do not follow. By "option that does nothing" you mean this change
> by itself does nothing that is correct. But that is true of every option in
> that dialog as well. Moreover, it is a well known fact that you cannot post a
> patch for different components in reviewboard. Anyhow, the option will most
> definitely be used by kwebkitpart. Whether or not some body implements
> support for it in khtml is a question I cannot answer. That is what I meant.
>
> David Faure wrote:
> Do you have the kwebkitpart patch ready?
> I suppose it'll be easy to "apply" to khtml as well.
>
> Albert Astals Cid wrote:
> You are suggesting to add an option that does nothing in our default html
> rendering engine. That is adding a bug. The fact that you know it and don't
> care about it makes me sad.
>
> Dawit Alemayehu wrote:
> @David: Yes I have a patch for kwebkitpart, but unlike in khtml adding
> support for this in kwebkitpart required a very small change in one place in
> addition to adding code to read the config option itself in
> webkitettings.{h|cpp}. That does not seem to be the case in khtml. It is a
> little bit more invovled.
>
> @Albert: Really ?? So how exactly is another browser engine supposed to
> provide configuration option to the user if it is supposed to be embedded
> into Konqueror ? Why would a developer working on a separate browsing engine
> be forced to implement any functionality into khtml ? Would that requirement
> apply the other way around ? The last I checked, this is a konqueror setting.
> Whether a specific browser engine supports it or not is up to that browser
> engine.Just for the record I almost always go out of my way to implement
> things in khtml ; especially when I factor out features that are common to
> both engines. In this case, I neither have the time nor a complete grasp of
> how the KWallet integration works in khtml. As I stated above the change is
> not in a single isolated location like it is in kwebkitpart. Feel free to do
> a grep in khtml and see for yourself. I can always add the set/get functions
> to access the option in KHTMLSettings, but what use would that be if it is
> not implemented.
>
> Anyhow, I digress. If there are objections, I will simply move this
> feature into the webkit config module I will have to create down the road.
>
> Albert Astals Cid wrote:
> "So how exactly is another browser engine supposed to provide
> configuration option to the user if it is supposed to be embedded into
> Konqueror ?"
> Having it's own engine-only kcm for it's engine-specific options?
>
> "Why would a developer working on a separate browsing engine be forced to
> implement any functionality into khtml ?"
> When did i say that?
>
> "Would that requirement apply the other way around ?"
> If you want to use the "general" apply to all engines options page, of
> course.
>
> You probably don't have any bit of user mentallity left in your head,
> because it's pretty obvious that adding a configuration option to "web
> rendering configuration" that won't work with our default rendering engine
> it's bad usability.
>
> But hey, since David promised to implement this for khtml, go ahead,
> don't let me block progress.
>
I just briefly looked at how complex it would be to implement in KHTML, and it
seems to be enough with this three-line patch?
diff --git a/khtml/ui/passwordbar/storepassbar.cpp
b/khtml/ui/passwordbar/storepassbar.cpp
index 3f5c392..08d79a9 100644
--- a/khtml/ui/passwordbar/storepassbar.cpp
+++ b/khtml/ui/passwordbar/storepassbar.cpp
@@ -80,6 +80,10 @@ StorePass::~StorePass()
void StorePass::saveLoginInformation(const QString& host, const QString& key,
const QMap& walletMap)
{
+ KConfigGroup config( KGlobal::config(), "HTML Settings" );
+ if (!config.readEntry("OfferToSaveWebsitePassword", true))
+return;
+
m_host = host;
m_key = key;
m_walletMap = walletMap;
- Martin Tobias Holmedahl
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104631/#review12934
---
On April 26, 2012, 3:48 a.m., Dawit Alemayehu wrote:
>
> ---
> 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.
>
>
> Description
> ---
>
> A patch to make that provides an option to disable the
Re: Running tests faster..
On Tuesday 15 May 2012, David Faure wrote: > On Sunday 13 May 2012 00:04:43 Alexander Neundorf wrote: > > Hi, > > > > just a quick hint, maybe you don't know this yet: > > > > You can run tests using "make test". > > This will run test by test after each other. > > Internally this simply calls ctest. > > > > If you call ctest manually, you can use extra command line options, and, > > it supports -jN, as make does. > > > > So, if you have 4 cores, run > > ctest -j4 > > to have it execute 4 tests in parallel and save time this way. > > Save time... but at the expense of more failures, if the tests aren't > ready for this ;-) > > E.g. in kdelibs I get 3 more failures, due to ksycoca-related tests > creating and removing services that show up in other tests' queries, or > other tests reading and writing from the same shared files. There are several properties which can be set on tests: http://www.cmake.org/cmake/help/v2.8.8/cmake.html#section_PropertiesonTests among them RUN_SERIAL and DEPENDS (and COST). Using them it should be possible to avoid such failures (but I haven't used this myself yet). Alex
Review Request: KJS: fix behaviour on allocation errors
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104960/ --- Review request for kdelibs. Description --- The KJS allocator will likely crash with a 0-deref on allocation errors. The exact behaviour will also depend on the platform, e.g. a Un*x platform without posix_memalign() will have MAP_FAILED as the pointer used for calculations (which is (void*)-1), other will have 0. This will make the allocator have a sane default behaviour: just return 0. Diffs - kjs/collector.cpp 70e4757 Diff: http://git.reviewboard.kde.org/r/104960/diff/ Testing --- Thanks, Rolf Eike Beer
Review Request: QSslConfiguration set/get functions for KTcpSocket
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104958/ --- Review request for kdelibs and Thiago Macieira. Description --- The attached patch adds QSslConfiguration getter/setter functions to KTcpSocket. That way users of KTcpSocket can set their own Ssl configuration information on the socket. Note that a patch that addresses a current SSL related bug in TCPSlaveBase requires this change. See https://git.reviewboard.kde.org/r/103610/. Diffs - kdecore/network/ktcpsocket.h 982e5b1 kdecore/network/ktcpsocket.cpp 57d54a9 Diff: http://git.reviewboard.kde.org/r/104958/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request: Fix for SSL handeshake failure in TcpSlaveBase due to server not supporting SSL compression
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103610/ --- (Updated May 15, 2012, 6:31 p.m.) Review request for kdelibs and Thiago Macieira. Changes --- Split out the patch for KTcpSocket into its own review request. Description --- The attached patch addresses the issue of SSL handshake failure in TcpSlaveBase due to lack of support for disabling SSL compression in Qt. As of 4.8, Qt supports this functionality so this patch implements support for activing that support in KTcpSocket and using it from KIO::TcpSlaveBase so that users will be able to browse SSL protected sites that do not support SSL compression. This addresses bug 275524. http://bugs.kde.org/show_bug.cgi?id=275524 Diffs (updated) - kio/kio/tcpslavebase.h fea2c08 kio/kio/tcpslavebase.cpp d0f92b4 Diff: http://git.reviewboard.kde.org/r/103610/diff/ Testing --- Visit the site listed in the bug report: https://tim.rz.rwth-aachen.de/mail-lifecycle/ Thanks, Dawit Alemayehu
Re: Review Request: Fix for SSL handeshake failure in TcpSlaveBase due to server not supporting SSL compression
On terça-feira, 15 de maio de 2012 18.03.52, Dawit Alemayehu wrote: > Updated the patch. Actually make it work. > > @Thiago: do you still object to me adding a setter/getter functions for > retreiving the QSslConfiguration from KTcpSocket ? No. I actually don't remember objecting to QSslConfiguration. The problem is the KSSL* classes that are still there from KDE 3. I'd recommend you split this patch in two, though. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Review Request: Fix for SSL handeshake failure in TcpSlaveBase due to server not supporting SSL compression
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103610/ --- (Updated May 15, 2012, 6:03 p.m.) Review request for kdelibs and Thiago Macieira. Changes --- Updated the patch. Actually make it work. @Thiago: do you still object to me adding a setter/getter functions for retreiving the QSslConfiguration from KTcpSocket ? Description --- The attached patch addresses the issue of SSL handshake failure in TcpSlaveBase due to lack of support for disabling SSL compression in Qt. As of 4.8, Qt supports this functionality so this patch implements support for activing that support in KTcpSocket and using it from KIO::TcpSlaveBase so that users will be able to browse SSL protected sites that do not support SSL compression. This addresses bug 275524. http://bugs.kde.org/show_bug.cgi?id=275524 Diffs (updated) - kdecore/network/ktcpsocket.h 982e5b1 kdecore/network/ktcpsocket.cpp 57d54a9 kio/kio/tcpslavebase.h fea2c08 kio/kio/tcpslavebase.cpp d0f92b4 Diff: http://git.reviewboard.kde.org/r/103610/diff/ Testing --- Visit the site listed in the bug report: https://tim.rz.rwth-aachen.de/mail-lifecycle/ Thanks, Dawit Alemayehu
Re: Running tests faster..
On Tuesday 15 May 2012 18:47:16 Harald Sitter wrote: > On Tue, May 15, 2012 at 6:42 PM, David Faure wrote: > > E.g. in kdelibs I get 3 more failures, due to ksycoca-related tests > > creating and removing services that show up in other tests' queries, or > > other tests reading and writing from the same shared files. > > Any shared resource makes this impossible, but it's interesting to keep in > > mind for the design of future unit tests. > > TBH, a test that depends on another test sounds like a bad test and > should be fix. I am certain Kent Beck agrees ;) No no, they don't *depend* on each other. They *interfer* with each other. That's different :) Any two tests that read and write in the same file (e.g. config file) or database (e.g. ksycoca, or mysql), create such trouble. Yes it can be avoided, making sure that each test uses its own file or database, but this is extra effort, it just doesn't work out of the box, that's all I was pointing out. It's always easy (but never fair) to look back at existing things and declare them "bad" after the fact, when in fact the requirements have changed meanwhile :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
Re: Running tests faster..
On Tue, May 15, 2012 at 6:42 PM, David Faure wrote: > On Sunday 13 May 2012 00:04:43 Alexander Neundorf wrote: >> Hi, >> >> just a quick hint, maybe you don't know this yet: >> >> You can run tests using "make test". >> This will run test by test after each other. >> Internally this simply calls ctest. >> >> If you call ctest manually, you can use extra command line options, and, it >> supports -jN, as make does. >> >> So, if you have 4 cores, run >> ctest -j4 >> to have it execute 4 tests in parallel and save time this way. > > Save time... but at the expense of more failures, if the tests aren't ready > for this ;-) > > E.g. in kdelibs I get 3 more failures, due to ksycoca-related tests creating > and removing services that show up in other tests' queries, or other tests > reading and writing from the same shared files. > Any shared resource makes this impossible, but it's interesting to keep in > mind for the design of future unit tests. TBH, a test that depends on another test sounds like a bad test and should be fix. I am certain Kent Beck agrees ;) HS
Re: Running tests faster..
On Sunday 13 May 2012 00:04:43 Alexander Neundorf wrote: > Hi, > > just a quick hint, maybe you don't know this yet: > > You can run tests using "make test". > This will run test by test after each other. > Internally this simply calls ctest. > > If you call ctest manually, you can use extra command line options, and, it > supports -jN, as make does. > > So, if you have 4 cores, run > ctest -j4 > to have it execute 4 tests in parallel and save time this way. Save time... but at the expense of more failures, if the tests aren't ready for this ;-) E.g. in kdelibs I get 3 more failures, due to ksycoca-related tests creating and removing services that show up in other tests' queries, or other tests reading and writing from the same shared files. Any shared resource makes this impossible, but it's interesting to keep in mind for the design of future unit tests. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
Re: Review Request: implement support for window.onhashchange
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104946/ --- (Updated May 15, 2012, 12:56 p.m.) Review request for kdelibs. Changes --- fix issues raised so far. Description --- Implement a custom hashchange event, and make the khtml kpart emit it when we are asked to navigate to another anchor, and the ref is different. Diffs (updated) - khtml/ecma/kjs_events.h 3727b94 khtml/ecma/kjs_events.cpp e7c7e5b khtml/ecma/kjs_html.h 089b550 khtml/ecma/kjs_html.cpp d64e07c khtml/ecma/kjs_window.h 416b045 khtml/ecma/kjs_window.cpp e75e6e7 khtml/html/html_baseimpl.cpp baa13b5 khtml/khtml_part.cpp 24589e4 khtml/misc/htmlattrs.in 21a2363b khtml/misc/htmlnames.h e3adbe7 khtml/misc/htmlnames.cpp 3b22b6d khtml/xml/dom2_eventsimpl.h 5b452d2 khtml/xml/dom2_eventsimpl.cpp f01a533 Diff: http://git.reviewboard.kde.org/r/104946/diff/ Testing --- tested extensively against http://lolcats.iskrembilen.com/ Thanks, Martin Tobias Holmedahl Sandsmark
Re: kio and frameworks 5
On Friday, May 11, 2012 21:33:35 Casper Clemence wrote: > Libferris is an awesome piece of technology. It provides not just the > traditional features of a VFS but a uniform method of access for > applications and users to a large and expanding range of things. It has others have asked the "what does it do that KIO does not (or does poorly)" question, and i'll add this to it: is this about changing the application-facing API of KIO? the kioslave-facing API? (e.g. replacing current kio slaves with libferris as the 'one implementation to bind them all') the implementation of the various kioslaves (such as file, http, ...)? does this only apply to a subset of kioslaves (e.g. file, but not http)? iow, what is the scope of this discussion? :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: kio and frameworks 5
On Fri, May 11, 2012 at 10:33 PM, Casper Clemence wrote: > I'm want to start a discussion, put an idea out there. I am also being > pushy, on someone else's behalf. > > Although it may be a difficult discussion I think it would be a great shame > to miss the opportunity to have it. I'm not trying to tell anyone to "do it > this way". > > Please excuse me for saying "we" when I have not contributed to KDE as a > developer, I tied myself in knots trying to write in the third person and > gave up. > > Preamble over. > > The discussions is this "what part should libferris take in the refresh of > KIO in KDE Frameworks 5?" > > Ben Martin really should be involved in any discussion of a redesign at the > very least. He clearly has put a lot of work and thought into virtual > filesystems and has created something quite unique. > > Libferris is an awesome piece of technology. It provides not just the > traditional features of a VFS but a uniform method of access for > applications and users to a large and expanding range of things. It has been > demonstrated to work on maemo and as a Plasma DataEngine and has a web > service interface. The rate at which Ben is able to turn out new > capabilities for libferris also suggests it is well written and easy to > develop. > > A uniform method of access for applications makes developing cool new stuff > easier. A uniform method of access for users leads means a powerful tool to > do what you want with your data, browsing a database in your file browser > and dragging and dropping data around. > > So there are three points I want to suggest: > (1) Speak to Ben about the possible developments of kio > (2) learn from libferris > (3) consider adopting libferris wholesale > > Possibly the biggest pain point with adopting libferris wholesale is that > libferris indexes and KDE already has an indexer in strigi. > > But before the idea of adopting it wholesale into kdelibs is thrown out we > should ask whether the difficulty of solving any issues we have with it > really are greater than the difficulty of writing - and the advantage of > those features libferris has which would never get written into kio. > > Libferris can already talk to soprano and Nepomuk, perhaps it should be > considared whether allowing libferris to take over from strigi could > actually be a good thing. Integration of the indexer into the VFS seems > quite smart especially when the VFS knows how to read the structure of > documents as well as index the text and metadata. I don't think that it is > an easy question, whether or not it is worth it can only be answered by > looking into it in technical detail, even trying it out. One question I think might be worth asking is "what (if anything) is kio missing?" We have applications that do device or file access, such as ark and k3b, that are not using kio slaves for that access. Why not? Is it just a lack of time, or is there something fundamental in kio that makes this impossible, inefficient, or too difficult? If it is the latter, it would be good to fix it. If it is the former, then that implies kio does not provide something compelling enough for them to want to switch. The second question is, "will libferris help with this, or can it be made to help?" So I think the first question to ask is not, "should we switch to libferris?", but "what is preventing kio from being used more in KDE applications?" If libferris is a solution, or at least part of a solution, to the problem, then maybe we should consider switching. If not, then maybe another route might be better. -Todd
