Re: libksane, KSaneCore and QT_NO_KEYWORDS
Am 29.09.22 um 16:10 schrieb Ahmad Samir: On 29/9/22 10:22, Tobias Leupold wrote: Hi all! I recently had to port Scandoc from libksane to KSaneCore, and now, I have questions ;-) Question 1: On Gentoo, we have libksane 22.04.3 (stable) and 22.08.1 (testing). On an Artix machine I run, there's only 22.08.1 (those guys are even more bleeding edge than Gentoo ...). I could not link against libksane 22.08.1 anymore there. I knew that there was effort going on to create a separate library only containing the SANE communication backend, without the QWidgets dependencies. This is of course a reasonable thing to do -- but if I get this correctly, libksane itself now depends on KSaneCore, and one can't link against it as before. So what's the rationale behind still releasing libksane, when it can't be used anymore, and one has to port one's code to KSaneCore anyway? Apart from that: The KSaneCore API docs say that one should use "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link against it. That actually didn't work, I had to use "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I missing something, or should either the documentation be changed and/or the "KF5::SaneCore" target be added/defined? Question 2: KSaneCore depends on at least KF 5.90.0. After bumping this dependency in my CMakeLists.txt, I was deluged with compiler errors. It was a bit hard to figure out what was going on, but long story short, "-DQT_NO_KEYWORDS" is now set by default, which makes it necessary to use "Q_SIGNALS", "Q_SLOTS" and "Q_EMIT" instead of "signals", "slots" and "emit". I know that defining these keywords is argued about, as it "pollutes" the global namespace. But afaik, the only scenario where one has to define "- DQT_NO_KEYWORDS" is when a third-party signal/slot mechanism is used. Doing so seems to be reasonable when coding the frameworks (as Qt add-ons) to leave this up to the user. But what's the rationale or benefit of doing so by default for applications? Switching to Q_EMIT was done in KF because "emit" is going to be used by the STL in C++20 and later: https://lists.qt-project.org/pipermail/development/2020-February/038812.html https://en.cppreference.com/w/cpp/io/basic_osyncstream/emit Thanks for all clarification and/or explanation! Cheers, Tobias Regards, Ahmad Samir This is indeed an understandable reason to use the Q_... macros by default. Thanks for the explanation!
Re: libksane, KSaneCore and QT_NO_KEYWORDS
On 29/9/22 10:22, Tobias Leupold wrote: Hi all! I recently had to port Scandoc from libksane to KSaneCore, and now, I have questions ;-) Question 1: On Gentoo, we have libksane 22.04.3 (stable) and 22.08.1 (testing). On an Artix machine I run, there's only 22.08.1 (those guys are even more bleeding edge than Gentoo ...). I could not link against libksane 22.08.1 anymore there. I knew that there was effort going on to create a separate library only containing the SANE communication backend, without the QWidgets dependencies. This is of course a reasonable thing to do -- but if I get this correctly, libksane itself now depends on KSaneCore, and one can't link against it as before. So what's the rationale behind still releasing libksane, when it can't be used anymore, and one has to port one's code to KSaneCore anyway? Apart from that: The KSaneCore API docs say that one should use "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link against it. That actually didn't work, I had to use "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I missing something, or should either the documentation be changed and/or the "KF5::SaneCore" target be added/defined? Question 2: KSaneCore depends on at least KF 5.90.0. After bumping this dependency in my CMakeLists.txt, I was deluged with compiler errors. It was a bit hard to figure out what was going on, but long story short, "-DQT_NO_KEYWORDS" is now set by default, which makes it necessary to use "Q_SIGNALS", "Q_SLOTS" and "Q_EMIT" instead of "signals", "slots" and "emit". I know that defining these keywords is argued about, as it "pollutes" the global namespace. But afaik, the only scenario where one has to define "- DQT_NO_KEYWORDS" is when a third-party signal/slot mechanism is used. Doing so seems to be reasonable when coding the frameworks (as Qt add-ons) to leave this up to the user. But what's the rationale or benefit of doing so by default for applications? Switching to Q_EMIT was done in KF because "emit" is going to be used by the STL in C++20 and later: https://lists.qt-project.org/pipermail/development/2020-February/038812.html https://en.cppreference.com/w/cpp/io/basic_osyncstream/emit Thanks for all clarification and/or explanation! Cheers, Tobias Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: libksane, KSaneCore and QT_NO_KEYWORDS
Am Donnerstag, 29. September 2022, 12:09:10 CEST schrieb Christophe Giboudeaux: > libksane is still needed by a couple applications: > https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=KF5%3A%3ASane Yeah, sure, Scandoc was one of those -- but the problem is that on can't build the code anymore against newer versions of libksane. The code before the port (last commit was ea5fe5b890147d0f70235ae9dcdeb022fe7df8a3) compiles without a problem against libksane 22.04.3, but with version 22.08.1, I get: In file included from /home/tobias/tmp/git/scandoc/build/scandoc_autogen/ UVLADIE3JM/moc_ScannerSettingsWidget.cpp:10, from /home/tobias/tmp/git/scandoc/build/scandoc_autogen/ mocs_compilation.cpp:9: /home/tobias/tmp/git/scandoc/build/scandoc_autogen/UVLADIE3JM/../../../ src/ScannerSettingsWidget.h:9:10: fatal error: KSaneCore: No such file or directory 9 | #include | ^~~ because libksane doesn't include or at least install the respective header(s) anymore ... On my Gentoo machine with 22.04.3, the following headers are installed: /usr/include/KF5/KSane/ksane_export.h /usr/include/KF5/KSane/KSaneWidget /usr/include/KF5/KSane/KSaneCore /usr/include/KF5/KSane/KSaneOption /usr/include/KF5/KSane/ksanewidget.h /usr/include/KF5/KSane/ksanecore.h /usr/include/KF5/KSane/ksaneoption.h /usr/include/KF5/ksane_version.h On the Artix machine with 22.08.1 (and also if I upgrade the lib on Gentoo), only /usr/include/KF5/KSane/KSaneWidget /usr/include/KF5/KSane/ksane_export.h /usr/include/KF5/KSane/ksanewidget.h /usr/include/KF5/ksane_version.h remain. So ... nothing besides KSaneWidget ... and if some code uses libksane's KSaneCore and KSaneOption headers, it can't be built against 22.08.1 anymore ... also, one can't use the new KSaneCore lib as a drop-in replacement, as the namespaces as well as some signal signatures have been changed. Don't get me wrong, It's of course the right thing to do to retire libksane in favor of KSaneCore. But I would have expected to see some emphasized "Don't use me anymore, port your stuff to KSaneCore, libksane will be discontinued soon" warning for at least some time, before an upgrade leaves non-ported code uncompilable ... > > The KSaneCore API docs say that one should use > > "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link > > against it. That actually didn't work, I had to use > > "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I > > missing something, or should either the documentation be changed and/or > > the > > "KF5::SaneCore" target be added/defined? > > The change is intentional: https://invent.kde.org/libraries/ksanecore/-/ > commit/40c3d3687aee > > The metainfo.yaml also needs an update Thanks for the clarification!
Re: libksane, KSaneCore and QT_NO_KEYWORDS
Hello, On jeudi 29 septembre 2022 10:22:19 CEST Tobias Leupold wrote: > > So what's the rationale behind still releasing libksane, when it can't be > used anymore, and one has to port one's code to KSaneCore anyway? > libksane is still needed by a couple applications: https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=KF5%3A%3ASane > The KSaneCore API docs say that one should use > "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link > against it. That actually didn't work, I had to use > "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I > missing something, or should either the documentation be changed and/or the > "KF5::SaneCore" target be added/defined? The change is intentional: https://invent.kde.org/libraries/ksanecore/-/ commit/40c3d3687aee The metainfo.yaml also needs an update
libksane, KSaneCore and QT_NO_KEYWORDS
Hi all! I recently had to port Scandoc from libksane to KSaneCore, and now, I have questions ;-) Question 1: On Gentoo, we have libksane 22.04.3 (stable) and 22.08.1 (testing). On an Artix machine I run, there's only 22.08.1 (those guys are even more bleeding edge than Gentoo ...). I could not link against libksane 22.08.1 anymore there. I knew that there was effort going on to create a separate library only containing the SANE communication backend, without the QWidgets dependencies. This is of course a reasonable thing to do -- but if I get this correctly, libksane itself now depends on KSaneCore, and one can't link against it as before. So what's the rationale behind still releasing libksane, when it can't be used anymore, and one has to port one's code to KSaneCore anyway? Apart from that: The KSaneCore API docs say that one should use "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link against it. That actually didn't work, I had to use "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I missing something, or should either the documentation be changed and/or the "KF5::SaneCore" target be added/defined? Question 2: KSaneCore depends on at least KF 5.90.0. After bumping this dependency in my CMakeLists.txt, I was deluged with compiler errors. It was a bit hard to figure out what was going on, but long story short, "-DQT_NO_KEYWORDS" is now set by default, which makes it necessary to use "Q_SIGNALS", "Q_SLOTS" and "Q_EMIT" instead of "signals", "slots" and "emit". I know that defining these keywords is argued about, as it "pollutes" the global namespace. But afaik, the only scenario where one has to define "- DQT_NO_KEYWORDS" is when a third-party signal/slot mechanism is used. Doing so seems to be reasonable when coding the frameworks (as Qt add-ons) to leave this up to the user. But what's the rationale or benefit of doing so by default for applications? Thanks for all clarification and/or explanation! Cheers, Tobias
Re: KWayland respin request
On 9/29/22 00:22, David Faure wrote: Hi Vlad, I just read your email now. Better email me or release-team@ with such requests, for faster reaction times. In any case, 5.98.0 was released on Sep 12, so your mail came after the release, so it's not like a "respin" of 5.98.0 was possible. A 5.98.1 release of kwayland would be possible though. But I'm not sure it's worth it at this point, 5.99.0 will be tagged in 3 days and released in 10 days. Yeah, I think it's not as important as it used to be because 5.99.0 will be released soon. Regards, Vlad
