Re: Review Request 120909: in kio_smb: Set inode/directory mimetype for folders
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120909/ --- (Updated jul. 11, 2015, 8:21 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and David Faure. Repository: kio-extras Description --- Set inode/directory mimetype for folders Diffs - smb/kio_smb_browse.cpp 67e2fa0 Diff: https://git.reviewboard.kde.org/r/120909/diff/ Testing --- Previously (kde4) KFileItem was doing an extra effort into figuring out the miemtype for remotes url but now it is not (at least not by default). Since we already know that the item is a directory we can set the mimetype already, saving roundtrips and making samba kioslave show folder icons again (and faster since we save a stat). Would be nice if somebody from frameworks (kio) could confirm that the situation regarding mimetypes in frameworks have changed. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121446: Ignore child mtp devices
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121446/ --- (Updated jul. 11, 2015, 8:38 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Solid. Repository: solid Description --- When an mtp device has child usb devices (for example when you plug an android phone with debugging), these childs usbs are mark as MTP but we can't really access them. According to the udev rules installed by libmtp, an alias devlink is added to the actual device, so this patch adds a filter for that. Diffs - src/solid/devices/backends/udev/udevmanager.cpp 39137ce Diff: https://git.reviewboard.kde.org/r/121446/diff/ Testing --- Tested with 3 different devices, 2 of them android with and withtout debug and it worked fine (plasma shows only 1 working mtp device instead of 3) Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121446: Ignore child mtp devices
On des. 11, 2014, 1:17 p.m., Aleix Pol Gonzalez wrote: +1 makes sense to me, less of a workaround as it used to be. ping? - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121446/#review71802 --- On des. 11, 2014, 1:05 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121446/ --- (Updated des. 11, 2014, 1:05 p.m.) Review request for KDE Frameworks and Solid. Repository: solid Description --- When an mtp device has child usb devices (for example when you plug an android phone with debugging), these childs usbs are mark as MTP but we can't really access them. According to the udev rules installed by libmtp, an alias devlink is added to the actual device, so this patch adds a filter for that. Diffs - src/solid/devices/backends/udev/udevmanager.cpp 39137ce Diff: https://git.reviewboard.kde.org/r/121446/diff/ Testing --- Tested with 3 different devices, 2 of them android with and withtout debug and it worked fine (plasma shows only 1 working mtp device instead of 3) Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123111: Only add a '/' if the url does not end with one
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123111/ --- (Updated May 5, 2015, 12:44 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit 6788bacc9f8eb593e67e3264177d49d45eb1ddf4 by Aleix Pol to branch master. Repository: frameworkintegration Description --- I could not figure out any other way of knowing if the path ends with '/' than calling toString so that is what I am doing. This patch adds a test with 3 different data that now behave correctly, before smb: and smb:// were failing. Diffs - autotests/CMakeLists.txt e8ed6a9 autotests/kdirselectdialog_unittest.cpp PRE-CREATION src/platformtheme/kdirselectdialog.cpp 9a4082a src/platformtheme/kdirselectdialog_p.h 8b5c77a Diff: https://git.reviewboard.kde.org/r/123111/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123101: Only add / to path if really necessary
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123101/ --- (Updated May 4, 2015, 3:13 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit 901871e7d4285afa4401d37fc7bb60956836a24e by Aleix Pol on behalf of Àlex Fiestas to branch master. Repository: kio Description --- This is really similar to https://git.reviewboard.kde.org/r/122613/ up to the point where if they happen to be exactly the same after the review I will move the code to where it can be shared. Diffs - autotests/kdiroperatortest.cpp add9fcf src/filewidgets/kdiroperator.cpp c014157 Diff: https://git.reviewboard.kde.org/r/123101/diff/ Testing --- Used it for 15min with kate and kdevelop, everything seems fine. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122613: Do not add an extra slash if item does not have a host (KUrlComboBoxPrivate::textForItem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/ --- (Updated March 22, 2015, 5:18 p.m.) Review request for KDE Frameworks. Changes --- Change code as suggested by David, also added test. Repository: kio Description --- The rest of kio internally is doing this correctly apparently it was only a problem in the GUI part of it. Diffs (updated) - autotests/kurlcomboboxtest.h PRE-CREATION autotests/kurlcomboboxtest.cpp PRE-CREATION src/widgets/kurlcombobox.cpp ed5b8a2 Diff: https://git.reviewboard.kde.org/r/122613/diff/ Testing --- Besides the added unit tests, I have used this patch while running a few ups, everything seems to work great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122613: Do not add an extra slash if item does not have a host (KUrlComboBoxPrivate::textForItem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/ --- (Updated March 22, 2015, 5:25 p.m.) Review request for KDE Frameworks. Repository: kio Description --- The rest of kio internally is doing this correctly apparently it was only a problem in the GUI part of it. Diffs (updated) - autotests/CMakeLists.txt 69c8957 autotests/kurlcomboboxtest.h PRE-CREATION autotests/kurlcomboboxtest.cpp PRE-CREATION src/widgets/kurlcombobox.cpp ed5b8a2 Diff: https://git.reviewboard.kde.org/r/122613/diff/ Testing --- Besides the added unit tests, I have used this patch while running a few ups, everything seems to work great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123101: Only add / to path if really necessary
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123101/ --- Review request for KDE Frameworks. Repository: kio Description --- This is really similar to https://git.reviewboard.kde.org/r/122613/ up to the point where if they happen to be exactly the same after the review I will move the code to where it can be shared. Diffs - autotests/kdiroperatortest.cpp add9fcf src/filewidgets/kdiroperator.cpp c014157 Diff: https://git.reviewboard.kde.org/r/123101/diff/ Testing --- Used it for 15min with kate and kdevelop, everything seems fine. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122613: Do not add an extra slash if item does not have a host (KUrlComboBoxPrivate::textForItem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/ --- (Updated March 23, 2015, 12:34 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit f00990e3a5b7178d75278429c426fc9d953d49de by Àlex Fiestas to branch master. Repository: kio Description --- The rest of kio internally is doing this correctly apparently it was only a problem in the GUI part of it. Diffs - autotests/CMakeLists.txt 69c8957 autotests/kurlcomboboxtest.h PRE-CREATION autotests/kurlcomboboxtest.cpp PRE-CREATION src/widgets/kurlcombobox.cpp ed5b8a2 Diff: https://git.reviewboard.kde.org/r/122613/diff/ Testing --- Besides the added unit tests, I have used this patch while running a few ups, everything seems to work great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123111: Only add a '/' if the url does not end with one
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123111/ --- Review request for KDE Frameworks. Repository: frameworkintegration Description --- I could not figure out any other way of knowing if the path ends with '/' than calling toString so that is what I am doing. This patch adds a test with 3 different data that now behave correctly, before smb: and smb:// were failing. Diffs - autotests/CMakeLists.txt e8ed6a9 autotests/kdirselectdialog_unittest.cpp PRE-CREATION src/platformtheme/kdirselectdialog.cpp 9a4082a src/platformtheme/kdirselectdialog_p.h 8b5c77a Diff: https://git.reviewboard.kde.org/r/123111/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122613: Do not add an extra slash if item does not have a host (KUrlComboBoxPrivate::textForItem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/#review76712 --- Hey, anybody can review it? - Àlex Fiestas On feb. 18, 2015, 8:46 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/ --- (Updated feb. 18, 2015, 8:46 p.m.) Review request for KDE Frameworks. Repository: kio Description --- The rest of kio internally is doing this correctly apparently it was only a problem in the GUI part of it. Diffs - autotests/CMakeLists.txt f613c1a autotests/kurlcomboboxtest.h PRE-CREATION autotests/kurlcomboboxtest.cpp PRE-CREATION src/widgets/kurlcombobox.cpp ed5b8a2 Diff: https://git.reviewboard.kde.org/r/122613/diff/ Testing --- Besides the added unit tests, I have used this patch while running a few ups, everything seems to work great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122613: Do not add an extra slash if item does not have a host (KUrlComboBoxPrivate::textForItem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/ --- (Updated feb. 18, 2015, 8:46 p.m.) Review request for KDE Frameworks. Changes --- Fixed all the issues. Repository: kio Description --- The rest of kio internally is doing this correctly apparently it was only a problem in the GUI part of it. Diffs (updated) - autotests/CMakeLists.txt f613c1a autotests/kurlcomboboxtest.h PRE-CREATION autotests/kurlcomboboxtest.cpp PRE-CREATION src/widgets/kurlcombobox.cpp ed5b8a2 Diff: https://git.reviewboard.kde.org/r/122613/diff/ Testing --- Besides the added unit tests, I have used this patch while running a few ups, everything seems to work great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/ --- (Updated Feb. 17, 2015, 9:43 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kio Description --- If we know that the item is a dir, return directly the correct mimetype for directories. More info of why this is needed at: https://git.reviewboard.kde.org/r/120909/ Diffs - autotests/kfileitemtest.h 0ee7204 autotests/kfileitemtest.cpp 59c104e src/core/kfileitem.cpp 5894226 Diff: https://git.reviewboard.kde.org/r/121447/diff/ Testing --- Besides tests, tried smb kioslave and it worked great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122613: Do not add an extra slash if item does not have a host (KUrlComboBoxPrivate::textForItem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/ --- Review request for KDE Frameworks. Repository: kio Description --- The rest of kio internally is doing this correctly apparently it was only a problem in the GUI part of it. Diffs - autotests/CMakeLists.txt f613c1a autotests/kurlcomboboxtest.h PRE-CREATION autotests/kurlcomboboxtest.cpp PRE-CREATION src/widgets/kurlcombobox.cpp ed5b8a2 Diff: https://git.reviewboard.kde.org/r/122613/diff/ Testing --- Besides the added unit tests, I have used this patch while running a few ups, everything seems to work great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kio and scheme://
Review request to fix this!
https://git.reviewboard.kde.org/r/122613/
Thanks for the support guys!
On Sun, Nov 2, 2014 at 1:43 PM, Àlex Fiestas afies...@kde.org wrote:
Hi there
There are quite a few places where the following code is found:
if (!url.path().endsWith('/')) {
url.setPath(url.path() + '/');
}
Given an url like: 'scheme://' KUrl will return '/' as path while QUrl
returns
empty string.
This is making kio add a third slash to the url in many places (because of
code like the one pasted before).
As a result if you open dolphin and type smb://, it will be redirected to
smb:///.
Is this an intended behavior or should I start sending patches to prevent
this
from happening?
Also, even though technically the path of 'smb://' is empty, users are
used to
that format (specially given how popular htp:// is) so I would like to keep
supporting it.
Cheers!
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/ --- (Updated Feb. 15, 2015, 6:27 p.m.) Review request for KDE Frameworks. Changes --- Add tests for a case suggested by dfaure Repository: kio Description --- If we know that the item is a dir, return directly the correct mimetype for directories. More info of why this is needed at: https://git.reviewboard.kde.org/r/120909/ Diffs (updated) - autotests/kfileitemtest.h 0ee7204 autotests/kfileitemtest.cpp 59c104e src/core/kfileitem.cpp 5894226 Diff: https://git.reviewboard.kde.org/r/121447/diff/ Testing --- Besides tests, tried smb kioslave and it worked great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
On Feb. 9, 2015, 7:24 p.m., David Faure wrote: This should not be done if the slave has provided a UDS_MIME_TYPE. E.g. kio_smb sends mimetypes that derive from inode/directory, such as application/x-smb-server and application/x-smb-workgroup. If you think this works with the current patch, please prove it with a unittest :-) Àlex Fiestas wrote: I quite not get this message sorry :/ can you explain a bit more? Àlex Fiestas wrote: Mmm I think I get it now, will check it out (write the test) tomorrow. Added tests for the use case you suggest (I think) they pass without modification to the patch. The reason why they patch is that UDS_MIME_TYPE is used in the ctor of the private class, so the added code will not we called in that case since mimetype is already initialized. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/#review75730 --- On Feb. 15, 2015, 6:27 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/ --- (Updated Feb. 15, 2015, 6:27 p.m.) Review request for KDE Frameworks. Repository: kio Description --- If we know that the item is a dir, return directly the correct mimetype for directories. More info of why this is needed at: https://git.reviewboard.kde.org/r/120909/ Diffs - autotests/kfileitemtest.h 0ee7204 autotests/kfileitemtest.cpp 59c104e src/core/kfileitem.cpp 5894226 Diff: https://git.reviewboard.kde.org/r/121447/diff/ Testing --- Besides tests, tried smb kioslave and it worked great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/ --- (Updated feb. 9, 2015, 5:51 p.m.) Review request for KDE Frameworks. Repository: kio Description --- If we know that the item is a dir, return directly the correct mimetype for directories. More info of why this is needed at: https://git.reviewboard.kde.org/r/120909/ Diffs - autotests/kfileitemtest.h 0ee7204 autotests/kfileitemtest.cpp 59c104e src/core/kfileitem.cpp 5894226 Diff: https://git.reviewboard.kde.org/r/121447/diff/ Testing (updated) --- Besides tests, tried smb kioslave and it worked great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/ --- (Updated feb. 9, 2015, 5:45 p.m.) Review request for KDE Frameworks. Changes --- Add tests Repository: kio Description --- If we know that the item is a dir, return directly the correct mimetype for directories. More info of why this is needed at: https://git.reviewboard.kde.org/r/120909/ Diffs (updated) - autotests/kfileitemtest.h 0ee7204 autotests/kfileitemtest.cpp 59c104e src/core/kfileitem.cpp 5894226 Diff: https://git.reviewboard.kde.org/r/121447/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
On feb. 9, 2015, 7:24 p.m., David Faure wrote: This should not be done if the slave has provided a UDS_MIME_TYPE. E.g. kio_smb sends mimetypes that derive from inode/directory, such as application/x-smb-server and application/x-smb-workgroup. If you think this works with the current patch, please prove it with a unittest :-) I quite not get this message sorry :/ can you explain a bit more? - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/#review75730 --- On feb. 9, 2015, 5:51 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/ --- (Updated feb. 9, 2015, 5:51 p.m.) Review request for KDE Frameworks. Repository: kio Description --- If we know that the item is a dir, return directly the correct mimetype for directories. More info of why this is needed at: https://git.reviewboard.kde.org/r/120909/ Diffs - autotests/kfileitemtest.h 0ee7204 autotests/kfileitemtest.cpp 59c104e src/core/kfileitem.cpp 5894226 Diff: https://git.reviewboard.kde.org/r/121447/diff/ Testing --- Besides tests, tried smb kioslave and it worked great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
On feb. 9, 2015, 7:24 p.m., David Faure wrote: This should not be done if the slave has provided a UDS_MIME_TYPE. E.g. kio_smb sends mimetypes that derive from inode/directory, such as application/x-smb-server and application/x-smb-workgroup. If you think this works with the current patch, please prove it with a unittest :-) Àlex Fiestas wrote: I quite not get this message sorry :/ can you explain a bit more? Mmm I think I get it now, will check it out (write the test) tomorrow. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/#review75730 --- On feb. 9, 2015, 5:51 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121447/ --- (Updated feb. 9, 2015, 5:51 p.m.) Review request for KDE Frameworks. Repository: kio Description --- If we know that the item is a dir, return directly the correct mimetype for directories. More info of why this is needed at: https://git.reviewboard.kde.org/r/120909/ Diffs - autotests/kfileitemtest.h 0ee7204 autotests/kfileitemtest.cpp 59c104e src/core/kfileitem.cpp 5894226 Diff: https://git.reviewboard.kde.org/r/121447/diff/ Testing --- Besides tests, tried smb kioslave and it worked great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Add your blog to the Qt planet
Hey! In the Randa sprint we discussed about how to promote all the awesome stuff we do better in the Qt community. One of the ideas we came up with was to add the blogs of our developers to the Qt planet. The process is like ours, so just clone the Qt repository www/planetqt and submit a code review at https://codereview.qt-project.org/#/admin/projects/www/planetqt I asked to the Qt community manager (in CC'd) and he said it was totally ok to add blogs of people for example working on plasma or applications. Basically anything cool done with Qt is ok! Cheers! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121927: Update XCursor settings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121927/#review73570 --- Ship it! There is test for this code in kdeplatformtheme_unittest.cpp, do you think it will be possible to test the fallback we have for then the size is -1? Alsot, maybe checking with XCursorGetTheme that the theme has been applied will be nice, so we make sure we won't loose this in possible future refactors of this code. Otherwise code looks good! - Àlex Fiestas On gen. 9, 2015, 9:18 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121927/ --- (Updated gen. 9, 2015, 9:18 a.m.) Review request for KDE Frameworks, Àlex Fiestas and Eike Hein. Repository: frameworkintegration Description --- Code taken and adjusted from KGlobalSettings. Diffs - src/platformtheme/khintssettings.cpp a477a1078f7d62294abfffc92a77889832b1e0db autotests/CMakeLists.txt 00337e775e4e2d3e2d1bb583f4102323f0e5973b src/platformtheme/CMakeLists.txt 8a3b1b43d617083730517fe8db0a1e2f543913ab Diff: https://git.reviewboard.kde.org/r/121927/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121927: Update XCursor settings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121927/#review73571 --- src/platformtheme/khintssettings.cpp https://git.reviewboard.kde.org/r/121927/#comment51222 Maybe move this platform specific code to a separate method so IFDEF is smaller? It will help if we need to add more ifdefs in the future. - Àlex Fiestas On gen. 9, 2015, 9:18 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121927/ --- (Updated gen. 9, 2015, 9:18 a.m.) Review request for KDE Frameworks, Àlex Fiestas and Eike Hein. Repository: frameworkintegration Description --- Code taken and adjusted from KGlobalSettings. Diffs - src/platformtheme/khintssettings.cpp a477a1078f7d62294abfffc92a77889832b1e0db autotests/CMakeLists.txt 00337e775e4e2d3e2d1bb583f4102323f0e5973b src/platformtheme/CMakeLists.txt 8a3b1b43d617083730517fe8db0a1e2f543913ab Diff: https://git.reviewboard.kde.org/r/121927/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121447: Return inode/directory when isDir returns true (kfileitem)
On des. 11, 2014, 2:27 p.m., Mark Gaiser wrote:
src/core/kfileitem.cpp, line 255
https://git.reviewboard.kde.org/r/121447/diff/1/?file=332652#file332652line255
-- add here
} else {
// Fix for IO slaves that don't set UDS_MIME_TYPE for a folder.
if (m_fileMode QT_STAT_MASK) == QT_STAT_DIR) {
m_entry.insert(KIO::UDSEntry::UDS_MIME_TYPE, inode/directory);
m_mimeType = db.mimeTypeForName(inode/directory);
m_bMimeTypeKnown = true;
}
}
Not tested! Just written in comment box :)
I think that's about all you'd need to fix this.
But if this is accaptable is probably up to David to decide.
I'm also not 100% sure that you catch all cases when readUDSEntry().
Emmanuel Pescosta wrote:
+1
I also think that this is better way to fix it.
Avoids code duplication and the correct mime type for folders is set a
early as possible, so other code can rely on it.
David Faure wrote:
This suggestion would break the case where m_guessedMimeType is set, so
it should at least that that one is empty too.
Anyhow, the orig patch is fine, since determineMimeType is only called
once. KFileItem already takes care of caching the result.
And you can see the cache (d-m_mimeType) in currentMimeType() too, so
the new code will also only run once.
There's no need to insert a UDS_MIME_TYPE entry. KFileItem's whole
purpose in life is to encapsulate all these details with a proper API, so as
long as it returns a correct mimetype everything's fine.
I do agree on one thing though: a small unittest in kfileitemtest would
be nice :)
Mark Gaiser wrote:
@David, Right, i missed that mimetype caching part which makes it a one
time call to determineMimeType. Still, it seems better to me to move it to an
initialization step since you nearly always need to know the mime type as
early as possible anyway + you only need to add code in one place (right?).
I guess the } else { ... like i said before would become an if right
after m_guessedMimeType is set:
if (m_guessedMimeType.isEmpty() m_fileMode QT_STAT_MASK) ==
QT_STAT_DIR) {
m_mimeType = db.mimeTypeForName(inode/directory);
m_bMimeTypeKnown = true;
}
I will add tests and update the patch, sorry for that.
- Àlex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121447/#review71804
---
On des. 11, 2014, 1:22 p.m., Àlex Fiestas wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121447/
---
(Updated des. 11, 2014, 1:22 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
If we know that the item is a dir, return directly the correct mimetype for
directories.
More info of why this is needed at:
https://git.reviewboard.kde.org/r/120909/
Diffs
-
src/core/kfileitem.cpp 6a2cfa5
Diff: https://git.reviewboard.kde.org/r/121447/diff/
Testing
---
Thanks,
Àlex Fiestas
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121536: Actually set the palette when it changes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121536/#review72102 --- Could we test this somehow? - Àlex Fiestas On des. 15, 2014, 5:10 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121536/ --- (Updated des. 15, 2014, 5:10 p.m.) Review request for KDE Frameworks. Repository: frameworkintegration Description --- Actually set the palette when it changes Simply emitting an event that the palette has changed has absolutely no effect as QApplication keeps a cache of the palette, we need to update that appropriately Diffs - src/platformtheme/khintssettings.cpp 8799216 Diff: https://git.reviewboard.kde.org/r/121536/diff/ Testing --- Opened systemsettings5 changed my colour scheme and had it work immediately. Breeze seems to have an issue updating tabview widgets on the fly but that's a separate issue. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121446: Ignore child mtp devices
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121446/ --- Review request for KDE Frameworks and Solid. Repository: solid Description --- When an mtp device has child usb devices (for example when you plug an android phone with debugging), these childs usbs are mark as MTP but we can't really access them. According to the udev rules installed by libmtp, an alias devlink is added to the actual device, so this patch adds a filter for that. Diffs - src/solid/devices/backends/udev/udevmanager.cpp 39137ce Diff: https://git.reviewboard.kde.org/r/121446/diff/ Testing --- Tested with 3 different devices, 2 of them android with and withtout debug and it worked fine (plasma shows only 1 working mtp device instead of 3) Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121090: Move kio-mtp to kio-extras
On Thursday 13 November 2014 17:55:15 David Faure wrote: On Nov. 12, 2014, 10:04 p.m., Àlex Fiestas wrote: I would move this perhaps to plasma-workspace since this slave is really important for nowadays usage of the desktop (android phones etc). Aleix Pol Gonzalez wrote: Well, there's important kio's as well in kio-extras. Question is, is it useful outside the workspace? Would a cross-platform application use it? It seems to me they would, I can see amarok requiring it even on windows or gnome. Jan Grulich wrote: To me it makes more sense to have it in kio-extras with the rest of kioslaves. plasma-workspace isn't about importance. It's about what constitutes the pure desktop (a place where to show windows from applications). Actual functionality that would also work in other desktops and OSes (like dolphin, like kioslaves, and so on) belongs to Applications. kio-extras being under kde/workspace right now is really a bug, that I've been pleading against since day one. Please please move it out of there, it's nonsense for it to be there. kioslaves work in other environments. You are right. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121095: FrameworkIntegration: Add KTextToHTML emoticons support to FrameworkIntegrationPlugin
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121095/#review70302 --- Since this seems quite easy to test, I would like automated tests before this gets merged (we already have too much untested code in this framework) - Àlex Fiestas On nov. 11, 2014, 2:51 p.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121095/ --- (Updated nov. 11, 2014, 2:51 p.m.) Review request for KDE Frameworks, David Faure and Michael Pyne. Repository: frameworkintegration Description --- This patch is related to /r/121094, which moves KTextToHTML conversion utility from KPimUtils to KCoreAddons. Since KCoreAddons can't depend on KEmoticons needed for smileys conversion, I added the actual KEmoticons code here, to create a run-time dependency, similar to the KWidgetsAddons-KConfig dependency for KMessageBox. This patch refactors the FrameworkIntegrationPlugin a bit - I split the KMessageBox-specific code into a separate file, and added a new file with the KTextToHTMLEmoticonsInterface implementation, as we can't just keep stacking more and more classes into a single file :-) Diffs - CMakeLists.txt 3721bfa src/integrationplugin/CMakeLists.txt 3395368 src/integrationplugin/frameworkintegrationplugin.h 6dc6825 src/integrationplugin/frameworkintegrationplugin.cpp a45ba9d src/integrationplugin/kmessagebox.h PRE-CREATION src/integrationplugin/kmessagebox.cpp PRE-CREATION src/integrationplugin/ktexttohtml.h PRE-CREATION src/integrationplugin/ktexttohtml.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121095/diff/ Testing --- Tested with KTextToHTML code from /r/121094 in a QGuiApplication and it seems to work. Thanks, Daniel Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120909: in kio_smb: Set inode/directory mimetype for folders
On oct. 31, 2014, 8:52 a.m., David Faure wrote:
Hmm, not sure which change in KFileItem you're referring to. But maybe this
is the change from KMimeType (which used a mode_t argument) to QMimeType
(which doesn't). We could add some logic in KFileItem to preserve behavior
compat for kioslaves if you want.
Mark Gaiser wrote:
Just thinking out loud now..
KFileItem should know if an entry is a file or folder. It's being set in
UDS_FILE_TYPE and used in the isDir() function of KFileItem. That being said,
isn't the easiest fix for this to just add some logic to the iconName()
function in KFileItem that does something like this:
if (isDir()) {
return whatever-the-mime-type-of-a-folder-is;
}
?
I saw comments like this: // ## d-m_fileMode isn't used anymore (for remote
urls) in KFileItem.
So, should I try to patch kfileitem to take into account UDS_FILE_TYPE?
- Àlex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120909/#review69572
---
On oct. 30, 2014, 10:42 p.m., Àlex Fiestas wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120909/
---
(Updated oct. 30, 2014, 10:42 p.m.)
Review request for KDE Frameworks and David Faure.
Repository: kio-extras
Description
---
Set inode/directory mimetype for folders
Diffs
-
smb/kio_smb_browse.cpp 67e2fa0
Diff: https://git.reviewboard.kde.org/r/120909/diff/
Testing
---
Previously (kde4) KFileItem was doing an extra effort into figuring out the
miemtype for remotes url but now it is not (at least not by default).
Since we already know that the item is a directory we can set the mimetype
already, saving roundtrips and making samba kioslave show folder icons again
(and faster since we save a stat).
Would be nice if somebody from frameworks (kio) could confirm that the
situation regarding mimetypes in frameworks have changed.
Thanks,
Àlex Fiestas
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kio and scheme://
Hi there
There are quite a few places where the following code is found:
if (!url.path().endsWith('/')) {
url.setPath(url.path() + '/');
}
Given an url like: 'scheme://' KUrl will return '/' as path while QUrl returns
empty string.
This is making kio add a third slash to the url in many places (because of
code like the one pasted before).
As a result if you open dolphin and type smb://, it will be redirected to
smb:///.
Is this an intended behavior or should I start sending patches to prevent this
from happening?
Also, even though technically the path of 'smb://' is empty, users are used to
that format (specially given how popular htp:// is) so I would like to keep
supporting it.
Cheers!
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120909: in kio_smb: Set inode/directory mimetype for folders
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120909/ --- Review request for KDE Frameworks and David Faure. Repository: kio-extras Description --- Set inode/directory mimetype for folders Diffs - smb/kio_smb_browse.cpp 67e2fa0 Diff: https://git.reviewboard.kde.org/r/120909/diff/ Testing --- Previously (kde4) KFileItem was doing an extra effort into figuring out the miemtype for remotes url but now it is not (at least not by default). Since we already know that the item is a directory we can set the mimetype already, saving roundtrips and making samba kioslave show folder icons again (and faster since we save a stat). Would be nice if somebody from frameworks (kio) could confirm that the situation regarding mimetypes in frameworks have changed. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119505: Instance our onw QFileDialog instead of using getExistingDirectoryUrl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119505/ --- (Updated Oct. 23, 2014, 8 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kio Description --- getExistingDirectoryUrl only works for local files so we have to implement it on our own for now. As for Qt, QFileDialog::getExistingDirectoryUrl calls QUrl.toLocalFile, if we remove that, further down the code path _qt_get_directory is called which checks that the file exists but since Qt is not able to talk all our kios (for example smb) it will return false. So at the moment we are forced to implement it ourselves. Diffs - src/widgets/kurlrequester.cpp cf0b0c7 Diff: https://git.reviewboard.kde.org/r/119505/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120422: Fix build with Qt 5.4 - Implement SystemTrayMenuItem::setIconSize
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120422/#review67769 --- src/platformtheme/kdeplatformsystemtrayicon.cpp https://git.reviewboard.kde.org/r/120422/#comment47199 Remove src/platformtheme/kdeplatformsystemtrayicon.cpp https://git.reviewboard.kde.org/r/120422/#comment47198 Use Q_UNUSED better because this is going to get call many times from QMenu and on all of them, it is not really a warning. Also, add a comment saying that we don't do anything with the size of the icon. - Àlex Fiestas On set. 29, 2014, 1:32 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120422/ --- (Updated set. 29, 2014, 1:32 p.m.) Review request for KDE Frameworks. Repository: frameworkintegration Description --- Otherwise it's a pure virtual class. I'm unsure what should be done in this case though. If somebody knows I'll be happy to fix it. Diffs - src/platformtheme/kdeplatformsystemtrayicon.h 6ceaa43 src/platformtheme/kdeplatformsystemtrayicon.cpp 3ada7d2 Diff: https://git.reviewboard.kde.org/r/120422/diff/ Testing --- Builds. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120422: Fix build with Qt 5.4 - Implement SystemTrayMenuItem::setIconSize
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120422/#review67653 --- I could accept the patch, problem is that later on we might forget to fix this properly :/ Will check tomorrow what this new virtual is supposed to do and see what we can do about it. - Àlex Fiestas On set. 29, 2014, 1:32 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120422/ --- (Updated set. 29, 2014, 1:32 p.m.) Review request for KDE Frameworks. Repository: frameworkintegration Description --- Otherwise it's a pure virtual class. I'm unsure what should be done in this case though. If somebody knows I'll be happy to fix it. Diffs - src/platformtheme/kdeplatformsystemtrayicon.h 6ceaa43 src/platformtheme/kdeplatformsystemtrayicon.cpp 3ada7d2 Diff: https://git.reviewboard.kde.org/r/120422/diff/ Testing --- Builds. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
How to promote less mature Frameworks?
Hi there At the Randa sprint we have discussed a little bit what to do with those frameworks that are still not mature (for example they can't commit on ABI/API stability) but they are ready for feedback from third party developers. Even though there was not consensus in the discussion this is an idea that came out during the discussion: -We introduce a Maturity level that we can use to manage expectations about the Framework (for example whether API/ABI will be kept) -We release Frameworks that are not ready together with the rest, but we have to make damn sure we manage expectations. With this we can get early feedback for new frameworks, and since we have a rapid release cycle we can improve them fast. What do you think? Cheerzs. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
On Monday 11 August 2014 12:51:21 Milian Wolff wrote: a) what's the advantage of having a native widget style, compared to using QtCurve settings? Are there things missing / not implementable in QtCurve? We did some rought tests and QtCurve was wy slower than Oxygen (that at the same time was slower than Fusion). The test we did was re-painting widgets over and over with different styles and then measuring instructions and time iirc. Cheerz. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119505: Instance our onw QFileDialog instead of using getExistingDirectoryUrl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119505/ --- (Updated ago. 5, 2014, 10:01 p.m.) Review request for KDE Frameworks. Repository: kio Description --- getExistingDirectoryUrl only works for local files so we have to implement it on our own for now. As for Qt, QFileDialog::getExistingDirectoryUrl calls QUrl.toLocalFile, if we remove that, further down the code path _qt_get_directory is called which checks that the file exists but since Qt is not able to talk all our kios (for example smb) it will return false. So at the moment we are forced to implement it ourselves. Diffs (updated) - src/widgets/kurlrequester.cpp cf0b0c7 Diff: https://git.reviewboard.kde.org/r/119505/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119505: Instance our onw QFileDialog instead of using getExistingDirectoryUrl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119505/ --- (Updated ago. 3, 2014, 12:47 a.m.) Review request for KDE Frameworks. Repository: kio Description --- getExistingDirectoryUrl only works for local files so we have to implement it on our own for now. As for Qt, QFileDialog::getExistingDirectoryUrl calls QUrl.toLocalFile, if we remove that, further down the code path _qt_get_directory is called which checks that the file exists but since Qt is not able to talk all our kios (for example smb) it will return false. So at the moment we are forced to implement it ourselves. Diffs (updated) - src/widgets/kurlrequester.cpp f2837ad Diff: https://git.reviewboard.kde.org/r/119505/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119505: Instance our onw QFileDialog instead of using getExistingDirectoryUrl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119505/ --- Review request for KDE Frameworks. Repository: kio Description --- getExistingDirectoryUrl only works for local files so we have to implement it on our own for now. As for Qt, QFileDialog::getExistingDirectoryUrl calls QUrl.toLocalFile, if we remove that, further down the code path _qt_get_directory is called which checks that the file exists but since Qt is not able to talk all our kios (for example smb) it will return false. So at the moment we are forced to implement it ourselves. Diffs - src/widgets/kurlrequester.cpp cf0b0c7 Diff: https://git.reviewboard.kde.org/r/119505/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119011: KInit: call setgroups(0, 0) before calling setgid()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119011/#review61240 --- Ship it! We did a similar thing in kwallet pam module. - Àlex Fiestas On June 29, 2014, 10:50 a.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119011/ --- (Updated June 29, 2014, 10:50 a.m.) Review request for KDE Frameworks. Repository: kinit Description --- While packaging kinit, we got a warning from rpmlint that start_kdeinit calls setgid() without calling setgroups() first. From rpmlint: This executable is calling setuid and setgid without setgroups or initgroups. There is a high probability this mean it didn't relinquish all groups, and this would be a potential security issue to be fixed. Seek POS36-C on the web for details about the problem. The reasoning is that when you drop privileges from root to regular user, there might be some extra groups left that, if not cleared, might grant the process privileges to do superuser things. The code does not check for return value, as the call will fail if we are not a superuser. This oneliner makes rpmlint happy and maybe prevents a security issue. Diffs - src/start_kdeinit/start_kdeinit.c 07a28d3 Diff: https://git.reviewboard.kde.org/r/119011/diff/ Testing --- Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Solid situation for 5.0
On Monday 23 June 2014 19:29:19 Kevin Ottens wrote: What do you mean? Not releasing solid as part of 5.0? Not enabling the new async API? Not enabling the new api. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Solid situation for 5.0
As many of you know late in the game I started writing some new code to add much needed asynchronous api to Solid/Power which meant moving the old deprecate code to kdelibs4Support. The new API is done (you can review it on master, there are 2 CMake options to enable them) and all is left to do is to develop the UPower backend (which should be rather trivial). With so little time between now and the release I think it will be wise to delay until 5.1 (which happens in a ~month anyway) so we can have the entire July to review the api. At the moment, people porting over KF5 they can use kdelibs4Support and wait until 5.1 to move to the new async api. Does it sound good? Sorry for the mess. Cheers. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KCoreAddons does not install most of its headers on my system
On Mon, Jun 16, 2014 at 9:41 AM, Frank Reininghaus frank7...@googlemail.com wrote: Hello everyone, I tried to set up a separate Qt5+KF5 build in release mode. Unfortunately, I did not succeed :-( The first package that fails to build (even if I repeat the kdesrc-build process many times) is kservice. The comiler reports [ 30%] Building CXX object src/CMakeFiles/KF5Service.dir/services/kserviceaction.cpp.o In file included from /home/kde-frameworks-release/kde/src/frameworks/kservice/src/services/kmimetypetrader.h:23:0, from /home/kde-frameworks-release/kde/src/frameworks/kservice/src/services/kmimetypetrader.cpp:20: /home/kde-frameworks-release/kde/src/frameworks/kservice/src/services/kservice.h:27:28: fatal error: kpluginfactory.h: No such file or directory #include kpluginfactory.h ^ I then found that kpluginfactory should actually be installed by kcoreaddons, but that does not happen here. The install.log of kcoreaddons looks like this: # kdesrc-build running: 'gmake' 'install/fast' # from directory: /home/kde-frameworks-release/kde/build/frameworks/kcoreaddons Install the project... -- Install configuration: release -- Up-to-date: /home/kde-frameworks-release/kf5/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake -- Up-to-date: /home/kde-frameworks-release/kf5/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfigVersion.cmake -- Up-to-date: /home/kde-frameworks-release/kf5/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets.cmake -- Up-to-date: /home/kde-frameworks-release/kf5/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets-release.cmake -- Up-to-date: /home/kde-frameworks-release/kf5/include/KF5/kcoreaddons_version.h -- Up-to-date: /home/kde-frameworks-release/kf5/lib64/libKF5CoreAddons.so.4.100.0 -- Up-to-date: /home/kde-frameworks-release/kf5/lib64/libKF5CoreAddons.so.5 -- Up-to-date: /home/kde-frameworks-release/kf5/lib64/libKF5CoreAddons.so -- Up-to-date: /home/kde-frameworks-release/kf5/include/KF5/KCoreAddons/KAboutData -- Up-to-date: /home/kde-frameworks-release/kf5/include/KF5/KCoreAddons/kaboutdata.h -- Up-to-date: /home/kde-frameworks-release/kf5/include/KF5/KCoreAddons/kcoreaddons_export.h -- Up-to-date: /home/kde-frameworks-release/kf5/mkspecs/modules/qt_KCoreAddons.pri -- Up-to-date: /home/kde-frameworks-release/kf5/share/mime/packages/kde5.xml -- Updating MIME database at /home/kde-frameworks-release/kf5/share/mime It looks like it installs nothing that is in subdirectories of kcoreaddons/src/lib/. It still works nicely with my kde-frameworks user. The only change between both builds (except that one is based on a more recent Qt5 checkout) that I am aware of is that I replaced debug by release as the build type. I then reverted the debug-release change, cleared the kcoreaddons build directory and re-ran kdesrc-build, but it does not help. The CMake log does not look suspicious to me: http://paste.kde.org/p0ccahzhh I tried to understand the CMakeLists.txt, but I'm not really familiar with CMake and the ECM stuff, so I haven't found out what the problem is yet. Does anyone have an idea what I could do to investigate and possibly fix the problem? Thanks and best regards, Frank I encountered this yesterday, for a quick workaround rollback to cmake 3.0 (cmake-git is what makes this happen) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118234: [frameworksintegration] Ensure the xcb connection gets flushed before the event dispatcher blocks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118234/#review58445 --- src/platformtheme/CMakeLists.txt https://git.reviewboard.kde.org/r/118234/#comment40652 This workaround is quite important for 5.3.0 and older at least, maybe in those cases we should make it mandatory? - Àlex Fiestas On May 21, 2014, 6:18 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118234/ --- (Updated May 21, 2014, 6:18 a.m.) Review request for KDE Frameworks and Àlex Fiestas. Bugs: 334858 https://bugs.kde.org/show_bug.cgi?id=334858 Repository: frameworkintegration Description --- Ensure the xcb connection gets flushed before the event dispatcher blocks This is a workaround for Qt versions which do not yet have the change https://codereview.qt-project.org/85654 It is important to have this workaround as applications can get stalled when a framework uses xcb and doesn't flush the connection manually. BUG: 334858 Diffs - src/platformtheme/CMakeLists.txt da77cf816fe5f63e8eb9277d5d81d957b89c7966 src/platformtheme/config-platformtheme.h.cmake PRE-CREATION src/platformtheme/main.cpp 21d9aa0864e1887f5efbe4a05d264968af6e7e73 Diff: https://git.reviewboard.kde.org/r/118234/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting Minutes 2014~w21
Hello everybody, This is the minutes of the Week 21 KF5 meeting. As usual it has been held on #kde-devel at 4pm CEST time. Were present: sebas, notmart, tosky, mgraesslin, agateau, teo, alexmerry , PovAddict, teo and afiestas. mgraesslin: Trying to fix a problem in Qt5 with the low level usage of xcb/XLib. Patch can be found at: https://codereview.qt-project.org/#change,85654 Also, if the patch is not accepted or it is delayed we have to find a workaround, our QPT sounds ilke the best worse place. XFlush is not being called either, applications and frameworks using it shall call it themselves or port to xcb. agateau: Documented how l10n work in the wiki: https://community.kde.org/Frameworks/Frameworks_Localization_Policy Improved unittest for po handling in ecm Fixed a bg in string extration for qt-translated frameworks in l10n-kf5 Improving kgenapidox to make it easier for developers to generate their api teo: In talks and evaluating how HighDPI support will be handled in the future. alexmerry: Cleanups and reviews on his frameworks (done with kimageformats) Some RR for kdesignerplugin ervin: Spending time in the endless discussion of release cycle afiestas: Solid/Power api and upower backend. tosky: Bufgixes in kdoctools If you got questions, feel free to ask. Cheers! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
visibility compile flag
Hi there I'm porting libkscreen to Frameworks and I found that we are passing (when available) -fvisibility=hidden. After reading this[1] really quick I thought I would send an email here so people wiser than me can decide if it makes sense to enable it to all frameworks by default, it sounds useful. [1]: http://gcc.gnu.org/wiki/Visibility Cheers! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: visibility compile flag
On Tuesday 29 April 2014 09:21:44 Kevin Ottens wrote: Hello, On Monday 28 April 2014 19:50:51 Àlex Fiestas wrote: I'm porting libkscreen to Frameworks and I found that we are passing (when available) -fvisibility=hidden. After reading this[1] really quick I thought I would send an email here so people wiser than me can decide if it makes sense to enable it to all frameworks by default, it sounds useful. I'm confused... isn't it already the case? At least KDECompilerSettings.cmake has the following line: set(CMAKE_CXX_VISIBILITY_PRESET hidden) It should enable -fvisibility=hidden for all frameworks as they include that file. Or you meant something else? O I did check but apparently not enough :/ Nothing then! (more code that I can remove from kscreen cmake :p) Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 14, 2014, 12:18 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.h 2a29a15 src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. I'm all for dead code cemetery, but where is it? signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wednesday 09 April 2014 11:57:37 Marco Martin wrote: On Wednesday 09 April 2014, Àlex Fiestas wrote: I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. Not talking about that repo in particular, but... on the other hand, putting stuff in own micro repositories is as swiping under the carpet as leaving them in one of the main ones, if anything it ensures even more that it will go abandoned and unnoticed. If it's stuff that really nobody is even using and is safe to drop, that's ok (would be even ok to just delete it tough) but if is something that the user needs anyways and potentially causes regressions in the experience, it has to stay, and in the place that goes the least unnoticed. Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, then we will end up like in kde-workspace form KDE4 with a bunch of code nobody even knows what it does. We need to sort the house and do spring cleaning and this is our chance to do so. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
On April 7, 2014, 3:37 p.m., Kevin Ottens wrote: src/ioslaves/http/http.cpp, line 1900 https://git.reviewboard.kde.org/r/117333/diff/3/?file=262392#file262392line1900 What about doing it? :-) Àlex Fiestas wrote: I can do that but in another review if that is ok, this is blocking the merge of apiCleanup (solid) and I would like to do that asap. Kevin Ottens wrote: Then update ASAP. :-) To me it looks like the right point in time to fix it and that looks like a one liner even seeing what else you wrote. Oks, will do today. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/#review55175 --- On April 2, 2014, 2:40 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 2, 2014, 2:40 p.m.) Review request for KDE Frameworks. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 10, 2014, 12:08 p.m.) Review request for KDE Frameworks. Changes --- Implemented todo. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs (updated) - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.h 2a29a15 src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 10, 2014, 12:08 p.m.) Review request for KDE Frameworks. Changes --- Implemented todo. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.h 2a29a15 src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 13:43:37 Marco Martin wrote: On Thursday 10 April 2014, Àlex Fiestas wrote: Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, then we no, even that is the same problem (i did not explain enough), ie there are two cases: * it's not built and ported yet, likely noone will miss it * it's not built and ported yet, causes regressions in the first case, it can either be just killed or is fine the micro repo if someone steps up for maintainership in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. Thing is, in KDE4 it is broken, the model is all fucked up, some times it mounts the incorrect things or things that are already mounted (causing annoying dialogs) etc. So like I said in the sprint is it is something nice to have but it has to be maintained, fixed and polished and that won't happen before 2.0 and there is no reason to believe it will ever happen (since nobody at the sprint even knew what it was). signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 14:42:37 Marco Martin wrote: On Thursday 10 April 2014, you wrote: in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. one concrete thing that may be done is to do a (yet another) sweep of the things that are from workspace/runtime and being move around, like was done in the sprint, but do it in this mailinglist with more people interested involved. so, the central thing this time will be is it necessary or will it cause significant regressions In this way we can make sure no stuff that has still valid use case (yes, even if all of the people working in the framework hate such component, that's irrelevant :p) is left unported (like a good example is the automounter, i would never use such a thing ever, never the less that's irrelevant and is an important component of a base workspace for too many users, no matter how buggy or unmaintained is) Even though going offtopic I will use this thread to say my mind since it seems that your PoV diverges from mine. The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. This mess, this lack of quality is what makes KDE4 unpolished even after 6 years of development, we have plenty of features more than we can handle and we need to puts things in order. This video shows a bit of the things I feel: http://www.youtube.com/watch?v=CqY9l9qiFoA And this feeling is a constant while using kde4, some kde4 apps etc. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 08 April 2014 17:37:00 Kevin Ottens wrote: Good move. Pushed me toward looking a bit closer to this page, as obviously we didn't look close enough before (sorry about that), I might have a concern still: solid-deviceautomounter getting its own repository. It looks again like a completely leave behind or put in plasma-workspace (maybe not the kcm which is perhaps more plasma-desktop). With the uncertainty around it, I'd say its put in plasma-* until we got a replacement solution. I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Monday 07 April 2014 23:27:33 Alex Merry wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. The reason for the split is that they are not used, not maintained and they are not of general interest. Few examples: kiosalves of interest: sftp fish smb ... kioslaves not of interest: settings (allows you to use dolphin/konqueror as systemsettings) cgi (allows you to execute cgi without having a web server) finger I personally do not want to have those not of interest or unmaintained kiosalves around, I do not want to maintain them, I do not want distros to ship them by default (which will happen for those distros that will pacakge the entire repository) etc. Maybe we can move them to unmaintain (there is such place in our git repos I think) or something like that, but I really think that kio_cgi does not belong near smb. Cheers. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Status of the KDE Runtime module splitting
On Tuesday 08 April 2014 07:52:24 Kevin Ottens wrote: I agree there's one repository too many. But that's clearly workspace stuff to me. We discussed this a few weeks back and decided that we do not want those ioslaves in kde-workspace, we are not going to maintain them and we do not care of them, hence why we created the extra repo so they could go somewhere. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 08 April 2014 14:31:51 Alex Merry wrote: Well, I would say: discard them or include them. I know Albert was pushing not to get rid of code that still technically works, but I think you either have to go that route and put it in kioslaves/kio-extras/whatever (so that it will hopefully *keep* working), or declare it dead on the basis no-one cares enough to bother maintaining it. To a large extent, I would consider this the decision of whoever volunteers to maintain kio-extras (or whatever it gets called). So, any takers? we need a maintainer. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Cheers. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
On April 7, 2014, 3:37 p.m., Kevin Ottens wrote: src/ioslaves/http/http.cpp, line 1900 https://git.reviewboard.kde.org/r/117333/diff/3/?file=262392#file262392line1900 What about doing it? :-) I can do that but in another review if that is ok, this is blocking the merge of apiCleanup (solid) and I would like to do that asap. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/#review55175 --- On April 2, 2014, 2:40 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 2, 2014, 2:40 p.m.) Review request for KDE Frameworks. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: The kde-workspace split
This is what I added into the logical-module-structure:
kde/workspace/* : {
oldstable-qt4: ,
stable-qt4: ,
latest-qt4: ,
kf5-qt5: master
},
kde/workspace/kde-workspace : {
oldstable-qt4: KDE/4.11,
stable-qt4: KDE/4.11,
latest-qt4: KDE/4.11,
kf5-qt5:
},
Is it wrong?
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- Review request for KDE Frameworks. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 2, 2014, 12:49 p.m.) Review request for KDE Frameworks. Changes --- Removed some more references to Solid. In http.cpp I haven't replaced it with QNetworkConfigurationManager because it is not actually used and I rather do not break things. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs (updated) - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117332: Improve the KWindowSystemX11 Test
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117332/#review54875 --- Ship it! Looks good. - Àlex Fiestas On April 2, 2014, 12:32 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117332/ --- (Updated April 2, 2014, 12:32 p.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Improve the KWindowSystemX11 Test Extended the unit test to cover several signals emitted by the X11 implementation of KWindowSystem. Diffs - autotests/kwindowsystemx11test.cpp c9784b15755a45da499d0b2e660e75f32d3602e2 Diff: https://git.reviewboard.kde.org/r/117332/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 2, 2014, 2:40 p.m.) Review request for KDE Frameworks. Changes --- Forgot to remove one include :) Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs (updated) - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday 28 March 2014 11:30:25 Alex Merry wrote: In principle, I agree. In practice, a lot of our frameworks have a runtime dependency of some sort on it.[0] Alex [0]: http://lxr.kde.org/search?v=kf5-qt5_filestring=_string=kded5 I can't talk for other frameworks but in the case of Solid it is a mistake since it makes code that is cross-platform not cross-platform anymore. During the next week I will either remove that or make it platform specific (kde integration). signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Move KDED out of frameworks?
Hi there First of all sorry for sending this email so late in the release process, but today has been the first day in months that I have been able to work fully concentrated on Frameworks. KDED is a weird framework, while it is a solution it is still really tied to what was once known as KDE, just to mention a few things: -It always registers org.kde.kded5 in the bus, allowing only 1 instance -It plays a role in startkde startup sequence -It checks for KDE session for loading or not some modules -Manages sycoca freshness -Integrates with ksplash -... So for the moment I'd like to move KDED into kde-workspace (not into the repo but in the git structure) until we clean and remove all ties to KDE and make it more of a solution for any desktop. Since it does not install any header (kdbusaddons does it instead) we won't break anything with it. What do you think? Cheers. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Big changes for Solid
Hi there First of all I'm really sorry for doing this now just hours before Beta but honestly I have not been able to do it before. In Solid we have a bunch of public Interfaces which represent different kind of hardware, like Battery, Block or Processor. After 6 years (all KDE4) the adoption of many of these interface has been poor to the point where some interfaces have no users at all (in lxr) or only one app. Because of this we decided long ago to strip all these barely used interfaces since they add extra work for no real use. And that is what I have done. In the branch solid/apiCleaning you will find that I have removed some interfaces and because of how Solid it structured we can't really offer empty mock classes in kde4support. I have done 1 commit per each removed interface and I have explained in that commit who uses that interface + how to port it. Of course I will add documentation of how to port existing app to alternative apis (Qt and UDev mostly). I know that this kind of change is anything but welcomed at this stage but I really really do not want to maintain this for the entire KF5 series. Cheers and sorry for the mess. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Final kde-runtime splitting plan
On Tuesday 25 March 2014 20:00:51 Albert Astals Cid wrote: Can you give a rationale of why we're removing the following things? kfile4 kfile4 is only useful to test a library that is right now on kde4support. Maybe we can move it there if you want. kio_cgi Who needs to execute a cgi script without a web server? If you do then we can move it its own repo, I really don't want to see distributions shipping this kio in a package such of kioslaves-extras since it really doesn't offer anything useful for most of our user base. kio settings Browsing the settings in the file browser does not seem like a really convenient thing to have, and of course it adds more code to maintain. If you want to keep it that's fine but then please become maintainer and tell us where to move it (maybe kioslave-extra?). Cheers! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Final kde-runtime splitting plan
On Tuesday 25 March 2014 23:01:39 Luigi Toscano wrote: Why kreadconfig (which includes kreadconfig and kwriteconfig) is going to be in plasma-workspace? Isn't it useful for every KConfig-based component/application? Maybe kde cli tools could be the target... I thought there was another tool to do such things but apparently there are not, so yes we have to move kread/write config elsewhere. I wonder if a good place will be kconfig itself? they are useful tools for any kconfig user. Maintainer, any thoughts? signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Final kde-runtime splitting plan
Hi there Today Aleix and I are starting to split kde-runtime so we have gone through all the components again making sure that everything has a suitable destination. The result is this [1] wiki. Please, check that you are ok with the destination of each component and also check the things that have been targeted as **REMOVE** should be really removed (we believe so). Cheers ! [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Sprint from 24th of April until 28th
On Wednesday 19 February 2014 18:20:21 you wrote: We finally have a date for the sprint, next step is to know how many people need sponsoring, so please register yourself here: https://sprints.kde.org/sprint/224 I want to send the budget somewhere next week so please, hurry! Thanks ! Remember that you have to put as well your travel expenses (flight, train, bus...) so we can request the budget to the KDE e.V Thanks ! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Sprint from 24th of April until 28th
We finally have a date for the sprint, next step is to know how many people need sponsoring, so please register yourself here: https://sprints.kde.org/sprint/224 I want to send the budget somewhere next week so please, hurry! Thanks ! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Frameworks sprint in Barcelona
Hi there ! It is time we decide when to organize the Frameworks sprint, the main objective of this sprint is Making it releseable. The Doodle contains only Thursdays from May and April which is the day the sprint will start (and end on Sunday) http://doodle.com/n4r7xv3waigbcnv4 Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115251: Add better runtime detection for X11 usage in KStartupInfo
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115251/#review48141
---
Ship it!
The rest of the code is fine, +1 from me.
src/kstartupinfo.cpp
https://git.reviewboard.kde.org/r/115251/#comment34047
Mayube will be better do a return early here?
if (!X11Info::isPlatformX!!) {return} so we can avoid an extra indentation
on all that code?
- Àlex Fiestas
On Jan. 23, 2014, 10:06 a.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115251/
---
(Updated Jan. 23, 2014, 10:06 a.m.)
Review request for KDE Frameworks.
Repository: kwindowsystem
Description
---
Add better runtime detection for X11 usage in KStartupInfo
Compile time checks for X11 is no longer sufficient. This adds a
runtime check to all the code paths which look dangerous if executed
on a non-X11 platform.
Diffs
-
src/kstartupinfo.cpp 5dbf47cb666fbed17c943491efe93e17f27d581e
Diff: https://git.reviewboard.kde.org/r/115251/diff/
Testing
---
Thanks,
Martin Gräßlin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115249: Add runtime detection to KUserTimestamp
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115249/#review48140 --- Ship it! +1 - Àlex Fiestas On Jan. 23, 2014, 9:05 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115249/ --- (Updated Jan. 23, 2014, 9:05 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Add runtime detection to KUserTimestamp KUserTimestamp methods should only be used if we are on platformX11. A compile time check is not enough. Diffs - src/kusertimestamp.cpp de8ca61e7e9dd0ae9492ccf61883560d80501e2b Diff: https://git.reviewboard.kde.org/r/115249/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: TP1 release
On Sunday 05 January 2014 13:42:49 David Faure wrote: I made and uploaded the tarballs (and zips) for the TP1 release. Let's give the packagers a few days, and then we'll publish and announce the release. Meanwhile, no major changes in frameworks please, in case I need to redo tarballs. Bugfixes yes, but nothing that requires updating ECM, or that means changes across the board in all frameworks. \o/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forward includes
On Friday 27 December 2013 19:00:14 Aleix Pol wrote: Hi, I've been going through the kde4support forward includes, since I wanted to start making the modules I decided we'd better make sure all of them are working properly. After some research, I found that I don't have these available, can somebody please tell me if I'm missing some dependency or if these are indeed not available [1]? If there's no problem with this, I'll proceed to change these for a warning that they're not available anymore (see attachment). Cheers! Aleix PS: Happy holidays! I have checked a few of them manually and indeed the real header files do not exists. The approach in the patch seems correct, we don't want to add a source incompatible change by removing them, but I'd change the message from: #warning This file is not available anymore in KF5, please see http://community.kde.org/Frameworks/Porting_Notes Or something in this fashion so it is more useful. Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Do we want to have a meeting Tomorrow Tuesday?
I haven't seen that much action in Frameworks since it is kinda frozen and getting prepare for splitting. Do we still want to hold a meeting tomorrow? Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting 2013-w51 Reminder
Hi there ! Since nobody said anything against it, let's have the last meeting of the year, as always it will happen on #kde-devel today (Tuesday) at 4pm Barcelona (CET / UTC+1) time. If you want me to do any announcement today in the meeting just when the meeting starts either send it as a reply here, or contact me in any way. See you there. Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting 2013-w50 Reminder
Hi there ! Just a quick reminder: The next KF5 Update Meeting will happen on #kde-devel today (Tuesday) at 4pm Barcelona (CET / UTC+1) time. If you want me to do any announcement today in the meeting just when the meeting starts either send it as a reply here, or contact me in any way. See you there. Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting Minutes 2013-w50
These are the minutes of Week 50 KF5 meeting. As usual it has been held on #kde-devel at 4pm (CET / UTC+1) time. Present on the meeting: dMaggot, Sho_, markg85, d_ed, vHanda, teo- mck182, apol, agateau, mgrasslin, sebas, afiestas Announcements: -By popular demand Tuesday meeting is now KF5 only. -There is going to be a breakage before splitting, summary of the change: findings are now KF5Foo instead of KFoo (KF5Archive instead of KArchive) Linking is now KF5::Foo instead of KF5::KFoo (KF5::Archive instead of KF5::KArchive) Topics discussed: *mck182: Finished renaming of tier1/tier3 -It has been discussed how to proceed with the renaming, agateau will write some scripts to port most of the code using KF5 right now. *apol: Jhon Layt has gone AWOL and he has the KLocale API for KF5 on time formatting and byte size formatting working, no patches are known though. *agateau: Waiting for a final decision on the include prefix (http://mail.kde.org/pipermail/kde-frameworks-devel/2013-December/008523.html ) *agateau: Work on dependency diagrams (http://agateau.com/2013/12/05/kf5-diagrams/) *agateau: Working on integrating the diagrams with apidox *mgrasslin: Moved KGlobalAccel from XmlGui to tier1 *mgrasslin: Now looking in a KWindowSystem issue *sebas: Fixed a crash in Plasma Framework *afiestas: Fixed issues that appeared from the KStandardDir to QStandardPath porting Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114328: re-add customstyleelement suite to kstyle
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114328/#review45335 --- Ship it! Code looks good, you are the master of QStyle if you think those methods are useful, please ship it! - Àlex Fiestas On Dec. 6, 2013, 2:43 p.m., Hugo Pereira Da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114328/ --- (Updated Dec. 6, 2013, 2:43 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- re-add customstyleelement suite to kstyle Diffs - tier4/frameworkintegration/src/kstyle/kstyle.h 8a881f5 tier4/frameworkintegration/src/kstyle/kstyle.cpp 27d407e Diff: http://git.reviewboard.kde.org/r/114328/diff/ Testing --- compiles, works, fix kde-workspace build also: will be used when moving oxygen from qcommonstyle back to kstyle (right now we have a fork of some of the said methods) Thanks, Hugo Pereira Da Costa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting Minutes 2013-w49
These are the minutes of the Week 49 KF5 meeting. As usual it has been held on #kde-devel at 4pm (CET / UTC+1) time. Present on the meeting: vhanda, teo-, agateau, apol, dfaure, mck1982, shadeslayer, sebas, mgrasslin and afiestas, arichardson, PovAddict,randomguy3, General notes: Few people raised the concern that this is a frameworks meeting rather than plasma2/workspace, maybe we should have 2. Also, after the meeting it was discussed whether we should continue using qt5.git instead of qt-repo-tools. It seems like qt5.git continues to be the thing to use. Topics discussed: *teo-: screenlocker is up for adoption *agateau: Work on superbuild, some difficulties on setting it up in build.kde.org. Apol notes that maybe we want to move directly to the splitting. *randomguy3: Pushed changes making kimageformats separate from kguiaddons *apol: Ported some stuff to plasma2 hoping to find gaps in KF5 *apol: Started to work on making QFileDialog frameworks integration *scarpino: Available to do some work, kde-workspace/plasma taks suggested *mck182: all tier1 have libKF5* prefix now, found some issues with Config.cmake since target become KF5::KF5Target (instead of KF5::Target) *dfaure: Split script should be done: split_out_frameworks.sh which will split kdelibs.git in ../frameworks, also runs astyle. Then qtrepotools/bin/git-qt-grafts can be run to use git log. *dfaure: Working on remove the dependency from KLauncher to KRun. *afiestas: https://git.reviewboard.kde.org/r/114184/ waiting for final ship it. *afiestas: working on startkde, fixing things related to it (kinit module) *sebas: debugging plasma startup crash *sebas: enabled pager in default layout *sebas: made statusnotifier items in systray mostly work *sebas: more make-it-work stuff in the panel That's it, sorry for the delay on sending the minutes. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114184: Remove everything in kstyle that is not about KDE integration
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114184/ --- (Updated Dec. 5, 2013, 2:22 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Removed everything from KStyle that is NOT about integrating with KDE. Diffs - tier4/frameworkintegration/src/kstyle/kstyle.h 4c83509 tier4/frameworkintegration/src/kstyle/kstyle.cpp 626d2a9 Diff: http://git.reviewboard.kde.org/r/114184/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting 2013-w49 Reminder
Hi there ! Just a quick reminder: The next KF5 Update Meeting will happen on #kde-devel today (Tuesday) at 4pm Barcelona (CEST / UTC+2) time. If you want me to do any announcement today in the meeting just when the meeting starts either send it as a reply here, or contact me in any way. See you there. Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114184: Remove everything in kstyle that is not about KDE integration
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114184/ --- (Updated Nov. 29, 2013, 1:28 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Removed everything from KStyle that is NOT about integrating with KDE. Diffs (updated) - tier4/frameworkintegration/src/kstyle/kstyle.h 4c83509 tier4/frameworkintegration/src/kstyle/kstyle.cpp 626d2a9 Diff: http://git.reviewboard.kde.org/r/114184/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114184: Remove everything in kstyle that is not about KDE integration
On Nov. 29, 2013, 8:52 a.m., Kevin Ottens wrote: tier4/frameworkintegration/src/kstyle/kstyle.h, line 1518 http://git.reviewboard.kde.org/r/114184/diff/2/?file=220988#file220988line1518 If you use Q_DECL_OVERRIDE, no need to repeat the virtual (applies to most of the methods in here). I do like virtual, it is more syntax sugar and C++ developers are more use to it than to Q_DECL_OVERRIDE. I'd like to keep it but if you really want I can remove it. On Nov. 29, 2013, 8:52 a.m., Kevin Ottens wrote: tier4/frameworkintegration/src/kstyle/kstyle.h, line 1523 http://git.reviewboard.kde.org/r/114184/diff/2/?file=220988#file220988line1523 Hmmm, I don't get that one... Which warning did you get? Because of the QApplication and QPalette overloads? Yes On Nov. 29, 2013, 8:52 a.m., Kevin Ottens wrote: tier4/frameworkintegration/src/kstyle/kstyle.cpp, line 373 http://git.reviewboard.kde.org/r/114184/diff/2/?file=220989#file220989line373 Is it me or it's not needed anymore since the eventFilter method is gone? (not that it was doing anything meaningful previously). Even more so as you removed the removeEventFilter line from unpolish(). Yeah, I removed all of this but forgot this one :/ - Àlex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114184/#review44770 --- On Nov. 28, 2013, 6:20 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114184/ --- (Updated Nov. 28, 2013, 6:20 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Removed everything from KStyle that is NOT about integrating with KDE. Diffs - tier4/frameworkintegration/src/kstyle/kstyle.h 4c83509 tier4/frameworkintegration/src/kstyle/kstyle.cpp 626d2a9 Diff: http://git.reviewboard.kde.org/r/114184/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kded5 and kde-workspace
On Wednesday 20 November 2013 20:47:54 Àlex Fiestas wrote: Hey there Today I have been porting powerdevil and while doing it found out that kded5 was not loading any modules and many kde-workspace projects were using org.kde.kded instead of the one ended with .kded5 Tomorrow I'd like to push a local commit that changes all org.kde.kded for org.kde.kded5 (which we will have to change again but more about that in a later email), and will effectively make kde-workspace and plasma-framework depend on kded5. In order to make kded5 load modules, you have to have KDE_SESSION_VERSION set to 5, so add that to your set kde5 environment script. So please, adapt your environment asap, I'd like to push this tomorrow so we can do testing of the kf5 KDEDModules instead of kded4. Cheers ! Change pushed, please set KDE_SESSION_VERSION to 5 so we can get some testing to kded ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Reporting bugs against frameworks/plasma2
On Thursday 21 November 2013 16:34:28 Kevin Ottens wrote: Hello, On Thursday 21 November 2013 15:59:17 David Edmundson wrote: Long term, I disagree with using the version frameworks everywhere. Agreed... We want to have a split between Frameworks5.0 and Plasma2.0 and they may not be on the same release cycle. That said; you can rename a version in bugzilla with relative ease, and it will 'update' all existing reports. ... and that said it looks like a temporary measure. So likely this version name wouldn't be used anymore after the respective releases. It totally is, since we are using frameworks, and dogfooding plasma2 we need to report and keep tracks of the bugs somewhere if not we will loose them. Once splitting is done, we will split kdelibs product as well I guess. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kded5 and kde-workspace
On Thursday 21 November 2013 11:09:22 Daniel Nicoletti wrote: Funny this is the kind of thing that could just be avoided if projects stopped using the org.kde.kded DBus interface and instead registered their own. I for example don't need to do any change because I register org.kde.apperd interface so if tomorrow I decide to use a stand alone approach for the module it won't break everything calling it. Maybe it would be a good thing to do that for KDED modules on 5. Agreed, that's the plan and what I meant in: 2013/11/21 Àlex Fiestas afies...@kde.org: On Wednesday 20 November 2013 20:47:54 Àlex Fiestas wrote: org.kde.kded5 (which we will have to change again but more about that in a later email) Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Reporting bugs against frameworks/plasma2
Hi there! We are already trying to dogfood Plasma2 + frameworks and as it was to be expected we have tons of bugs :p so I have taken the liberty of setting up bugzilla, we can change things if you don't agree with that I have done. For frameworks: I have added a new version called frameworks, product is still kdelibs. For Plasma: I have created a new product called plasma-shell, since the technology has changed and all the code is almost new, it makes little sense to use the old one. I propose we add a frameworks version for each things we port (like powerdevil), so we can keep using the same product/components. What do you think? Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kded5 and kde-workspace
Hey there Today I have been porting powerdevil and while doing it found out that kded5 was not loading any modules and many kde-workspace projects were using org.kde.kded instead of the one ended with .kded5 Tomorrow I'd like to push a local commit that changes all org.kde.kded for org.kde.kded5 (which we will have to change again but more about that in a later email), and will effectively make kde-workspace and plasma-framework depend on kded5. In order to make kded5 load modules, you have to have KDE_SESSION_VERSION set to 5, so add that to your set kde5 environment script. So please, adapt your environment asap, I'd like to push this tomorrow so we can do testing of the kf5 KDEDModules instead of kded4. Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113723: Fix KIO to build standalone, prepare for moving into its tier
On Nov. 9, 2013, 12:47 a.m., David Faure wrote: staging/kio/CMakeLists.txt, line 34 http://git.reviewboard.kde.org/r/113723/diff/1/?file=212052#file212052line34 Why? KDED doesn't provide a library. It provides a DBus interface (.xml) that is installed and later on used in kcookiejar to generate c++ code. - Àlex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113723/#review43285 --- On Nov. 8, 2013, 5:01 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113723/ --- (Updated Nov. 8, 2013, 5:01 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- As you will see, this splitting was a bit harder than others: - KIO was using a couple of private headers from kjobwidgets, which now they will be installed. - The xslt_kde target was being used from KDocTools without having it exported. Now it will be properly exported. - Also defines all dependencies so it can be compiled independently, modularization is done as well. Diffs - tier2/kdoctools/src/CMakeLists.txt 3940e98 tier2/kdoctools/KDocToolsConfig.cmake.in PRE-CREATION tier2/kdoctools/KDocToolsConfig.cmake d501dc8 tier2/kdoctools/CMakeLists.txt c2256ff superbuild/CMakeLists.txt 458fb4c tier1/kcoreaddons/src/lib/CMakeLists.txt fad55c5 staging/kio/tests/CMakeLists.txt 6cee291 staging/kio/src/widgets/CMakeLists.txt d90386d staging/kio/src/ioslaves/http/tests/CMakeLists.txt 52c9f6c staging/kio/src/ioslaves/http/kcookiejar/CMakeLists.txt b0feff6 staging/kio/src/ioslaves/help/CMakeLists.txt 40637dc staging/kio/src/filewidgets/CMakeLists.txt 31fe8c6 staging/kio/CMakeLists.txt 6c7297e cmake/modules/FindGSSAPI.cmake cmake/modules/CMakeLists.txt 7910270 tier3/kded/KDEDConfig.cmake.in 32f8d56 tier3/kservice/src/CMakeLists.txt cc0c1a4 Diff: http://git.reviewboard.kde.org/r/113723/diff/ Testing --- Builds, Installs, tests still pass; both modularized and monolithic kdelibs. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113686: Fix KParts standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113686/#review43252 --- Ship it! Tested, it builds both independently and with the whole repo. - Àlex Fiestas On Nov. 7, 2013, 1:04 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113686/ --- (Updated Nov. 7, 2013, 1:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds all the dependencies so it can be compiled. Diffs - staging/kio/src/core/kprotocolmanager.h af8c8a8 superbuild/CMakeLists.txt e965cc8 tier3/kparts/CMakeLists.txt 77557bf tier3/kparts/autotests/CMakeLists.txt d47a821 tier3/kparts/src/browserrun.h 9038fd4 tier3/kparts/tests/CMakeLists.txt 1e675f0 Diff: http://git.reviewboard.kde.org/r/113686/diff/ Testing --- Builds, installs, tests still pass. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113695: Fix KDEWebKit standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113695/#review43253 --- Ship it! Tested, it builds and looks good. - Àlex Fiestas On Nov. 7, 2013, 12:38 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113695/ --- (Updated Nov. 7, 2013, 12:38 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds missing dependencies, small other fixes. Diffs - superbuild/CMakeLists.txt 90688f6 tier3/kdewebkit/CMakeLists.txt b56e71d tier3/kdewebkit/src/CMakeLists.txt c48b7ed Diff: http://git.reviewboard.kde.org/r/113695/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113693: Fix KNotifyConfig standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113693/#review43254 --- Ship it! I think this can go in once the comment is changed. - Àlex Fiestas On Nov. 7, 2013, 1:07 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113693/ --- (Updated Nov. 7, 2013, 1:07 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Add the dependencies of dependencies. Small fixes. Diffs - superbuild/CMakeLists.txt 90688f6 tier3/knotifyconfig/CMakeLists.txt 8be2ceb tier3/knotifyconfig/tests/CMakeLists.txt 385ff70 Diff: http://git.reviewboard.kde.org/r/113693/diff/ Testing --- Builds, installs, the test seems to work. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113694: Fix KNewStuff standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113694/#review43256 --- Ship it! Looks good, builds standalone and with frameworks. - Àlex Fiestas On Nov. 7, 2013, 1:04 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113694/ --- (Updated Nov. 7, 2013, 1:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds dependencies to make sure KNewStuff can be compiled alone Diffs - superbuild/CMakeLists.txt 90688f6 tier3/knewstuff/CMakeLists.txt f7f4dfa Diff: http://git.reviewboard.kde.org/r/113694/diff/ Testing --- Builds and installs. All tests are commented out. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
