libksane, KSaneCore and QT_NO_KEYWORDS

[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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20220929/037feb10/attachment.sig>