libksane, KSaneCore and QT_NO_KEYWORDS

[Tobias Leupold]

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