libksane, KSaneCore and QT_NO_KEYWORDS

[Tobias Leupold]

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!