Re: Moving Milou to Extragear

2014-02-12 Thread Vishesh Handa
On Tuesday, February 11, 2014 11:48:44 PM Albert Astals Cid wrote:

 Repo name?

Oops. It's called milou.

Clone it via the standard - kde:milou

-- 
Vishesh Handa


Re: Review Request 114479: Select the newly created bookmark folder as the current item

2014-02-12 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114479/#review49637
---


This review has been submitted with commit 
4d34879e8e253286030a0f7193b6bd90ea4bf1a8 by Dawit Alemayehu to branch master.

- Commit Hook


On Dec. 24, 2013, 2:50 p.m., Dawit Alemayehu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/114479/
 ---
 
 (Updated Dec. 24, 2013, 2:50 p.m.)
 
 
 Review request for kdelibs and David Faure.
 
 
 Bugs: 152158
 http://bugs.kde.org/show_bug.cgi?id=152158
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 When a user creates a new bookmark folder in the Add Bookmark dialog, make it 
 the current selected item.
 
 
 Diffs
 -
 
   kio/bookmarks/kbookmarkdialog.h a746c22 
   kio/bookmarks/kbookmarkdialog.cc 713ceff 
 
 Diff: https://git.reviewboard.kde.org/r/114479/diff/
 
 
 Testing
 ---
 
 
 File Attachments
 
 
 Add new folder w/o patch
   
 https://git.reviewboard.kde.org/media/uploaded/files/2013/12/15/1be1b4c9-eddd-43cf-b3fa-18cc0a44b212__before.png
 Add new folder w/ patch
   
 https://git.reviewboard.kde.org/media/uploaded/files/2013/12/15/353b3c50-ccc8-4390-9d76-a9f85a703987__after.png
 
 
 Thanks,
 
 Dawit Alemayehu
 




Re: Review Request 114473: Change modality of dialog in KRun::displayOpenWithDialog to Qt::WindowModal

2014-02-12 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114473/#review49638
---


This review has been submitted with commit 
6d99b077800b62c68370a1e916a64ffcbc2bb73d by Dawit Alemayehu to branch master.

- Commit Hook


On Dec. 22, 2013, 1:29 p.m., Dawit Alemayehu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/114473/
 ---
 
 (Updated Dec. 22, 2013, 1:29 p.m.)
 
 
 Review request for kdelibs and David Faure.
 
 
 Bugs: 153421
 http://bugs.kde.org/show_bug.cgi?id=153421
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 The attached patch changes the KOpenWith dialog in 
 KRun::displayOpenWithDialog from blocking Konqueror windows when a user 
 clicks on OpenWith in the context menu or unknown file in the Dolphin part.
 
 
 Diffs
 -
 
   kio/kio/krun.cpp ad5656e 
 
 Diff: https://git.reviewboard.kde.org/r/114473/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Dawit Alemayehu
 




Re: Review Request 114436: Set WindowModality of all KIO message box to Qt::WindowModal

2014-02-12 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114436/#review49639
---


This review has been submitted with commit 
0704d649cb478aff5058dc3f0ac6294abf8a579d by Dawit Alemayehu to branch master.

- Commit Hook


On Dec. 24, 2013, 3:01 p.m., Dawit Alemayehu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/114436/
 ---
 
 (Updated Dec. 24, 2013, 3:01 p.m.)
 
 
 Review request for kdelibs, David Faure and Frank Reininghaus.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 The attached patch changes the WindowModality of all the message/information 
 boxes displayed by KIO::JobUiDelegate to Qt::WindowModal instead of 
 Qt::ApplicationModal. This prevents a message box in one window from blocking 
 all other windows.
 
 
 Diffs
 -
 
   kio/kio/jobuidelegate.cpp 8534863 
 
 Diff: https://git.reviewboard.kde.org/r/114436/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Dawit Alemayehu
 




Re: Review Request 115689: Fix khtml/ecma/xmlhttprequest.cpp to properly handle HEAD requests

2014-02-12 Thread Dawit Alemayehu

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115689/
---

(Updated Feb. 12, 2014, 9:56 a.m.)


