Re: Review Request 115408: Fix alignment for mime icon in kpropertiesdialog
On Feb. 8, 2014, 2:34 p.m., Thomas Lübking wrote: Here's my vote then. Unless there's concern, push it in some days™ (ie. tuesday or so, should leave enough time to cry out) kdeuser56 kdeuser56 wrote: push it sounds like I should push it, however I can't do it, as I do not have a dev account. Could you push it for me? Pushing in frameworks/kio would also be nice (diff can be found here: http://pastebin.kde.org/p7eahjnoq)! Thomas: Would you mind shipping it for me? - kdeuser56 --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/#review49252 --- On Feb. 8, 2014, 10:02 a.m., kdeuser56 kdeuser56 wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/ --- (Updated Feb. 8, 2014, 10:02 a.m.) Review request for kdelibs and Frank Reininghaus. Repository: kdelibs Description --- The iconbutton and the iconlabel were clearly aligned using the old style, when everything was left aligned. In my interpretation of the KDE HIG guidelines, the iconbutton/label should also be right aligned. Especially with bigger font sizes, the visual issue becomes obvious. Idea: see kproperties-dolphin-1.png Before: see before-1.png and before-2.png After: see after-1.png and after-2.png Diff for kio (frameworks) can be found here: http://pastebin.kde.org/p4ojv6a1w Diffs - kio/kfile/kpropertiesdialog.cpp 6611ee7 Diff: https://git.reviewboard.kde.org/r/115408/diff/ Testing --- Compiled and installed. Works as expected. File Attachments idea https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/91648ead-a248-4c42-b45c-8741d1291955__kproperties-dolphin-1.png before1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/f9b5bba2-f810-4de5-b292-da66e0cf60ac__before-1.png before2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/516dbfec-597f-4f95-bb83-797d10ddebfc__before-2.png after1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/03fdb43f-6f67-407f-be27-e6afad906340__after-1.png after2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/06455bef-a229-4a1a-b9c0-cb1de61f7fa0__after-2.png center-center https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/ab93b637-e914-4521-a9c5-025515c97790__widget-center-icon-center.png left-left https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/38cd56fb-c411-4876-bebe-bc9923855751__widget-left-icon-leftunpatched.png right-center https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/80672290-b6fb-4fe3-b2ab-5ea5f0c6ed53__widget-right-icon-center.png right-right https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/8dec5429-021a-49a0-a34f-1a2e77d7aeef__widget-right-icon-right.png Thanks, kdeuser56 kdeuser56
KColorEdit in extragear/graphics
Hi, Why is the kcoloredit history lost when moving from svn to git? And why has the documentation not been moved accordingly? Cheers, Albert
Re: Review Request 101343: remove functions *Command::name() which are not used
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/101343/#review49935 --- Alexander, did you see David's comment? Do you plan to implement what he suggests? - Albert Astals Cid On May 12, 2011, 6:55 a.m., Alexander Potashev wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/101343/ --- (Updated May 12, 2011, 6:55 a.m.) Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- konq-plugins/domtreeviewer builds without there functions. May be these functions were left for future integration of domtreeviewer undoable commands' into Konqueror's undo stack. But for now, they only add a few translatable strings the user won't ever see. Diffs - konq-plugins/domtreeviewer/domtreecommands.h df8272e konq-plugins/domtreeviewer/domtreecommands.cpp e4c7fff Diff: https://git.reviewboard.kde.org/r/101343/diff/ Testing --- konq-plugins/domtreeviewer compiles after this change. Thanks, Alexander Potashev
Re: Review Request 115689: Fix khtml/ecma/xmlhttprequest.cpp to properly handle HEAD requests
On Feb. 16, 2014, 12:38 a.m., Andrea Iacovitti wrote: khtml/ecma/xmlhttprequest.cpp, line 512 https://git.reviewboard.kde.org/r/115689/diff/2/?file=244040#file244040line512 This does not seems to fix the POST-POST redirection with no content on 307 response issue, instead it has the side effect that POST method is rewritten to GET in 307 redirection.Also it doesn't make possible to do an XHR PUT request with content (!_body.isEmpty()) as actually a POST request is sent to the origin server and not a PUT. We use KIO::http_post (regardless of method) whenever we need to send a request that includes content, even for methods that do not have a defined semantics for entity-body (e.g. DELETE). So setting custom method it's always needed. The reason a POST method is rewritten to GET in a 307 redirection has to do with how we originally chose to deal with POST redirection in KIO::TransferJob. Right now all POST redirections are converted to GET regardless of the HTTP status code in TransferJob::slotFinished in job.cpp. See the CMD_SPECIAL section of the switch statement in that function. As far as then issue with the PUT request and an entity-body, kio_http was designed only to send the entity-body to the server for POST and other webdav requests. Anything that is done to skirt around that to me is a hack by definition. What would be the purpose of allowing entity-body for methods that are not supposed to have such thing, e.g. DELETE? Anyhow, I do not want to cause regression ; so I will roll back this patch to the way things were. However, those POST-POST redirection tests it seems to pass are wrong because it never sends the entity-body to the redirected resource. - Dawit --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115689/#review49889 --- On Feb. 14, 2014, 4 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115689/ --- (Updated Feb. 14, 2014, 4 p.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/kio/job.cpp abb3dfd Diff: https://git.reviewboard.kde.org/r/115689/diff/ Testing --- Tested HEAD redirection with http://greenbytes.de/tech/tc/httpredirects/ Thanks, Dawit Alemayehu
Re: Review Request 115689: Fix khtml/ecma/xmlhttprequest.cpp to properly handle HEAD requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115689/ --- (Updated Feb. 16, 2014, 7:10 p.m.) Review request for kdelibs and Andrea Iacovitti. Changes --- Always send the CustomHTTPmethod meta data. 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/kio/job.cpp abb3dfd Diff: https://git.reviewboard.kde.org/r/115689/diff/ Testing --- Tested HEAD redirection with http://greenbytes.de/tech/tc/httpredirects/ Thanks, Dawit Alemayehu
Re: KColorEdit in extragear/graphics
On Mon, Feb 17, 2014 at 5:44 AM, Albert Astals Cid aa...@kde.org wrote: Hi, Hi Albert, Why is the kcoloredit history lost when moving from svn to git? And why has the documentation not been moved accordingly? Sysadmin doesn't perform migrations of history - it is up to the individual developer(s) responsible for a project to do this. Percy, please produce a conversion which includes history and then ask in the ticket for the repository to be emptied so it can be repushed. Cheers, Albert Thanks, Ben
Re: Review Request 115689: Fix khtml/ecma/xmlhttprequest.cpp to properly handle HEAD requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115689/#review49994 --- Ship it! - Andrea Iacovitti On Feb. 16, 2014, 7:10 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115689/ --- (Updated Feb. 16, 2014, 7:10 p.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/kio/job.cpp abb3dfd Diff: https://git.reviewboard.kde.org/r/115689/diff/ Testing --- Tested HEAD redirection with http://greenbytes.de/tech/tc/httpredirects/ Thanks, Dawit Alemayehu
Re: KColorEdit in extragear/graphics
El Dilluns, 17 de febrer de 2014, a les 08:15:55, Ben Cooksley va escriure: On Mon, Feb 17, 2014 at 5:44 AM, Albert Astals Cid aa...@kde.org wrote: Hi, Hi Albert, Why is the kcoloredit history lost when moving from svn to git? And why has the documentation not been moved accordingly? Sysadmin doesn't perform migrations of history - it is up to the individual developer(s) responsible for a project to do this. Sure I know, but maybe you guys could add to the steps doing a basic git log to see stuff is not broken? Or maybe ask for migrations to be reviewed here or in some other place so we don't get stuff like this? Cheers, Albert Percy, please produce a conversion which includes history and then ask in the ticket for the repository to be emptied so it can be repushed. Cheers, Albert Thanks, Ben
Re: KColorEdit in extragear/graphics
Hi all On 16/02/14 16:52, Albert Astals Cid wrote: El Dilluns, 17 de febrer de 2014, a les 08:15:55, Ben Cooksley va escriure: On Mon, Feb 17, 2014 at 5:44 AM, Albert Astals Cid aa...@kde.org wrote: Hi, Hi Albert, Why is the kcoloredit history lost when moving from svn to git? And why has the documentation not been moved accordingly? Albert, thanks for notice this, I did the migration too quickly forgot this important step (commit history) currently I'm working to solve this, however I couldn't found a tutorial for migration from git to svn (I'm not too adept in git) Sysadmin doesn't perform migrations of history - it is up to the individual developer(s) responsible for a project to do this. Sure I know, but maybe you guys could add to the steps doing a basic git log to see stuff is not broken? Or maybe ask for migrations to be reviewed here or in some other place so we don't get stuff like this? Indeed, however I think I should consult to admin before doing the git-push, so I take responsibility for this and, as I say, I'm working to fix it right now. Any help or tip would be appreciated ;) Cheers, Albert Cheers, Percy Percy, please produce a conversion which includes history and then ask in the ticket for the repository to be emptied so it can be repushed. Cheers, Albert Thanks, Ben
Re: KColorEdit in extragear/graphics
On 16/02/14 17:00, Percy Camilo Triveño Aucahuasi wrote: Hi all On 16/02/14 16:52, Albert Astals Cid wrote: El Dilluns, 17 de febrer de 2014, a les 08:15:55, Ben Cooksley va escriure: On Mon, Feb 17, 2014 at 5:44 AM, Albert Astals Cid aa...@kde.org wrote: Hi, Hi Albert, Why is the kcoloredit history lost when moving from svn to git? And why has the documentation not been moved accordingly? Albert, thanks for notice this, I did the migration too quickly forgot this important step (commit history) currently I'm working to solve this, however I couldn't found a tutorial for migration from git to svn (I'm not too adept in git) Sysadmin doesn't perform migrations of history - it is up to the individual developer(s) responsible for a project to do this. Sure I know, but maybe you guys could add to the steps doing a basic git log to see stuff is not broken? Or maybe ask for migrations to be reviewed here or in some other place so we don't get stuff like this? Indeed, however I think I should consult to admin before doing the git-push, so I take responsibility for this and, as I say, I'm working to fix it right now. Any help or tip would be appreciated ;) Cheers, Albert Cheers, Percy Percy, please produce a conversion which includes history and then ask in the ticket for the repository to be emptied so it can be repushed. Cheers, Albert Thanks, Ben For the record: I've already created the kcoloredit rules and the svn2git script inside dewey (~/aucahuasi) and sent a post to the sysadmin ticket. Thanks, Percy
