Re: libksane, KSaneCore and QT_NO_KEYWORDS
Hey Alexander, > Sorry for causing the extra work! Everything is fine, wasn't too hard ;-) And, as said, KSaneCore is of course the way to go. So, sooner or later, I would have ported my stuff anyway. > Since the KSaneCore interface inside libksane was never publicly announced, > Kåre and I decided that it is okay to remove it from the libksane repo. > I wasn't really aware that any other application besides Skanpage and > KSaneWidget actually used it directly. And I wasn't aware that this wasn't intended to be used directly ... and it seems that I was the only one to do so, because otherwise, someone else would also have complained about this I think. It was just I didn't like the KSaneWidget too much, as it was too ready-made for my taste, and I wanted to do it in a slightly different way. Thus, I implemented my own stuff. Also, Scandoc is currently a personal project, so I think that not too many people are using it by now. However, I use it in production in my dentist's office since I started to write it, and my wife also likes it :-) I didn't ask for opinions about the project yet (if this was possibly something that somebody may consider to be suitable for Extragear or so). Just for anybody being curious: I'm talking about https://invent.kde.org/tleupold/scandoc . Okay, but after all, all my questions are fully answered now. I now know what's up with libksane, KSaneCore (thanks for that again!) and the Qt keywords. Thanks for all the kind and detailed replies :-) Cheers, Tobias
Re: libksane, KSaneCore and QT_NO_KEYWORDS
Hello Tobias, I would like to add some explanations as it was me doing this :) Sorry for causing the extra work! On Thursday, 29 September 2022 13:19:37 CEST Tobias Leupold wrote: > 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 API of libksane has been only the KSaneWidget for most of the time. It was just internally split when I started working on Skanpage not too long ago. libksane will not be retired in the future as it's still providing a scanning interface for various applications. It is now just back to its original state before the split happened. libksane will probably be renamed to KSaneWidget (or similar) to reflect that better in the future, but this has to wait until the Qt6/KF6 transition. Since the KSaneCore interface inside libksane was never publicly announced, Kåre and I decided that it is okay to remove it from the libksane repo. I wasn't really aware that any other application besides Skanpage and KSaneWidget actually used it directly. > > > 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! > Sorry about that. I forgot to change it when it was decided to change the namespace. Best regards, Alex
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