Review request for kdelibs and Andrea Iacovitti.


Changes
---

Uploaded the patch. 

Please note that the relevant patch to this pull request is the one that 
changes khtml/ecma/xmlhttprequest.cpp and adds CMD_STAT to 
TransferJob::slotFinished's switch statement. Unfortunately, this patch depends 
on another one that is currently in review, 
https://git.reviewboard.kde.org/r/115651/, hence the posted patch here contains 
the changes from that review request as well.


Bugs: 331007
http://bugs.kde.org/show_bug.cgi?id=331007


Repository: kdelibs


Description
---

Fix khtml/ecma/xmlttprequest.cpp such that it correctly handles HEAD requests 
without a noticable delay, i.e. use KIO::mimeType instead of KIO::get. 
Otherwise, the request will wait for the content which is not returned when 
doing a stat operation like HEAD.


Diffs (updated)
-

  khtml/ecma/xmlhttprequest.cpp b3707e7 
  kio/DESIGN.metadata 1351119 
  kio/kio/accessmanager.cpp 7a806e8 
  kio/kio/job.cpp 13107c2 
  kioslave/http/http.cpp b13eed1 

Diff: https://git.reviewboard.kde.org/r/115689/diff/


Testing
---

Tested HEAD redirection with http://greenbytes.de/tech/tc/httpredirects/


Thanks,

Dawit Alemayehu



KDE Review: Move LabPlot to extragear.

2014-02-12 Thread Alexander Semke
Hi all,

couple of days ago LabPlot-project [1] decided to move to KDE and to become a 
part of KDE Edu and to collaborate closer with people involved in other 
projects on KDE Edu [2]. After almost four years of development we had the 
first stable release shortly [3] and the first bug fix release.

The repository is currently placed at [4]. Documentation is still missing and 
there're couple of issues reported by krazy (mostly related to i18n). We're 
already working on them.

I would like to request a review of the project and to move, if accepted, to 
extragear. 

Best regards
Alexander


[1] http://labplot.sourceforge.net/
[2] http://lists.kde.org/?l=kde-edum=138822352206203w=2
[3] http://lists.kde.org/?l=kde-edum=139016959012000w=1 (release)
[4] https://projects.kde.org/projects/kdereview/labplot



Review Request 115695: Rework KNotification to work without KNotify daemon

2014-02-12 Thread Martin Klapetek

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115695/
---

Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela.


Repository: knotifications


Description
---

