Restore the mobipocket extractor based
on the QMobipocket library, which was
apparently dormant since the KF5 transition.
Adjust existing code where needed and fix tests.
Still disabled.
Details
Details
Diff Detail
Diff Detail
- Repository
- R286 KFileMetaData
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
I'm afraid this could be a bit of a dependency loop since kdegraphics-mobipocket has a thumbnailer that depends on kio which is a tier 3 framework while kfilemetadata is a tier2 framework.
Is it possible to move the extractor to kdegraphics-mobipocket instead of having it in kfilemetadata? or does it depend on non installed include files?
Comment Actions
Oh, thanks for the hint, didn't know that. That makes it a lot more complicated than a straight port :(
Looking at the code of kdegraphics-mobipocket, shouldn't the thumbnail extractor actually be part of kio-extras? Seems quite kio-specific, and a quick look at lxr didn't reveal any usages of the thumbnailer.
Comment Actions
Why would it be part of kio-extras? the beauty of plugins is that they can live wherever, no?
Do I understand that the answer to my "Is it possible to move the extractor to kdegraphics-mobipocket instead of having it in kfilemetadata? " question is no?
If so, that probably needs fixing, the fact that you can't have external plugins means that the code is probably not as good as it should
Comment Actions
There is support for external extractors in KFileMetaData. As far as I know, it has not yeet been used.
That is probably the safest way to do what you suggest.
If so, that probably needs fixing, the fact that you can't have external plugins means that the code is probably not as good as it should
Comment Actions
KFM supports two kinds of extractors, one QPlugin based, and one using external processes.
The first one uses the interface defined and exported in kfilemetadata/extractor.h. Although it is AFAIK currently only used by by the extractors bundled in KFM, it can be used by any other Framework or Application.
The second one uses Json over pipes to communicate with a forked process. The only available documentation is the sourcecode, i.e. externalextractor.cpp. It has more overhead (serializing/deserializing json data), but can be used where incompatible licenses would forbid linking with KFM.
Comment Actions
My thinking here was that a lot of other thumbnailers are located in kio-extras. Moving the thumbnailer there too would lift the KIO dependency and make qmobipocket easier to deploy and to be used by others.
Do I understand that the answer to my "Is it possible to move the extractor to kdegraphics-mobipocket instead of having it in kfilemetadata? " question is no?
If so, that probably needs fixing, the fact that you can't have external plugins means that the code is probably not as good as it should
No, the answer was I don't know :) But as @mgallien and @bruns stated, it's possible. But I lack the time and motivation to work on this.
But honestly, I'm not super interested in this, I don't have any mobipocket files. I just saw that this code lay there disabled for years, and thought it would be easy to enable, which it isn't.
Would you be fine if I disable the mobiextractor like before, and merge the changes anyways? This way, it does at least compile and runs if someone enables it in cmake.
Otherwise I will abandon this revision.
Comment Actions
Just a note about this: kio-extras was not meant to be a collector of all possible kios. It's becaming as such, but if this continues we may end up revisiting it and splitting it.
Comment Actions
I would really like the module to be in the mobipocket repo, would serve as actual proof the extractors outside the main module work if we have an example of it :)
| cmake/FindQMobipocket.cmake | ||
|---|---|---|
| 1 ↗ | (On Diff #47335) | This is wrong, mobipocket installs its own cmake files so you don't need a find module. |
Comment Actions
The plan I was about to propose is to move the thumbnailer to kdegraphics-thumbnailers and remove it from the QMobipocket library, lifting the KIO dependency of QMobipocket. I think a KIO dependency for such a library is inconvenient.
Comment Actions
The proposed solution to remove the loop is moving the extractor to the kdegraphics-mobipocket repository.
Comment Actions
And I propose a different one :)
IMHO bundling these two is sub-optimal as it creates an unnecessary dependency on kde-specific libraries and limits its deployment. To me, this is the equivalent of bundling the audio thumbnailer with taglib.
Well, if we disagree here, I'd still like to merge this as is because it gets the code into a compiling and working state at least.
Comment Actions
Sure, this code is not compiled, if you think it's better just commit it (IMHO, not kfilemedata specialist)