OCR in KDE image viewers & editors?

after some “investigations”, i do believe it is some sort of a bug…

the documented KIO API has support for the old and the new path, but IMHO in the wrong order (as new actions are not added, if one of the same name already exists in. see: QWidget Class | Qt Widgets 5.15.15):

personaly i can’t handle this #if KIOWIDGETS_BUILD_DEPRECATED_SINCE(5, 85) line, that implies the included code will not be translated since framework version 85, but i’m running 110 and the old path based .desktop actions are not(!) ignored.

the latest(?) code has no support for the old path at all:

can someone shed some light into my likely wrong understanding?

or: how can i see, what actual code my current build 110 is made from?

Frog, a GTK Flatpak app that extracts Text from images

NormCap, extract from the screen

1 Like

Thanks, @kenning, because that would indeed would work for KDE apps in a roundabout way, although

wouldn’t be much use in the context of this topic, right?

As its about Qt app integration, no. But it is a Flatpak working on Wayland.

Do they work on X? I can’t use Wayland yet pleasantly due to 470535 – noborderrule=2 doesn't work on Wayland, does on X.

Thanks to this thread I was able to make a context menu action which runs tesseract on an image and puts the output on the pasteboard rather than creating a file. I wasn’t able to find a method which works on both X11 and Wayland, but here’s the working wayland version:

[Desktop Entry]
Type=Service
MimeType=image/*;
Icon=document-edit-sign
Actions=TesseractToClipboard;

[Desktop Action TesseractToClipboard]
Name=OCR to clipboard
Icon=document-edit-sign
Exec=tesseract %f - | wl-copy

It requires both tesseract and wl-clipboard packages, e.g.

sudo aptitude install tesseract wl-clipboard
2 Likes

Following your path, you might do something like:

Exec=[ "$XDG_SESSION_TYPE" == 'wayland' ] && clipcommand='wl-clipboard' || clipcommand='xclip'; tesseract %f - | $clipcommand

or you might do it the KDE way:

Exec=qdbus org.kde.klipper /klipper setClipboardContents "$(tesseract %f -)"

The first one definitely looks like an improvement! But is there any advantage to “the KDE way” which is worth making it less portable and more complicated? I don’t think I ever would have arrived at the “KDE way” myself, qdbus doesn’t even have a man page…

Edit: looks like these service actions are a KDE-specific thing anyway, so I suppose portability is a moot point

@barnaby, you know well that that’s not a doctrine which anyone adheres to. It’s silly to disparage an entire organization’s members, especially in such an unsubstantiated manner.

Since you (sensibly) want documentation for qdbus, have you filed an issue? I really want that too.

this!

so there is no downside. but lesser / lower requirements. qdbus(1) should always come with KDE, whereas xclip and wl-clipboard might not.

1 Like

That makes sense, thanks for the explanation! I assumed that Type=Service was just part of the desktop entry standard and didn’t realise that it was an un-namespaced KDE extension.

for unknown reasons there is indeed no manpage at least in neon. ubuntu has one online:

https://manpages.ubuntu.com/manpages/trusty/man1/qdbus.1.html

someone wrote a mini howto to get started with the concept of d-bus:

https://github.com/c-hartmann/D-Bus-the-mini-README

i’ve learned a lot of these:

1 Like