This patch merges KNotify daemon into KNotificationManager to have less daemons 
running and less dbus traffic. The patch is not yet finished (and for now it's 
full of QDebugs, that will all be removed and FIXMEs to indicate what needs 
doing), but as the Alpha2 is quite soon, I'd like to start the general review 
asap so some more changes can be done if needed.

Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them 
the notification directly. KNotifyConfig was repurposed a bit, now it serves 
mostly just as the .notifyrc wrapper, all the rest is reused from the 
KNotification object. There are some changes in the KNotification API - id() 
and appName() are now exposed to public and slotReceivedId(int) is now also 
public so that KNotificationManager can directly give it an id. I'd like to 
rename this and make it a non-slot. It's not the DBus/Galago server ID anymore, 
that is handled in NotifyByPopup which is responsible for communicating with 
the galago server (all the methods there were renamed to actually have *galago* 
in the name so it's clear), therefore the mapping of DBus/Galago Server ids is 
managed only there as it is actually only needed here. KNotitification::id() is 
assigned by the KNotificationManager and it's a simple increasing counter.

The UI/Plasmoid changes will come next - basically the plan is to put only the 
Persistent notifications in the notifications history.


Diffs
-

  src/notifybypopupgrowl.cpp PRE-CREATION 
  src/notifybypopupgrowl.h PRE-CREATION 
  src/notifybypopup.cpp PRE-CREATION 
  src/notifybypopup.h PRE-CREATION 
  src/knotifyplugin.h PRE-CREATION 
  src/knotifyplugin.cpp PRE-CREATION 
  src/knotifyconfig.cpp PRE-CREATION 
  src/knotifyconfig.h PRE-CREATION 
  src/knotificationmanager.cpp a4d0dfa 
  src/knotificationmanager_p.h 81d962d 
  src/knotification.cpp 5d7405b 
  src/knotification.h 00554ba 
  CMakeLists.txt 63ebf71 
  src/CMakeLists.txt a81b913 

Diff: https://git.reviewboard.kde.org/r/115695/diff/


Testing
---

Works perfectly with both plasma notifications and kpassivepopup.


Thanks,

Martin Klapetek



Re: Review Request 115689: Fix khtml/ecma/xmlhttprequest.cpp to properly handle HEAD requests

2014-02-12 Thread Rolf Eike Beer

Am 12.02.2014 10:56, schrieb Dawit Alemayehu:

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115689/
---

(Updated Feb. 12, 2014, 9:56 a.m.)


Review request for kdelibs and Andrea Iacovitti.


Changes
---

Uploaded the patch.


It looks to me as if the patch also contains the stuff for RR 115651.

Eike


Re: Review Request 115651: Fix HTTP redirection handling (3XX status code)

2014-02-12 Thread Andrea Iacovitti

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115651/#review49669
---


As stated in the bug report it is also true that every other browsers rewrite 
POST method to GET when following 301/302 redirections. This behavior could 
also be verified in curl by issuing the following commands:
curl -L --data fakepostdata 
http://greenbytes.de/tech/tc/httpredirects/redirect_with_status.cgi?301
curl -L --data fakepostdata 
http://greenbytes.de/tech/tc/httpredirects/redirect_with_status.cgi?302
We could/should do the same for compatibility.
In that case the snippet of code that handles 301-303 http status codes may 
assume this form:

} else if (m_request.responseCode = 301  m_request.responseCode= 
303) {
// NOTE: This is wrong according to RFC 2616 (section 10.3.[2-4,8]).
// However, because almost all client implementations treat a 
301/302
// response as a 303 response in violation of the spec, many servers
// have simply adapted to this way of doing things! Thus, we are
// forced to do the same thing. Otherwise, we loose compatibility 
and
// might not be able to correctly retrieve sites that redirect.
if (m_request.responseCode == 301) { // Moved permanently
setMetaData(QLatin1String(permanent-redirect), 
QLatin1String(true));
if (m_request.method == HTTP_POST) {
m_request.method = HTTP_GET; // FORCE a GET
setMetaData(QLatin1String(redirect-to-get), 
QLatin1String(true));
}
} else if (m_request.responseCode == 302) { // Moved temporarily
if (m_request.method == HTTP_POST) {
m_request.method = HTTP_GET; // FORCE a GET
setMetaData(QLatin1String(redirect-to-get), 
QLatin1String(true));
}
} else { // 303 See Other
if (m_request.method != HTTP_HEAD) {
m_request.method = HTTP_GET; // FORCE a GET
setMetaData(QLatin1String(redirect-to-get), 
QLatin1String(true));
}
}
}

...or something like that.

- Andrea Iacovitti


On Feb. 11, 2014, 10:28 a.m., Dawit Alemayehu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115651/
 ---
 
 (Updated Feb. 11, 2014, 10:28 a.m.)
 
 
 Review request for kdelibs, Andreas Hartmetz and David Faure.
 
 
 Bugs: 330795
 http://bugs.kde.org/show_bug.cgi?id=330795
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 The attached patch fixes how we handle HTTP redirection. Currently KIO does 
 not correctly handle a 303 See Other response. Instead of converting the 
 redirection request to a GET operation as specified in the RFC, KIO simply 
 repeats the same operation with the redirect URL. Additionally, KIO does not 
 handle redirection of a delete operation that is handled internally.
 
 
 Diffs
 -
 
   kio/DESIGN.metadata 1351119 
   kio/kio/accessmanager.cpp 7a806e8 
   kio/kio/job.cpp 13107c2 
   kioslave/http/http.cpp b13eed1 
 
 Diff: https://git.reviewboard.kde.org/r/115651/diff/
 
 
 Testing
 ---
 
 Run tests at
 
 http://greenbytes.de/tech/tc/httpredirects/t301methods.html
 http://greenbytes.de/tech/tc/httpredirects/t302methods.html
 http://greenbytes.de/tech/tc/httpredirects/t303methods.html
 
 
 Thanks,
 
 Dawit Alemayehu
 




