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
