Re: KColorEdit in extragear/graphics
On Mon, Feb 17, 2014 at 10:52 AM, Albert Astals Cid aa...@kde.org 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? 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? Sure, we should be able to do that. The vast majority of Subversion - Git migrations are now complete in any case. Cheers, Albert Thanks, Ben 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
KDM + ConsoleKit + Logind
Ahoys I was looking for some input on KDM+CK in a Logind world. When a system is using Logind I guess KDM+CK doesn't do much useful, so the question arose whether distributions with such a lineup should build without CK support. In short: If the rest of the system uses Logind, should KDM be built without CK support? Would building without CK support reduce user functionality, and if so aren't we then essentially requiring distributions that use KDM to continue using CK until Plasma Next comes along? (we are not communicating this very if this is the case). TIA HS
Re: KDM + ConsoleKit + Logind
Dne 17.2.2014 11:51, Harald Sitter napsal(a): Ahoys I was looking for some input on KDM+CK in a Logind world. When a system is using Logind I guess KDM+CK doesn't do much useful, so the question arose whether distributions with such a lineup should build without CK support. In short: If the rest of the system uses Logind, should KDM be built without CK support? Would building without CK support reduce user functionality, and if so aren't we then essentially requiring distributions that use KDM to continue using CK until Plasma Next comes along? (we are not communicating this very if this is the case). TIA HS Hi, I'm not entirely sure about kdm but for the rest of the code in kde-workspace (kworkspace, powerdevil et co.), login1 support is fairly complete and preferred over CK. (cc'ng Martin who works on login managers) -- Lukáš Tinkl lti...@redhat.com Software Engineer - KDE desktop team, Brno KDE developer lu...@kde.org Red Hat Inc. http://cz.redhat.com
Re: Moving Milou to Extragear
Dne 14.2.2014 15:49, Burkhard Lück napsal(a): Am Freitag, 14. Februar 2014, 13:09:19 schrieb Vishesh Handa: On Thursday, February 13, 2014 11:28:40 AM Burkhard Lück wrote: That loads the translation catalog, which also contains messages from the plasmoid outside the library. Apparently that happens early enough at runtime (at least I see the catalog is loaded running milou in plasmoidviewer in locale x-test), so even messages used only in the plasmoid are translated. Your plasmoid tries to load a catalog named plasma_applet_milou_applet via plasmoid/applet.h:60:K_EXPORT_PLASMA_APPLET(milou_applet, Applet), but you extract to milou, so this catalog does not exist. But then the milou catalog would be loaded so the translations should be there, right? If not, what would be the correct way of fixing this? One option which I can think of is extracting the translations to plasma_applet_milou_applet, and updating the KCatalogLoader in the case the library is used without the applet. This does not make sense to me. Use two messages catalogs, one for the plasmoid named plasma_applet_milou_applet and loaded via K_EXPORT_PLASMA_APPLET and the second one for the library named e.g. libmilou and loaded via KCatalogLoader. BTW, this approach will not work if you switch away from a C++ applet to a pure QML one in the future, just saying... Btw the fixes from Lukáš Tinkl for the preview plugins are useless, because the plugins are part of the library, which loads its catalog already via KCatalogLoader. How are the plugins part of the library? They are separate plugins and I thought they might actually be used as such (e.g. in Dolphin) but I might be wrong of course... -- Lukáš Tinkl lti...@redhat.com Software Engineer - KDE desktop team, Brno KDE developer lu...@kde.org Red Hat Inc. http://cz.redhat.com
Re: KDM + ConsoleKit + Logind
2014-02-17 13:55 GMT+01:00 Lukáš Tinkl lti...@redhat.com: Dne 17.2.2014 11:51, Harald Sitter napsal(a): Ahoys I was looking for some input on KDM+CK in a Logind world. When a system is using Logind I guess KDM+CK doesn't do much useful, so the question arose whether distributions with such a lineup should build without CK support. In short: If the rest of the system uses Logind, should KDM be built without CK support? Would building without CK support reduce user functionality, and if so aren't we then essentially requiring distributions that use KDM to continue using CK until Plasma Next comes along? (we are not communicating this very if this is the case). Hi, I'm not entirely sure about kdm but for the rest of the code in kde-workspace (kworkspace, powerdevil et co.), login1 support is fairly complete and preferred over CK. We are using a KDE 4.11 systemd running on pure logind in Tanglu without any reported issues. KDM has multiseat patches applied, which were taken from[1]. We also adjusted some other dependencies, but that was just minor work on the packaging. So yes, you can use KDM with logind, but I am not sure that using it at all will make sense long-term, since KDM is dead now. Cheers, Matthias [1]: https://git.reviewboard.kde.org/r/112294/diff/
Re: KDM + ConsoleKit + Logind
On Mon, Feb 17, 2014 at 2:09 PM, Matthias Klumpp matth...@tenstral.net wrote: 2014-02-17 13:55 GMT+01:00 Lukáš Tinkl lti...@redhat.com: Dne 17.2.2014 11:51, Harald Sitter napsal(a): Ahoys I was looking for some input on KDM+CK in a Logind world. When a system is using Logind I guess KDM+CK doesn't do much useful, so the question arose whether distributions with such a lineup should build without CK support. In short: If the rest of the system uses Logind, should KDM be built without CK support? Would building without CK support reduce user functionality, and if so aren't we then essentially requiring distributions that use KDM to continue using CK until Plasma Next comes along? (we are not communicating this very if this is the case). Hi, I'm not entirely sure about kdm but for the rest of the code in kde-workspace (kworkspace, powerdevil et co.), login1 support is fairly complete and preferred over CK. We are using a KDE 4.11 systemd running on pure logind in Tanglu without any reported issues. KDM has multiseat patches applied, which were taken from[1]. We also adjusted some other dependencies, but that was just minor work on the packaging. So yes, you can use KDM with logind, but I am not sure that using it at all will make sense long-term, since KDM is dead now. Right, but short of patching KDM to gain proper logind support, should one build with or without CK, i.e. does CK add anything useful if the rest of the system is not using it anyway? I mean, it's a crappy situation either way. The DM we ship with our workspace is not maintained and suggests usage of CK while the rest of the workspace really wants logind, so, not the most consistent requirement set to begin with. HS
Re: Review Request 115726: Deafult for not executing kwalletmanager once a wallet is open
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115726/#review50061 --- Ship it! - David Edmundson On Feb. 13, 2014, 5:13 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115726/ --- (Updated Feb. 13, 2014, 5:13 p.m.) Review request for KDE Runtime, kde-workspace and Plasma. Repository: kde-runtime Description --- Given that in 4.13 we want people to use pam to open the wallet it makes little sense to execute the wallet automatically. Other commits changing the default have been pushed to kwallet and kwalletmanager This review goes together with: https://git.reviewboard.kde.org/r/115727/ https://git.reviewboard.kde.org/r/115728/ Diffs - kwalletd/CMakeLists.txt 9c5ca92 kwalletd/kwallet-4.13.upd PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115726/diff/ Testing --- Thanks, Àlex Fiestas
Re: Review Request 115728: Deafult for not executing kwalletmanager once a wallet is open
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115728/ --- (Updated Feb. 17, 2014, 4:24 p.m.) Status -- This change has been marked as submitted. Review request for KDE Runtime, kde-workspace and Plasma. Repository: kwalletmanager Description --- Given that in 4.13 we want people to use pam to open the wallet it makes little sense to execute the wallet automatically. Other commits changing the default have been pushed to runtime and kwallet Diffs - src/konfigurator/konfigurator.cpp b9f6edb src/manager/kwalletmanager.cpp 355fda7 Diff: https://git.reviewboard.kde.org/r/115728/diff/ Testing --- Thanks, Àlex Fiestas
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/#review50079 --- This review has been submitted with commit 24d780debd65e5c2e957a0ab3dd1ba5b9885a42b by Dawit Alemayehu to branch KDE/4.12. - Commit Hook 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: 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. 17, 2014, 5:29 p.m.) Status -- This change has been marked as submitted. 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 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)! kdeuser56 kdeuser56 wrote: Thomas: Would you mind shipping it for me? I'd have to setup a frameworks build first. I'll push it then if that didn't happen otherwise, but Frank might want to push it before. - Thomas --- 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
Re: KDM + ConsoleKit + Logind
Harald Sitter wrote: Right, but short of patching KDM to gain proper logind support, should one build with or without CK, build without it. i.e. does CK add anything useful if the rest of the system is not using it anyway no. As I understand it, this is the only case where you'd want to consider keeping CK support, if you had apps that still used the CK-api to check for active sessions. -- Rex
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)! kdeuser56 kdeuser56 wrote: Thomas: Would you mind shipping it for me? Thomas Lübking wrote: I'd have to setup a frameworks build first. I'll push it then if that didn't happen otherwise, but Frank might want to push it before. Frank might want to push it before: To be honest, I'd prefer if you could ask someone else to do it. I do update and build a subset of Qt5+frameworks occasionally, but I only worked on a few low-level things so far, and I never built or used anything that could show a properties dialog. I don't feel comfortable pushing commits in code that I never worked with without testing first, and I will be unable to do it in the near future. Sorry about that. - Frank --- 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