Re: Review Request 115689: Fix khtml/ecma/xmlhttprequest.cpp to properly handle HEAD requests

2014-02-12 Thread Andrea Iacovitti

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115689/#review49671
---

Ship it!


Looks good from my side.

I added some comments in https://git.reviewboard.kde.org/r/115651 about 
http.cpp's changes.

- Andrea Iacovitti


On Feb. 12, 2014, 9:56 a.m., Dawit Alemayehu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115689/
 ---
 
 (Updated Feb. 12, 2014, 9:56 a.m.)
 
 
 Review request for kdelibs and Andrea Iacovitti.
 
 
 Bugs: 331007
 http://bugs.kde.org/show_bug.cgi?id=331007
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 Fix khtml/ecma/xmlttprequest.cpp such that it correctly handles HEAD requests 
 without a noticable delay, i.e. use KIO::mimeType instead of KIO::get. 
 Otherwise, the request will wait for the content which is not returned when 
 doing a stat operation like HEAD.
 
 
 Diffs
 -
 
   khtml/ecma/xmlhttprequest.cpp b3707e7 
   kio/DESIGN.metadata 1351119 
   kio/kio/accessmanager.cpp 7a806e8 
   kio/kio/job.cpp 13107c2 
   kioslave/http/http.cpp b13eed1 
 
 Diff: https://git.reviewboard.kde.org/r/115689/diff/
 
 
 Testing
 ---
 
 Tested HEAD redirection with http://greenbytes.de/tech/tc/httpredirects/
 
 
 Thanks,
 
 Dawit Alemayehu
 




Re: Moving Milou to Extragear

2014-02-12 Thread Albert Astals Cid
El Dimarts, 11 de febrer de 2014, a les 11:55:01, Vishesh Handa va escriure:
 Hello people
 
 I've been developing Milou for quite some time now and I think it would be
 best to move it into extragear so that a release can be made sometime after
 the 4.13 release.
 
 Milou is a dedicated search plasmoid for Baloo. Here is a nice screenshot
 [1]. It also supports previews for certain file types, specially emails.
 
 It implements its own form of runners called sources. The main source is
 the Baloo source along with one for applications. On moving to KF5 its
 concept of sources will be dropped and it will directly use the runners.
 The needed features will be added to the krunner framework.
 
 I could really use a review for the QML code, hence the plasma-devel cc.

Why some i18n calls have a space at the end?

I'd also say that your catalog isn't getting loaded (i.e. your catalog name is 
wrong).

Cheers,
  Albert


Re: Moving Milou to Extragear

2014-02-12 Thread Albert Astals Cid
El Dimarts, 11 de febrer de 2014, a les 11:55:01, Vishesh Handa va escriure:
 Hello people
 
 I've been developing Milou for quite some time now and I think it would be
 best to move it into extragear so that a release can be made sometime after
 the 4.13 release.
 
 Milou is a dedicated search plasmoid for Baloo. Here is a nice screenshot
 [1]. It also supports previews for certain file types, specially emails.
 
 It implements its own form of runners called sources. The main source is
 the Baloo source along with one for applications. On moving to KF5 its
 concept of sources will be dropped and it will directly use the runners.
 The needed features will be added to the krunner framework.
 
 I could really use a review for the QML code, hence the plasma-devel cc.

Also you can optimize
  qDeleteAll(m_mapping.values());
to
  qDeleteAll(m_mapping);

Cheers,
  Albert


Re: KDE Review: Move LabPlot to extragear.

2014-02-12 Thread Albert Astals Cid
El Dimarts, 11 de febrer de 2014, a les 21:32:29, Alexander Semke va escriure:
 Hi all,
 
 couple of days ago LabPlot-project [1] decided to move to KDE and to become
 a part of KDE Edu and to collaborate closer with people involved in other
 projects on KDE Edu [2]. After almost four years of development we had the
 first stable release shortly [3] and the first bug fix release.
 
 The repository is currently placed at [4]. Documentation is still missing
 and there're couple of issues reported by krazy (mostly related to i18n).
 We're already working on them.
 
 I would like to request a review of the project and to move, if accepted, to
 extragear.

