Re: Review Request: kio_http: fix keepalive timeout parsing
On Oct. 12, 2011, 5:55 a.m., Dawit Alemayehu wrote: kioslave/http/http.cpp, line 3107 http://git.reviewboard.kde.org/r/102822/diff/1/?file=38514#file38514line3107 This seems unnecessary to me since the parser produces a lower case token to begin with. hmm... i did more tests and can't confirm what you say. If server sends timeOut=5 - tIt.next() == timeOut=5 - Andrea --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102822/#review7251 --- On Oct. 10, 2011, 10:35 p.m., Andrea Iacovitti wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102822/ --- (Updated Oct. 10, 2011, 10:35 p.m.) Review request for kdelibs, Andreas Hartmetz and Dawit Alemayehu. Description --- Keep-alive header can specify multiple, comma-separated, value pairs. For example what apache web server normally sends is something like that: Keep-Alive: timeout=5, max=99 Actually kio_http fails to extract timeout value because it assumes keep-alive header can contain only a single value pair. In the case of example above what it end up to do is m_request.keepAliveTimeout = QString(5, max=99).toInt(), that returns 0 (wrong!). Diffs - kioslave/http/http.cpp 2862707 kioslave/http/parsinghelpers.cpp fc75d68 Diff: http://git.reviewboard.kde.org/r/102822/diff/diff Testing --- -Patched code compiles -Hacked a web server and made tests against following keep-alive header variants: Keep-Alive: timeout=5, max=99 Keep-Alive: Timeout=5, max=99 (uppercase 'T') Keep-Alive: Timeout=5 , max=99(extra space before comma) Thanks, Andrea Iacovitti
R: Re: Review Request: kio_http: fix keepalive timeout parsing
Testing --- -Patched code compiles -Hacked a web server and made tests against following keep-alive header variants: Keep-Alive: timeout=5, max=99 Keep-Alive: Timeout=5, max=99 (uppercase 'T') Keep-Alive: Timeout=5 , max=99(extra space before comma) I don't know which RfC this comes from and if that makes any requirements rfc 2068 (19.7.1.1) about the ordering, but other header fields (like Content-Disposition) do not have some. So what happens with e.g.: max=99, timeout=5 max = 99, timeout = 5 foo = bar, timeout = 5 Parsinghelpers returns all tokens between commas, we loop through those tokens to find the one that starts with timeout= So the order doesn't matter. Is it possible to add a unit test for this? Well i think it is, i could try... AI.
Re: Review Request: facePerm is a KDM option, unrelated to the user setting his face (for other apps)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102799/ --- (Updated Oct. 12, 2011, 4:55 p.m.) Review request for KDE Base Apps. Changes --- Removed unnecessary whitespace changes, and the new Remove image button (I will create a separate request for it). I always used the coding style of the function I changed, the file contains a mixture of tabs and 2-whitespace indents. What is the kdelibs style? Description --- Currently, the User account password KCM refuses to change the user image if KDM is set up not to use user images. That however does not make much sense, all this applet does is writing the image to ~/.face.icon, which the user can do manually anyway. The fact that KDM might or might not actually display this image in the user selection is unrelated, as KDM is not even the only user of this file: Plasma Kickoff displays it, and maybe more apps use it (GDM uses a different file, though) This patch therefore removes the check for the KDM settings and makes the KCM simply manage the .face.icon file. It does not fall back to the system default if the user image does not exist, as Plasma Kickoff does not do that either. The patch also adds a button in the Change face dialogue to remove the user image, to make it possible to go back to the default state again. After changing the image, the user still has to log off and on again for Plasma to use it - Plasma would have to somehow listen to changes to that file. I don't know if that is desired. This addresses bug 183245. http://bugs.kde.org/show_bug.cgi?id=183245 Diffs (updated) - kdepasswd/kcm/main.h 320126f kdepasswd/kcm/main.cpp 5ce1961 Diff: http://git.reviewboard.kde.org/r/102799/diff/diff Testing --- Compiled and verified that the KCM now behaves as desired. Thanks, Ralf Jung
Re: Re: Re: Re: Security Audit Request for Screenlocker Branch
On Wednesday 12 October 2011 19:38:11 Oswald Buddenhagen wrote: On Wed, Oct 12, 2011 at 04:47:54PM +0200, Dario Freddi wrote: 2011/10/12 Martin Gräßlin mgraess...@kde.org: ok I have been thinking about it and have a new proposal: * writing a kded module to only handle the screen locking (grab keyboard and mouse) TBH, if you really care about not making the thing crash, I would not put it into KDED, which has a lot of things which are not under your control potentially crashy, but into a separate running daemon. my first thought, too. :} ok, so a separate running daemon it shall be * having greeter in a separate process, so that the kded module can restart the greeter in case it crashes * use xproperty on all greeter windows to inform the compositor which windows belong to it i'm assuming you are including the locker/saver window in greeter windows? Yes, everything visual in the separate process. * use a kwin effect to additionally ensure that the screen is blanked and nothing gets above the greeter windows that seems superfluous. the presence of the locker window simultaneously indicates locker mode and provides blanking content (rendered by an out-of-process hack and blanked in-process as a fallback). when that goes away unexpectedly, all bets are off anyway. See Thomas mail: with compositing enabled some xscreensavers fail to blank the screen. The main reason for the effect would be to fade in/out the locker, but when we have it, we can also use it to fix this annoying bug only present with compositing. Cheers Martin signature.asc Description: This is a digitally signed message part.
Call for the next release codename to be Ritchie
I guess I should have posted this to release team mailing list, but this way the topic will have more people involved. As you all (probably) know, Dennis Ritchie has passed away. In my opinion, we should somehow make tribute to him. I'm not sure the idea to name a release after him would be fitting, but that's the only thing I've came up with. -- Ivan
Re: Call for the next release codename to be Ritchie
A Dijous, 13 d'octubre de 2011, Ivan Čukić vàreu escriure: I guess I should have posted this to release team mailing list, but this way the topic will have more people involved. As you all (probably) know, Dennis Ritchie has passed away. In my opinion, we should somehow make tribute to him. I'm not sure the idea to name a release after him would be fitting, but that's the only thing I've came up with. You want the release team for this ;-) Albert -- Ivan
Re: Call for the next release codename to be Ritchie
On Thursday 13 October 2011 11:49:19 Ivan Čukić wrote: You want the release team for this ;-) Yes, as I said: I guess I should have posted this to release team mailing list, but this way the topic will have more people involved. Just wanted a general core-dev response, not only those who make releases. Sure, if a naming flamefest can't be big enough on a small list, let's do it on a list with more subscribers. /irony Sorry this isn't how it works. We have specific lists for specific purposes, please respect that. The noise ratio on kde-core-devel is already high enough. And release-team@ has probably many more subscribers than you think. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: Call for the next release codename to be Ritchie
Sure, if a naming flamefest can't be big enough on a small list, let's do it on a list with more subscribers. /irony Ok, I apologize. Didn't really exoect something like this to become a flamefest. Mail sent to the r-t.
Re: small license problem in kdelibs
On Monday 26 September 2011 5:45:43 AM Marco Martin wrote: Hi all, last days, after we asked some more pair of eyes to check the licensing in plasma active, a thing was discovered: many LGPL licensed files had an header like that (you know, power of copy and paste ;) /* * Copyright 2010 Marco Martin notm...@gmail.com * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU Library General Public License as * published by the Free Software Foundation; either version 2, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details * * You should have received a copy of the GNU Library General Public * License along with this program; if not, write to the * Free Software Foundation, Inc., * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ as you note, talks about library general public license, then ...PARTICULAR PURPOSE. See the GNU General Public License for more details while it should be ...PARTICULAR PURPOSE. See the GNU Library General Public License for more details i guess it's an issue that krazy doesn't detect. Do you think this is something Krazy should look for? i.e, if the license seems to be LGPL, check for ... GNU Library General Public... right? or don't bother?
Re: Some help for recreating the Plasma Tool Box in QML
On Fri, Oct 7, 2011 at 9:40 PM, Mark mark...@gmail.com wrote: Hi KDE folks, It's been a long while since i last actively contributed to the KDE project. Sadly having a job is sucking up way more time then i would like. In recent months I've started to experiment with QML and started to like it. Provided if i only use it for declaring the GUI. Not the app logic, that should stay in C++ imho. I tried some things with it and it certainly is cool and powerful but now i want to do something useful with it. And given that KDE is going towards QML anyways I though I could provide my help and start with something. The thing I'd like to do is recreate the plasma tool box thing (the one in the lower right corner of your panel). My first goal is to make it exactly the same as it is now just in QML. Once that is done and working the same as the current Plasma Tool Box then i want to add something to it. I want to add setting the background image in the plasma toolbox. It will look about the same as the current part for Add Widgets... only with wallpapers. I don't know if changing the desktop background from the plasma tool box is the best way but to me it seems to be more logical then in Desktop - right mouse click - Desktop Settings .. It's something i'd like to experiment with :) There are a few questions though. Since i'm directing my efforts in one specific area i really don't want to spend hours/days to figure the new build system out, figuring out which branches i need for what and where the QML files for KDE are hidden (some of them are made in the recently ended GSOC right?). So i would like to ask for some quick pointers to get me started. Note: i want to run the basic KDE SC environment with the default tools as a separate user all from git. There used to be a magnificent tutorial for that on the KDE wiki but that was the old build style even with SVN things. * What is the current way to get the basic KDE SC running from Git? * What settings do i need to use? * Which branches do i need for QML + KDE? * Where do i need to be for recreating the plasma tool box in QML? kdebase-workspace? * How do i get a QML file running without the window decorations (the current plasma tool box doesn't have decorations so i guess i don't want them in QML either) * Target: KDE 4.8? I think that covers about all my questions. Last but not least. Above is just my idea of what i'd like to do. I've not spend any time yet on making anything and don't know if anyone else is already working on this. I also don't know if this is a change people want.. So some more information here would be nice. Kind regards and thanx in favor for any responses, Mark Anyone?
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Wednesday, 12. October 2011 02:12:55 Thomas Lübking wrote: Let me give my view here: Do you have configured a saver beyond dpms? And if, why? Do you use a locker beyond a black screen? And if, why? yes to both (diashow). Reason: make other people wandering by (or sitting in the same room during a presentation when the screen content is currently not needed but the display is still shown with the beamer, e.g. lengthy discussions) aware of an OS called Linux and a desktop system called KDE. I show pictures from kde-look etc. showing the KDE and Linux logos. Note: I very seldom have my laptop running on battery. Mostly AC, so power saving is of no concern to me. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Tuesday, 11. October 2011 21:11:03 Martin Gräßlin wrote: I consider most effects being bling yes, with that said I like it and appreciate it but still most effects add no real productive value. offtopicI have to disagree. By default we ship no effect which is bling only. They all add productive value. Even something like a fade effect is a productive value and not bling as it makes the system a more natural thing to use./offtopic I'm sorry but this makes me laugh. What productivity gain do I have when using the Snow or wobbly windows effect ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Thursday 13 October 2011 17:29:16 Martin Koller wrote: On Tuesday, 11. October 2011 21:11:03 Martin Gräßlin wrote: I consider most effects being bling yes, with that said I like it and appreciate it but still most effects add no real productive value. offtopicI have to disagree. By default we ship no effect which is bling only. They all add productive value. Even something like a fade effect is a productive value and not bling as it makes the system a more natural thing to use./offtopic I'm sorry but this makes me laugh. What productivity gain do I have when using the Snow or wobbly windows effect ? Sorry I wanted to write by default we ship no effect enabled which is bling only. Snow btw was my first contribution to KDE and I removed it for 4.7... just for the facts about the importance of bling. Wobbly is of course not enabled by default. As soon as we have a sufficient solution to build and distribute effects not bundled with KWin all non-productive effects will be moved into something like kde-artwork. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Review Request: facePerm is a KDM option, unrelated to the user setting his face (for other apps)
No tabs, 4 spaces instead. http://techbase.kde.org/Policies/Kdelibs_Coding_Style On 12 October 2011 12:55, Ralf Jung ralfjun...@gmx.de wrote: This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102799/ Review request for KDE Base Apps. By Ralf Jung. *Updated Oct. 12, 2011, 4:55 p.m.* Changes Removed unnecessary whitespace changes, and the new Remove image button (I will create a separate request for it). I always used the coding style of the function I changed, the file contains a mixture of tabs and 2-whitespace indents. What is the kdelibs style? Description Currently, the User account password KCM refuses to change the user image if KDM is set up not to use user images. That however does not make much sense, all this applet does is writing the image to ~/.face.icon, which the user can do manually anyway. The fact that KDM might or might not actually display this image in the user selection is unrelated, as KDM is not even the only user of this file: Plasma Kickoff displays it, and maybe more apps use it (GDM uses a different file, though) This patch therefore removes the check for the KDM settings and makes the KCM simply manage the .face.icon file. It does not fall back to the system default if the user image does not exist, as Plasma Kickoff does not do that either. The patch also adds a button in the Change face dialogue to remove the user image, to make it possible to go back to the default state again. After changing the image, the user still has to log off and on again for Plasma to use it - Plasma would have to somehow listen to changes to that file. I don't know if that is desired. Testing Compiled and verified that the KCM now behaves as desired. *Bugs: * 183245 http://bugs.kde.org/show_bug.cgi?id=183245 Diffs (updated) - kdepasswd/kcm/main.h (320126f) - kdepasswd/kcm/main.cpp (5ce1961) View Diff http://git.reviewboard.kde.org/r/102799/diff/
Re: Review Request: Cleanup the use of HTTPProtocol::httpClose
On Oct. 12, 2011, 10:51 p.m., Andreas Hartmetz wrote: This changeset changes some important parts without obvious (to me) gain. Before I spend an hour or two thinking through all the cases, which may or may not catch potential regressions, I'd like to know what this does for us. The current approach of acting a bit dumb seems more robust. Here is the gains we get out of this change: #1. Keep persistent connection on non-connection related errors. There is no reason to tear down our connection to a server on errors such as ERR_USR_CANCELED. #2. Avoid unnecessary performance hit by not calling httpClose multiple times. This is especially true for ::get which is by the far the most called function in this ioslave. For no good reason however, httpClose is called at least two times everytime ::get is successfully invoked. BTW, if you tell me the use cases which I should test, then I will be willing to do the regression testing. I have already gone through each of the ioslave functions to see if this change will affect any of them. I have even tested the most commonly used ones (get, post, put) through a proxy server to see if there are any regressions. So far I have not encountered one. - Dawit --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102801/#review7282 --- On Oct. 8, 2011, 5:16 a.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102801/ --- (Updated Oct. 8, 2011, 5:16 a.m.) Review request for kdelibs and Andreas Hartmetz. Description --- This patch cleans up where and under what circumstances httpClose gets called. This is done to avoid unnecessary invocation of httpClose. With this patch the function will only get called under the following circumstances: #1. from functions that only call proceedUntilResponseHeader directly. #2. from proceedUntilResponseContent. #3. from error #4. from davFinished. The main purpose of this change is to avoid httpClose being called multiple times on every GET request which is by far the most invoked call. Diffs - kioslave/http/http.h 4c62841 kioslave/http/http.cpp 2862707 Diff: http://git.reviewboard.kde.org/r/102801/diff/diff Testing --- Thanks, Dawit Alemayehu
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
Am Thu, 13 Oct 2011 18:24:55 +0200 schrieb todd rme toddrme2...@gmail.com: At least for me wobbly windows provides visual feedback when moving windows that I find useful. I used it a lot on compiz, but the Kwin one never really worked all that well but I would have it enabled if it did. Try advanced mode, the presets are somehow odd (to me) Stiffness: 40 Drag: 85 Move factor: 4 but after all, I'd still just consider it an annoyance. Cheers, Thomas
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
Am Wed, 12 Oct 2011 16:37:41 -0400 schrieb Michael Pyne mp...@kde.org: Sure it can. Just click Test in the Display Monitor screen saver options. ;) There's probably some DBus call to do the same thing. i thought about kstart --fullscreen kdeasciiquarium, fails because the window us resized externally (configure request) rather than by the screensaver class which probably sets the window fullscreen before the derived constructor is called. I will admit that resize is not supported, mostly because scaling down the text makes it completely impossible to see. From what i can say, the size impacts the amount of fishes and the area size, so it's not just a scale up/down (which should be done adjusting the font size, never by naive pixmap/image scaling. Hinting will more or less ensure the font remains visible) If you happen to meet him and he should actually require guidance in how to fix that, he may just call back. *cough* I'm open to suggestions. from a rough look on the code (still no git?) it seems to be sufficient to catch resize events on Screen (eg. with an eventfilter in AASaver), remove all sprites and do the addAll* from the constructor again. For scaling, the new size would be exposed to the sprites so they can wipe the caches and recreate them with a new font size. I guess my point is pretty much the same actually: Locking and screensaver animations should be orthogonal -- it should continue to be possible to kick off the screensaver without forcing on the lock. No - it should be possible to run nice little animations for personal joy whenever you want, but the screensaver just kicks in because the system is idle - it now had the chance to save a lot of energy AND the screen by simply turning the screen off, since nobody is watching. Instead it's keeping the screen turned on and also peaks the CPU/GPU for really amazing visual things - that unfortunately nobody sees (or wants to see, because otherwise he'd just activated them) = The screensaver hacks (ie. the nifty shows) need some propagation elsewhere, eg. some dropdown your 5 minutes of zen plasmoid. Launching the screensaver kcm and click the demo button is as cumbersome as taking away hands from keyboard and mouse and just wait five minutes or so. Video players usually trigger some action to prevent the screensavers from activation and if you steer on eg. a complex formula, it'd be more than annoying if it suddenly disappears (while xdpms shares this issue with screensavers) So the only sane reason these things to show up automatically is that the system is abandoned and than it's no more sane to run them. Cheers, Thomas
Re: Screensaver to be or not to be
Am 13.10.2011 20:21, schrieb Thomas Lübking: [...] it now had the chance to save a lot of energy AND the screen by simply turning the screen off, since nobody is watching. [...] So the only sane reason these things to show up automatically is that the system is abandoned and than it's no more sane to run them. That assumption is wrong. First of all why should there be different screen savers if none was looking at them? Second I just saw a screensaver the last days -- not my machine -- how is that possible if nobody is watching? Well if you are in an office there are more PCs than just yours. Something like a screen saver is for sure not bad for motivation or mood, rather the opposite. Further being in front of the pc does not mean that you are constantly interacting with it. Sometimes you are noting things, reading some information which is on paper etc. That is the moment something like a screen-prettisers (better than saver? ;) ) kicks in which might cause a little cheering up. The argument of saving energy is kinda hypocritical if you look at what most people use their computer for. If energy saving is the reason to deactivate things that some people enjoy -- they actually see these things from time to time -- then anything flash related should be deactivated, youtube should not be watched and even better the pc should stay turned off most of the time for most people. Thus energy saving is imo not a valid argument here. Screen prettisers are off by default and by default none forces people to visit youtube. If they decide so, well fine for them. I understand and agree to the technical reasons against keeping the current architecture but that does not mean that I agree to all the other arguments.
Re: Re: Screensaver to be or not to be
On Thursday 13 October 2011 20:49:29 Matthias Fuchs wrote: I understand and agree to the technical reasons against keeping the current architecture but that does not mean that I agree to all the other arguments. I just want to point out once more that we will not remove anything which is possible today. The only thing we remove is the coupling of screen savers/animation with screen locker. This means * if a screen saver is configured, this screen saver will be used also in locked condition in 4.8 * in 4.9 we will switch to a new QML based screen animation framework inside the screen locker. This means even if an old screen saver is configured the new screen locker will kick in. With other words: all the fancy things while screens are locked are still possible, just with a new framework \o/ * it is still possible to just use xscreensaver without configuring the lock, so all the old stuff is still possible \o/ * it is still possible to configure any script in power management profile, this can be a screen saver or any other fullscreen application or gwenview started as diashow or whatever \o/ So can we please stop the discussion? We are not removing something which will not be possible any more. We just decouple the automatic triggering of screen animations with screen locking as those are orthognal approaches. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Screensaver to be or not to be
Am 13.10.2011 21:09, schrieb Martin Gräßlin: On Thursday 13 October 2011 20:49:29 Matthias Fuchs wrote: I understand and agree to the technical reasons against keeping the current architecture but that does not mean that I agree to all the other arguments. I just want to point out once more that we will not remove anything which is possible today. The only thing we remove is the coupling of screen savers/animation with screen locker. Yes I understood that and do not argue on that. I simply oppose the way some people argue on screensavers in general.
Review Request: Improved proxy data caching in KProtocolManager
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102840/ --- Review request for kdelibs. Description --- The attached patch attempts to improve proxy lookup performance by using QCache to cache the proxy data for the last 100 (QCache default) lookups instead of caching just the last lookup. The current approach, where only the last lookup is cached, is useless whenever two consecutive requests for proxy data are for different URLs. Diffs - kio/kio/kprotocolmanager.cpp 92519e4 Diff: http://git.reviewboard.kde.org/r/102840/diff/diff Testing --- Thanks, Dawit Alemayehu
Re: Review Request: kio_http: fix keepalive timeout parsing
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102822/#review7299 --- Ship it! No objections from me either. I confused the iteratator function with the next in HTTPTokenizer ; so as Andreas already indicated feel free to commit this. - Dawit Alemayehu On Oct. 13, 2011, 5:59 p.m., Andrea Iacovitti wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102822/ --- (Updated Oct. 13, 2011, 5:59 p.m.) Review request for kdelibs, Andreas Hartmetz and Dawit Alemayehu. Description --- Keep-alive header can specify multiple, comma-separated, value pairs. For example what apache web server normally sends is something like that: Keep-Alive: timeout=5, max=99 Actually kio_http fails to extract timeout value because it assumes keep-alive header can contain only a single value pair. In the case of example above what it end up to do is m_request.keepAliveTimeout = QString(5, max=99).toInt(), that returns 0 (wrong!). Diffs - kioslave/http/http.cpp 2862707 kioslave/http/parsinghelpers.cpp fc75d68 Diff: http://git.reviewboard.kde.org/r/102822/diff/diff Testing --- -Patched code compiles -Hacked a web server and made tests against following keep-alive header variants: Keep-Alive: timeout=5, max=99 Keep-Alive: Timeout=5, max=99 (uppercase 'T') Keep-Alive: Timeout=5 , max=99(extra space before comma) Thanks, Andrea Iacovitti
Re: Security Audit Request for Screenlocker Branch
On Wed, Oct 12, 2011 at 09:39:48PM +0200, Thomas Lübking wrote: Stupid question, but since kdm links X11 and communicates with the greeter anyway: can we simply have it grab keyboard and mouse (must create a window in the session for this purpose, but it runs on root privs) using the kdm greeter for that basically equates making kdm handle the screenlocking entirely. which is a good idea as such. but consider that the greeter doesn't run while the session is up, so interaction would come with some delay. one could pre-launch it already when locking, i guess. one would probably put the locking engine's input handling inside the kdm backend (which, btw, means throwing some qt rudiments out of it) and feed the greeter with events just like the locker's plasma overlay is currently fed - that would make login time and in-session greeting pretty much identical. the greeter isn't necessarily root-owned (when correctly configured), but it still has the power to wreak some havoc (it's obvious that one would use the integration to implement early shutdown feedback and proper fast user switching, which means that the greeter can issue potentially destructive commands). the greeter recently stopped grabbing input by default, as that breaks input aids. this *must* be reverted to allow entry of other user's credentials. it's likely that the input redirection concept would cover auxilary windows adequately, just like it does for the plasma overlay. there are probably some more challenges i haven't considered. * use a kwin effect to additionally ensure that the screen is blanked and nothing gets above the greeter windows that seems superfluous. the presence of the locker window simultaneously indicates locker mode and provides blanking content Yesno, as mentioned w/ active compositing an ARGB window is pot. translucent. At least if the locker window is ARGB, this has to be covered by the compositor (but that's a tech. detail about broken screensavers) by initially wiping the scene and then only painting the locker/greeter right, i only thought about initial blanking. so the effect would explicitly black out all translucent areas of the main locker window. i guess that makes sense. On Wed, Oct 12, 2011 at 09:09:28PM +0200, Thomas Lübking wrote: Am Wed, 12 Oct 2011 09:10:40 +0200 schrieb Oswald Buddenhagen o...@kde.org: that's not a response to my question. the old lock engine offers the option to start a saver which only after a few seconds requires a password to make it go away. I think it was, because the idea is that the locker, unlike today savers, does not start automatically. The screen is just turned off to save it. well, that means that i was right, because even the premise for my question would not be satisfied any more. That might however be shortsighted, since it *could* be required to cover stupid users who just walk away and forget to lock their screen while they actually should. indeed. On Thu, Oct 13, 2011 at 10:26:39AM +0200, Martin Gräßlin wrote: * use xproperty on all greeter windows to inform the compositor which windows belong to it i'm assuming you are including the locker/saver window in greeter windows? Yes, everything visual in the separate process. if you make that process_es_, then it's correct. :)
Re: [proposal] KSecretsService components moving from playground
On Wednesday, 12. October 2011 01:09:51 Valentin Rusu wrote: I personally have been looking forward to KSecretsService and I like the idea of leaving KSecretsService unused by default for now, but it should at least be stressed to downstream to leave it off by default and why you chose it to be off for this release, if you do decide to implement it for 4.8. I assume there is a reason you decided to leave it off by default? Yes, I decided that precisely to avoid pitfalls I saw when KDE 4 arrived. Let's put the code in for 4.8, voluntarily test it by voluntarily checking that box, then put it on by default with the next 2012 release. What about adding a warning text at the checkbox, e.g. (experimental) like with Linux kernel drivers when configuring which makes the status clear and brave people only will try to activate it ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: [proposal] KSecretsService components moving from playground
On 10/13/2011 10:28 PM, Martin Koller wrote: On Wednesday, 12. October 2011 01:09:51 Valentin Rusu wrote: I personally have been looking forward to KSecretsService and I like the idea of leaving KSecretsService unused by default for now, but it should at least be stressed to downstream to leave it off by default and why you chose it to be off for this release, if you do decide to implement it for 4.8. I assume there is a reason you decided to leave it off by default? Yes, I decided that precisely to avoid pitfalls I saw when KDE 4 arrived. Let's put the code in for 4.8, voluntarily test it by voluntarily checking that box, then put it on by default with the next 2012 release. What about adding a warning text at the checkbox, e.g. (experimental) like with Linux kernel drivers when configuring which makes the status clear and brave people only will try to activate it ? Good idea! Thanks -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Review Request: Proxy overhaul Part 6: Proxy Configuration dialog rewrite
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102802/ --- Review request for KDE Base Apps. Description --- This patch completely overhauls the proxy configuration dialog so that it is much simpler to use and maintain. The major difference between it and the old configuration dialog is the merging of the configuration dialogs for the different proxy types into the main proxy dialog and the addition of a new input for specifying SOCKS proxy settings. See the attached screenshots to see how the new dialog looks. This addresses bugs 82352, 139789, 142562, 145006, 147340, 164460, 189019, 190149, 190901, 205594, 258196, and 283226. http://bugs.kde.org/show_bug.cgi?id=82352 http://bugs.kde.org/show_bug.cgi?id=139789 http://bugs.kde.org/show_bug.cgi?id=142562 http://bugs.kde.org/show_bug.cgi?id=145006 http://bugs.kde.org/show_bug.cgi?id=147340 http://bugs.kde.org/show_bug.cgi?id=164460 http://bugs.kde.org/show_bug.cgi?id=189019 http://bugs.kde.org/show_bug.cgi?id=190149 http://bugs.kde.org/show_bug.cgi?id=190901 http://bugs.kde.org/show_bug.cgi?id=205594 http://bugs.kde.org/show_bug.cgi?id=258196 http://bugs.kde.org/show_bug.cgi?id=283226 Diffs - konqueror/settings/kio/CMakeLists.txt e5476c9 konqueror/settings/kio/envvarproxy.ui a09450d konqueror/settings/kio/kenvvarproxydlg.h c7d2f5f konqueror/settings/kio/kenvvarproxydlg.cpp ef5c86c konqueror/settings/kio/kmanualproxydlg.h 4efa63c konqueror/settings/kio/kmanualproxydlg.cpp 6760957 konqueror/settings/kio/kproxydlg.h b2cafb8 konqueror/settings/kio/kproxydlg.cpp 2f512ce konqueror/settings/kio/kproxydlg.ui 96ff996 konqueror/settings/kio/kproxydlgbase.h 2047b90 konqueror/settings/kio/kproxydlgbase.cpp 9933698 konqueror/settings/kio/ksaveioconfig.h e895c2c konqueror/settings/kio/ksaveioconfig.cpp 62852fa konqueror/settings/kio/manualproxy.ui c69047f Diff: http://git.reviewboard.kde.org/r/102802/diff/diff Testing --- - Configure proxy through dialog and validate the results by checking the settings saved in $KDEHOME/share/config/kioslaverc. - Reloading the proxy dialog to see the saved information is properly loaded back again. Screenshots --- No Proxy http://git.reviewboard.kde.org/r/102802/s/296/ PAC Proxy http://git.reviewboard.kde.org/r/102802/s/297/ System Proxy http://git.reviewboard.kde.org/r/102802/s/298/ Manual Proxy http://git.reviewboard.kde.org/r/102802/s/299/ Thanks, Dawit Alemayehu
Re: Review Request: kio_http: fix keepalive timeout parsing
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102822/#review7302 --- This review has been submitted with commit 3be117c3007aadde359daed22b1bd629f3ff3d85 by Andrea Iacovitti to branch KDE/4.7. - Commit Hook On Oct. 13, 2011, 5:59 p.m., Andrea Iacovitti wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102822/ --- (Updated Oct. 13, 2011, 5:59 p.m.) Review request for kdelibs, Andreas Hartmetz and Dawit Alemayehu. Description --- Keep-alive header can specify multiple, comma-separated, value pairs. For example what apache web server normally sends is something like that: Keep-Alive: timeout=5, max=99 Actually kio_http fails to extract timeout value because it assumes keep-alive header can contain only a single value pair. In the case of example above what it end up to do is m_request.keepAliveTimeout = QString(5, max=99).toInt(), that returns 0 (wrong!). Diffs - kioslave/http/http.cpp 2862707 kioslave/http/parsinghelpers.cpp fc75d68 Diff: http://git.reviewboard.kde.org/r/102822/diff/diff Testing --- -Patched code compiles -Hacked a web server and made tests against following keep-alive header variants: Keep-Alive: timeout=5, max=99 Keep-Alive: Timeout=5, max=99 (uppercase 'T') Keep-Alive: Timeout=5 , max=99(extra space before comma) Thanks, Andrea Iacovitti
Re: Review Request: facePerm is a KDM option, unrelated to the user setting his face (for other apps)
On 13 October 2011 16:53, Ralf Jung ralfjun...@gmx.de wrote: Hi, No tabs, 4 spaces instead. http://techbase.kde.org/Policies/Kdelibs_Coding_Style Almost the complete main.cpp is using tabs currently (except for KCMUserAccount::decodeImgDrop, which uses 2 spaces) so I used it for the two lines I added. Is that okay, or am I supposed to use 4 spaces nevertheless? It's up to the maintainer of the code to accept your code (and he probably won't care about the coding style this time since every line but the last two you added were _already_ using tabs and 2 spaces), but why not use the astyle script to format the files, so everything is correct? Upload a new version of your patch but with only style changes. Kind regards, Ralf
Re: Review Request: facePerm is a KDM option, unrelated to the user setting his face (for other apps)
On Thu, Oct 13, 2011 at 06:27:45PM -0400, Steven Sroka wrote: On 13 October 2011 16:53, Ralf Jung ralfjun...@gmx.de wrote: No tabs, 4 spaces instead. http://techbase.kde.org/Policies/Kdelibs_Coding_Style Almost the complete main.cpp is using tabs currently (except for KCMUserAccount::decodeImgDrop, which uses 2 spaces) so I used it for the two lines I added. Is that okay, or am I supposed to use 4 spaces nevertheless? oh, well, just leave it as-is. It's up to the maintainer of the code to accept your code ... which maintainer, i wonder ... by appearances, it would be scripty. Upload a new version of your patch but with only style changes. only if you are really bored ...
Re: Review Request: Proxy overhaul Part 6: Proxy Configuration dialog rewrite
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102802/#review7304 --- Nice, work, as always :) Only one question: Do the port spin boxes need the Port: labels, as seen in the ASCII drawings from bug 147340? Or would it clutter the interface? Maybe a Hostname and Port headline for the two columns? - Christoph Feck On Oct. 13, 2011, 9:13 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102802/ --- (Updated Oct. 13, 2011, 9:13 p.m.) Review request for KDE Base Apps. Description --- This patch completely overhauls the proxy configuration dialog so that it is much simpler to use and maintain. The major difference between it and the old configuration dialog is the merging of the configuration dialogs for the different proxy types into the main proxy dialog and the addition of a new input for specifying SOCKS proxy settings. See the attached screenshots to see how the new dialog looks. This addresses bugs 82352, 139789, 142562, 145006, 147340, 164460, 189019, 190149, 190901, 205594, 258196, and 283226. http://bugs.kde.org/show_bug.cgi?id=82352 http://bugs.kde.org/show_bug.cgi?id=139789 http://bugs.kde.org/show_bug.cgi?id=142562 http://bugs.kde.org/show_bug.cgi?id=145006 http://bugs.kde.org/show_bug.cgi?id=147340 http://bugs.kde.org/show_bug.cgi?id=164460 http://bugs.kde.org/show_bug.cgi?id=189019 http://bugs.kde.org/show_bug.cgi?id=190149 http://bugs.kde.org/show_bug.cgi?id=190901 http://bugs.kde.org/show_bug.cgi?id=205594 http://bugs.kde.org/show_bug.cgi?id=258196 http://bugs.kde.org/show_bug.cgi?id=283226 Diffs - konqueror/settings/kio/CMakeLists.txt e5476c9 konqueror/settings/kio/envvarproxy.ui a09450d konqueror/settings/kio/kenvvarproxydlg.h c7d2f5f konqueror/settings/kio/kenvvarproxydlg.cpp ef5c86c konqueror/settings/kio/kmanualproxydlg.h 4efa63c konqueror/settings/kio/kmanualproxydlg.cpp 6760957 konqueror/settings/kio/kproxydlg.h b2cafb8 konqueror/settings/kio/kproxydlg.cpp 2f512ce konqueror/settings/kio/kproxydlg.ui 96ff996 konqueror/settings/kio/kproxydlgbase.h 2047b90 konqueror/settings/kio/kproxydlgbase.cpp 9933698 konqueror/settings/kio/ksaveioconfig.h e895c2c konqueror/settings/kio/ksaveioconfig.cpp 62852fa konqueror/settings/kio/manualproxy.ui c69047f Diff: http://git.reviewboard.kde.org/r/102802/diff/diff Testing --- - Configure proxy through dialog and validate the results by checking the settings saved in $KDEHOME/share/config/kioslaverc. - Reloading the proxy dialog to see the saved information is properly loaded back again. Screenshots --- No Proxy http://git.reviewboard.kde.org/r/102802/s/296/ PAC Proxy http://git.reviewboard.kde.org/r/102802/s/297/ System Proxy http://git.reviewboard.kde.org/r/102802/s/298/ Manual Proxy http://git.reviewboard.kde.org/r/102802/s/299/ Thanks, Dawit Alemayehu
Re: Review Request: Proxy overhaul Part 6: Proxy Configuration dialog rewrite
On Oct. 14, 2011, 12:05 a.m., Christoph Feck wrote: Nice, work, as always :) Only one question: Do the port spin boxes need the Port: labels, as seen in the ASCII drawings from bug 147340? Or would it clutter the interface? Maybe a Hostname and Port headline for the two columns? I guess Port: can be added. I simply copied what was in the old configuration dialog with very minor modifications. I do not have a preference one way or the other. I will add the port labels to clarify the interface and make sure users understand the purpose of those inputs. - Dawit --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102802/#review7304 --- On Oct. 13, 2011, 9:13 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102802/ --- (Updated Oct. 13, 2011, 9:13 p.m.) Review request for KDE Base Apps. Description --- This patch completely overhauls the proxy configuration dialog so that it is much simpler to use and maintain. The major difference between it and the old configuration dialog is the merging of the configuration dialogs for the different proxy types into the main proxy dialog and the addition of a new input for specifying SOCKS proxy settings. See the attached screenshots to see how the new dialog looks. This addresses bugs 82352, 139789, 142562, 145006, 147340, 164460, 189019, 190149, 190901, 205594, 258196, and 283226. http://bugs.kde.org/show_bug.cgi?id=82352 http://bugs.kde.org/show_bug.cgi?id=139789 http://bugs.kde.org/show_bug.cgi?id=142562 http://bugs.kde.org/show_bug.cgi?id=145006 http://bugs.kde.org/show_bug.cgi?id=147340 http://bugs.kde.org/show_bug.cgi?id=164460 http://bugs.kde.org/show_bug.cgi?id=189019 http://bugs.kde.org/show_bug.cgi?id=190149 http://bugs.kde.org/show_bug.cgi?id=190901 http://bugs.kde.org/show_bug.cgi?id=205594 http://bugs.kde.org/show_bug.cgi?id=258196 http://bugs.kde.org/show_bug.cgi?id=283226 Diffs - konqueror/settings/kio/CMakeLists.txt e5476c9 konqueror/settings/kio/envvarproxy.ui a09450d konqueror/settings/kio/kenvvarproxydlg.h c7d2f5f konqueror/settings/kio/kenvvarproxydlg.cpp ef5c86c konqueror/settings/kio/kmanualproxydlg.h 4efa63c konqueror/settings/kio/kmanualproxydlg.cpp 6760957 konqueror/settings/kio/kproxydlg.h b2cafb8 konqueror/settings/kio/kproxydlg.cpp 2f512ce konqueror/settings/kio/kproxydlg.ui 96ff996 konqueror/settings/kio/kproxydlgbase.h 2047b90 konqueror/settings/kio/kproxydlgbase.cpp 9933698 konqueror/settings/kio/ksaveioconfig.h e895c2c konqueror/settings/kio/ksaveioconfig.cpp 62852fa konqueror/settings/kio/manualproxy.ui c69047f Diff: http://git.reviewboard.kde.org/r/102802/diff/diff Testing --- - Configure proxy through dialog and validate the results by checking the settings saved in $KDEHOME/share/config/kioslaverc. - Reloading the proxy dialog to see the saved information is properly loaded back again. Screenshots --- No Proxy http://git.reviewboard.kde.org/r/102802/s/296/ PAC Proxy http://git.reviewboard.kde.org/r/102802/s/297/ System Proxy http://git.reviewboard.kde.org/r/102802/s/298/ Manual Proxy http://git.reviewboard.kde.org/r/102802/s/299/ Thanks, Dawit Alemayehu
Re: Review Request: Proxy overhaul Part 6: Proxy Configuration dialog rewrite
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102802/ --- (Updated Oct. 14, 2011, 5:32 a.m.) Review request for KDE Base Apps. Changes --- * Added Port: label to GUI. * Fixed bug in the code the loads proxy settings from file. Description --- This patch completely overhauls the proxy configuration dialog so that it is much simpler to use and maintain. The major difference between it and the old configuration dialog is the merging of the configuration dialogs for the different proxy types into the main proxy dialog and the addition of a new input for specifying SOCKS proxy settings. See the attached screenshots to see how the new dialog looks. This addresses bugs 82352, 139789, 142562, 145006, 147340, 164460, 189019, 190149, 190901, 205594, 258196, and 283226. http://bugs.kde.org/show_bug.cgi?id=82352 http://bugs.kde.org/show_bug.cgi?id=139789 http://bugs.kde.org/show_bug.cgi?id=142562 http://bugs.kde.org/show_bug.cgi?id=145006 http://bugs.kde.org/show_bug.cgi?id=147340 http://bugs.kde.org/show_bug.cgi?id=164460 http://bugs.kde.org/show_bug.cgi?id=189019 http://bugs.kde.org/show_bug.cgi?id=190149 http://bugs.kde.org/show_bug.cgi?id=190901 http://bugs.kde.org/show_bug.cgi?id=205594 http://bugs.kde.org/show_bug.cgi?id=258196 http://bugs.kde.org/show_bug.cgi?id=283226 Diffs (updated) - konqueror/settings/kio/CMakeLists.txt e5476c9 konqueror/settings/kio/envvarproxy.ui a09450d konqueror/settings/kio/kenvvarproxydlg.h c7d2f5f konqueror/settings/kio/kenvvarproxydlg.cpp ef5c86c konqueror/settings/kio/kmanualproxydlg.h 4efa63c konqueror/settings/kio/kmanualproxydlg.cpp 6760957 konqueror/settings/kio/kproxydlg.h b2cafb8 konqueror/settings/kio/kproxydlg.cpp 2f512ce konqueror/settings/kio/kproxydlg.ui 96ff996 konqueror/settings/kio/kproxydlgbase.h 2047b90 konqueror/settings/kio/kproxydlgbase.cpp 9933698 konqueror/settings/kio/ksaveioconfig.h e895c2c konqueror/settings/kio/ksaveioconfig.cpp 62852fa konqueror/settings/kio/manualproxy.ui c69047f Diff: http://git.reviewboard.kde.org/r/102802/diff/diff Testing --- - Configure proxy through dialog and validate the results by checking the settings saved in $KDEHOME/share/config/kioslaverc. - Reloading the proxy dialog to see the saved information is properly loaded back again. Screenshots (updated) --- No Proxy http://git.reviewboard.kde.org/r/102802/s/296/ PAC Proxy http://git.reviewboard.kde.org/r/102802/s/297/ System Proxy http://git.reviewboard.kde.org/r/102802/s/298/ Manual Proxy http://git.reviewboard.kde.org/r/102802/s/301/ Thanks, Dawit Alemayehu
