Re: Review Request: port sonnet away from i18nc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107412/#review23979 --- staging/sonnet/src/core/loader.cpp http://git.reviewboard.kde.org/r/107412/#comment18263 This tr() call needs to use the same context as the strings. The context is the class name by default, so SomeNamespace::Loader, this doesn't match what you used in the array. Probably better to pass the context explicitely than to try and guess it though: QCoreApplication::translate(SonnetDictionaryLoader, variantEnglish, dictionary variant) - David Faure On Dec. 24, 2012, 10:03 p.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107412/ --- (Updated Dec. 24, 2012, 10:03 p.m.) Review request for kdelibs and David Faure. Description --- port sonnet away from i18nc. Diffs - staging/sonnet/src/core/loader.cpp 887aee5 staging/sonnet/src/core/settings.cpp 59cb593 staging/sonnet/src/core/speller.cpp f831f55 Diff: http://git.reviewboard.kde.org/r/107412/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Review Request: Rewrite Google's tracking URLs in search results
On Dec. 23, 2012, 12:57 p.m., Anders Lund wrote: Wouldn't it be better to improve the userscripts plugin for KHTML? I have auserscript that removes the google tracking URLS in khtml, and there are probably similar scripts eg for facebook and apart from that a lot of other usefull scripts in userscripts.org. I do not understand the rationale behind targeting one specific website this way! Just my 2c :) userscripts plugin for KHTML Do you mean this one here? http://kde-apps.org/content/show.php?content=140676 It says it is no longer maintained. I will have a look ... My code is fairly simple and more likely (I assume) to get accepted than a large solution like userscript. rationale behind targeting one specific website this way It was my itch to scratch. Google is just the start. As I stated in the code as a TODO comment: more cases to add! - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107867/#review23899 --- On Dec. 23, 2012, 11:09 a.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107867/ --- (Updated Dec. 23, 2012, 11:09 a.m.) Review request for kdelibs. Description --- This patch adds the feature to KHTML to rewrite URLs that are used to track users. Right now, only tracking URLs from Google's search result are supported, but the list can be expanded (hard-coded right now). Example: A search for KDE may result in a list of links, including a link like http://www.google.com/url?q=http://www.kde.org/sa=Uei=YsYFfgOqAZzBQBCved=GEFANYNoNGusg=Y8BfN6qj0QYNHYJQQBEB When you follow this link, Google will transparently redirect you to http://www.kde.org, but still record your behaviour. The patch rewrites such links already in the HTML parsing phase, i.e. you never see the tracking URL, but instead the final URL only. The rewrite feature can be disabled through a setting, but there is no GUI for that yet. I was thinking about automatically detecting tracking URLs through a regular expression, but I guess running a regular expression check for every URL would be too time-consuming. I wrote the patch for 4.9.3 as this is the version I am using on the testing machine. I assume the affected classes haven't changed much in recent months, so it should be fairly simple to port to HEAD or future 4.11. Diffs - khtml/khtml_settings.h 0faec6d khtml/khtml_settings.cpp b5693b4 khtml/xml/dom_docimpl.cpp bb65a89 Diff: http://git.reviewboard.kde.org/r/107867/diff/ Testing --- Thanks, Thomas Fischer
Re: Review Request: KMessageWidget: Fix infinite recursion triggered from resizeEvent()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107835/#review23947 --- Fixes cantata for me (as described in bug 311336). I could also not find regressions so far. - Martin Blumenstingl On Dec. 21, 2012, 4:39 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107835/ --- (Updated Dec. 21, 2012, 4:39 p.m.) Review request for kdelibs. Description --- When KMessageWidget width is adjusted while it is animating, it tries to resize the snapshot of its content to match the new width. This causes an infinite recursion because updating the snapshot is done with QWidget::render, which in turns activate all the layout of the owning window, which triggers a resizeEvent... Attached patch does not resize the snapshot during animation anymore, it just ensures the content is correctly sized at the end of the animation. This addresses bug 311336. http://bugs.kde.org/show_bug.cgi?id=311336 Diffs - kdeui/widgets/kmessagewidget.cpp 481ef49 Diff: http://git.reviewboard.kde.org/r/107835/diff/ Testing --- Tested with `kate +30 foo` which used to trigger the infinite recursion. Tested with kmessagewidgetdemo and kmessagewidgettest, did not spot any regression. Thanks, Aurélien Gâteau
plasma and new shadow mess
Hi Plasma world, As new shadow lands in KDE 4.10 RC1, some unintentional mess is introduced. https://bugs.kde.org/show_bug.cgi?id=311502 https://bugs.kde.org/show_bug.cgi?id=311995 And it affects some more components, at least including kmix osd, brightness osd, icontasks. The problem is, custom widget using plasma svg doesn't get new shadow support automatically, some code must be written. I observe that some components get necessary modifications, for example krunner, while also quite a few of them still not. What make this problem worse is, the necessary class for shadow is not public. And AFAIK there are already 3 copies of same code across different kde projects (kdelibs/plasma/private/dialogshadows , kde-workspace/libs/plasmagenericshell/panelshadows, and one of my own in kdeplasma-addons), plasmagenericshell is a shared library but it doesn't install header.. I think some action need to be taken before the release, some possible solutions. 1. Revert the changes of new plasma air theme, so old shadow can be used. and try to fix all the things in KDE 4.11 or 2. get some header exposed to avoid duplication of the code, and fixed every custom widget, at least including: kwin, kmix, powerdevil, icontasks. I can give out my help for fix those, but some decision still need to be made (add new header to kdelibs or kde-workspace). Regards
Review Request: try fix tooltip shadow problem
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107905/ --- Review request for kdelibs, Plasma and Aaron J. Seigo. Description --- Well. I'm not an expert in kwin related stuff, this patch is basically revert 157a06e46f46ba83ba37a93b400647f4886e18c9, but I don't know the real reason for that. And actually, remove by handle is not necessary, since dialogshadows already connect to the widget's destroyed signal, hence it will handle that gracefully. This addresses bug 311502. http://bugs.kde.org/show_bug.cgi?id=311502 Diffs - plasma/tooltipmanager.cpp 00bfcdb Diff: http://git.reviewboard.kde.org/r/107905/diff/ Testing --- seems it fixed, but not sure it's the right way. Thanks, Xuetian Weng
Re: Review Request: try fix tooltip shadow problem
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107905/ --- (Updated Dec. 25, 2012, 12:14 a.m.) Review request for kdelibs, Plasma and Aaron J. Seigo. Description --- Well. I'm not an expert in kwin related stuff, this patch is basically revert 157a06e46f46ba83ba37a93b400647f4886e18c9, but I don't know the real reason for that. And actually, remove by handle is not necessary, since dialogshadows already connect to the widget's destroyed signal, hence it will handle that gracefully. This addresses bug 311502. http://bugs.kde.org/show_bug.cgi?id=311502 Diffs (updated) - plasma/tooltipmanager.cpp 00bfcdb Diff: http://git.reviewboard.kde.org/r/107905/diff/ Testing --- seems it fixed, but not sure it's the right way. Thanks, Xuetian Weng
Re: Review of kdev-python for move to extragear
Hi, since there were no further questions or complaints, I will consider kdev-python to have passed the review process now. Thanks! Greetings, Sven 2012/12/21 Sven Brauch svenbra...@googlemail.com: Hello, the two-week review period for this project (kdev-python) has passed. The only complaint raised was related to the python fork in the repository. Was the necessarity of this sufficiently explained by my follow-up email, or does anyone think this issue needs further discussion? Best regards, Sven 2012/12/7 Laszlo Papp lp...@kde.org: On Fri, Dec 7, 2012 at 12:09 PM, Milian Wolff m...@milianw.de wrote: On Friday 07 December 2012 06:01:19 Laszlo Papp wrote: Out of the curiosity: how much python3 is available? Thank you for your work. python3 _support_ please read http://scummos.blogspot.de/2012/11/kdev-python-14-stable- released.html 1.5 will get python3 support Thank you. Laszlo
Re: Review Request: Rewrite Google's tracking URLs in search results
On Dec. 23, 2012, 12:57 p.m., Anders Lund wrote: Wouldn't it be better to improve the userscripts plugin for KHTML? I have auserscript that removes the google tracking URLS in khtml, and there are probably similar scripts eg for facebook and apart from that a lot of other usefull scripts in userscripts.org. I do not understand the rationale behind targeting one specific website this way! Just my 2c :) Thomas Fischer wrote: userscripts plugin for KHTML Do you mean this one here? http://kde-apps.org/content/show.php?content=140676 It says it is no longer maintained. I will have a look ... My code is fairly simple and more likely (I assume) to get accepted than a large solution like userscript. rationale behind targeting one specific website this way It was my itch to scratch. Google is just the start. As I stated in the code as a TODO comment: more cases to add! Hello Anders, your comment on my posting two days ago isn't here, but I'll answer it here. I agree that hardcoding replacement patterns is inflexible regarding future changes on Google's (or anyone else's) homepage. I already fetched the latest sources from KHTML-userscript and imported them into my git scratch. I'll have a closer look during the next few days. - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107867/#review23899 --- On Dec. 23, 2012, 11:09 a.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107867/ --- (Updated Dec. 23, 2012, 11:09 a.m.) Review request for kdelibs. Description --- This patch adds the feature to KHTML to rewrite URLs that are used to track users. Right now, only tracking URLs from Google's search result are supported, but the list can be expanded (hard-coded right now). Example: A search for KDE may result in a list of links, including a link like http://www.google.com/url?q=http://www.kde.org/sa=Uei=YsYFfgOqAZzBQBCved=GEFANYNoNGusg=Y8BfN6qj0QYNHYJQQBEB When you follow this link, Google will transparently redirect you to http://www.kde.org, but still record your behaviour. The patch rewrites such links already in the HTML parsing phase, i.e. you never see the tracking URL, but instead the final URL only. The rewrite feature can be disabled through a setting, but there is no GUI for that yet. I was thinking about automatically detecting tracking URLs through a regular expression, but I guess running a regular expression check for every URL would be too time-consuming. I wrote the patch for 4.9.3 as this is the version I am using on the testing machine. I assume the affected classes haven't changed much in recent months, so it should be fairly simple to port to HEAD or future 4.11. Diffs - khtml/khtml_settings.h 0faec6d khtml/khtml_settings.cpp b5693b4 khtml/xml/dom_docimpl.cpp bb65a89 Diff: http://git.reviewboard.kde.org/r/107867/diff/ Testing --- Thanks, Thomas Fischer
Review Request: Initialize datetime of tags in tags:// protocol
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107910/ --- Review request for KDE Runtime and Vishesh Handa. Description --- Tags listed in tag:// protocol show created/modified date as 7.2.2106 06:28 (which is apparently timestamp of UINT_MAX). I think showing current datetime would be better :) Diffs - nepomuk/kioslaves/tags/kio_tags.cpp a6f4632 Diff: http://git.reviewboard.kde.org/r/107910/diff/ Testing --- Thanks, Dan Vrátil
Re: plasma and new shadow mess
On Montag, 24. Dezember 2012 23:12:22 CEST, Weng Xuetian wrote: Hi Plasma world, As new shadow lands in KDE 4.10 RC1, some unintentional mess is introduced. https://bugs.kde.org/show_bug.cgi?id=311502 https://bugs.kde.org/show_bug.cgi?id=311995 I doubt those have much relation, notably #311995 is not about shadows at all, but invocation of the non-ARGB theme under certain conditions. The problem is, custom widget using plasma svg doesn't get new shadow support automatically, some code must be written. The problem of #311502 rather seems to be an insufficient repaint area - more related to bug #312168, i'd say. Wild guess from your patch: don't remove the shadows before, but *after* the hiding (eventually later, ie. in the deconstructor or on the destroyed signal) to avoid confusations between the deleted window size and the dirty area. Cheers, Thomas
Re: Review Request: try fix tooltip shadow problem
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107905/#review23982 --- Seems to be an insufficient repaint area - pot. related to bug #312168. Wild guess from your patch: don't remove the shadows before, but *after* the hiding (eventually later, ie. in the deconstructor or on the destroyed signal) to avoid confusations between the deleted window size and the dirty area. - Thomas Lübking On Dec. 25, 2012, 12:14 a.m., Xuetian Weng wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107905/ --- (Updated Dec. 25, 2012, 12:14 a.m.) Review request for kdelibs, Plasma and Aaron J. Seigo. Description --- Well. I'm not an expert in kwin related stuff, this patch is basically revert 157a06e46f46ba83ba37a93b400647f4886e18c9, but I don't know the real reason for that. And actually, remove by handle is not necessary, since dialogshadows already connect to the widget's destroyed signal, hence it will handle that gracefully. This addresses bug 311502. http://bugs.kde.org/show_bug.cgi?id=311502 Diffs - plasma/tooltipmanager.cpp 00bfcdb Diff: http://git.reviewboard.kde.org/r/107905/diff/ Testing --- seems it fixed, but not sure it's the right way. Thanks, Xuetian Weng
Re: Review of kdev-python for move to extragear
Great. :) I personally agree with the internal python reasoning, and it can be changed later anyway if it turns out to be a real problem. Laszlo On 12/25/12, Sven Brauch svenbra...@googlemail.com wrote: Hi, since there were no further questions or complaints, I will consider kdev-python to have passed the review process now. Thanks! Greetings, Sven 2012/12/21 Sven Brauch svenbra...@googlemail.com: Hello, the two-week review period for this project (kdev-python) has passed. The only complaint raised was related to the python fork in the repository. Was the necessarity of this sufficiently explained by my follow-up email, or does anyone think this issue needs further discussion? Best regards, Sven 2012/12/7 Laszlo Papp lp...@kde.org: On Fri, Dec 7, 2012 at 12:09 PM, Milian Wolff m...@milianw.de wrote: On Friday 07 December 2012 06:01:19 Laszlo Papp wrote: Out of the curiosity: how much python3 is available? Thank you for your work. python3 _support_ please read http://scummos.blogspot.de/2012/11/kdev-python-14-stable- released.html 1.5 will get python3 support Thank you. Laszlo