Do you really need that embedded liborigin?

Cheers,
  Albert

 
 Best regards
 Alexander
 
 
 [1] http://labplot.sourceforge.net/
 [2] http://lists.kde.org/?l=kde-edum=138822352206203w=2
 [3] http://lists.kde.org/?l=kde-edum=139016959012000w=1 (release)
 [4] https://projects.kde.org/projects/kdereview/labplot



Re: KDE Review: Move LabPlot to extragear.

2014-02-12 Thread Albert Astals Cid
El Dimarts, 11 de febrer de 2014, a les 21:32:29, Alexander Semke va escriure:
 Hi all,
 
 couple of days ago LabPlot-project [1] decided to move to KDE and to become
 a part of KDE Edu and to collaborate closer with people involved in other
 projects on KDE Edu [2]. After almost four years of development we had the
 first stable release shortly [3] and the first bug fix release.
 
 The repository is currently placed at [4]. Documentation is still missing
 and there're couple of issues reported by krazy (mostly related to i18n).
 We're already working on them.
 
 I would like to request a review of the project and to move, if accepted, to
 extragear.

You have a few calls that are wrong like
i18n(X,plot designation)
What are you trying to do there?

Cheers,
  Albert

 
 Best regards
 Alexander
 
 
 [1] http://labplot.sourceforge.net/
 [2] http://lists.kde.org/?l=kde-edum=138822352206203w=2
 [3] http://lists.kde.org/?l=kde-edum=139016959012000w=1 (release)
 [4] https://projects.kde.org/projects/kdereview/labplot



Re: Review Request 115651: Fix HTTP redirection handling (3XX status code)

2014-02-12 Thread Rolf Eike Beer
Am Mittwoch, 12. Februar 2014, 17:10:49 schrieb Andrea Iacovitti:
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115651/#review49669
 ---
 
 
 As stated in the bug report it is also true that every other browsers
 rewrite POST method to GET when following 301/302 redirections. This
 behavior could also be verified in curl by issuing the following commands:
 curl -L --data fakepostdata
 http://greenbytes.de/tech/tc/httpredirects/redirect_with_status.cgi?301
 curl -L --data fakepostdata
 http://greenbytes.de/tech/tc/httpredirects/redirect_with_status.cgi?302 We
 could/should do the same for compatibility.
 In that case the snippet of code that handles 301-303 http status codes may
 assume this form:
 
 } else if (m_request.responseCode = 301  m_request.responseCode=
 303) { // NOTE: This is wrong according to RFC 2616 (section 10.3.[2-4,8]).
 // However, because almost all client implementations treat a 301/302 //
 response as a 303 response in violation of the spec, many servers // have
 simply adapted to this way of doing things! Thus, we are // forced to do
 the same thing. Otherwise, we loose compatibility and // might not be able
 to correctly retrieve sites that redirect. if (m_request.responseCode ==
 301) { // Moved permanently
 setMetaData(QLatin1String(permanent-redirect), QLatin1String(true)); if
 (m_request.method == HTTP_POST) {
 m_request.method = HTTP_GET; // FORCE a GET
 setMetaData(QLatin1String(redirect-to-get),
 QLatin1String(true)); }
 } else if (m_request.responseCode == 302) { // Moved temporarily
 if (m_request.method == HTTP_POST) {
 m_request.method = HTTP_GET; // FORCE a GET
 setMetaData(QLatin1String(redirect-to-get),
 QLatin1String(true)); }
 } else { // 303 See Other
 if (m_request.method != HTTP_HEAD) {
 m_request.method = HTTP_GET; // FORCE a GET
 setMetaData(QLatin1String(redirect-to-get),
 QLatin1String(true)); }
 }
 }
 
 ...or something like that.

switch () { … }

Eike

signature.asc
Description: This is a digitally signed message part.