my name is Alex. I started work on a new preview tool for Dolphin (yes, another one. One day it will happen).
It’s called Maki, standing for “Maki is A KDE Inspector”.
It is supposed to be a very lightweight app that lets you quickly look at a file to see if it’s the right one before having to open it in your application of choice, akin to GNOME’s Sushi or MacOS’ quick look.
It is currently working as a servicemenu in Dolphin. I know a global shortcut is possible, but it seems very clunky to query Dolphin via DBus, especially if there are multiple windows. Ideally, Maki gets integrated as deep as possible within KDE.
This is where I need some help. Right now, Maki is very bare-bones and not usable how it is supposed to be, merely being able to show off its basic capabilities. If anyone has some pointers to where I can turn this into a proper Dolphin plugin with a good way to integrate a keyboard shortcut, that would be much appreciated. Otherwise, if it’s deemed better to go the Sushi route and call a method from within Dolphin on DBus, I would love to make that happen as well.
This is my first KDE application and as such, it might take a minute to develop properly, so any code reviews and merge requests are more than welcome.
Indeed yet another file-previewer.
It would be great of those authors would do the work to upstream it properly.
Up-streaming is always the superior way.
But, starting your own project is always natural and fun and a good learning exercise.
Getting to something that most users would benefit to using is the real challenge.
Maki is using Qml and seems pretty simple which are good points.
thank you for the feedback. I see the concern about these multiple projects and I agree with you. Upstreaming is exactly the direction I would want to go as well. I just want to get this feature into Dolphin since I use it constantly on MacOS, so I don’t particularly mind who does the work.
A few questions so I’m sure I’m approaching this the right way:
Would a QML-based implementation be acceptable in Dolphin, considering it is primarily a C++ codebase? My current plan would be to open the preview as a separate QQuickWindow rather than an inline overlay like quiclook if at all possible, since that more closely aligns with other preview tools like MacOS Quick Look and GNOME’s Sushi. Does that seem acceptable or is there a preferred integration pattern?
Given that KiView and the quiclook MR already exist, is there interest in working together on the issue instead of separately? I’m happy to contribute, specifically since working with other developers would be an even better learning effort.
Is there a preferred place to have this design discussion? I’d rather not turn this forum into a design review. I’m not too familiar with Matrix yet, which channel would be the most appropriate for this effort?
I’ve read through the MR and it was mentioned that the use of KParts was encouraged. It seems rather heavy for a preview tool, however. I wouldn’t mind using them, I just want to keep a previewer as light-weight as possible.
I’d rather ask these questions now than submit something that doesn’t fit the project’s direction. I’d really like to make this happen.
QML is fine, the rendering is a bit easier to write.
It has some drawbacks still. The backend is still in C++.
The idea would be have it out-of-process of Dolphin, have just at least a minimal app that show a window with a file preview, then have a daemon to start showing previews (similarly to krunner) so the qml startup is amortized and next file preview is instantaneous.
The end goal would be to allow any program to use it, i.e Plasma or other apps, with a simple dbus call.
You can try to help the Kiview repo, but I am not very satisfied with it (too complicated, thread handling…, too much c++) and his contributor lost interest it seems. He was well invested for some time.
So starting off would be fine too. You need to be confortable.
The main criteria is good code quality, start small while picking some architecture allowing the next foreseen evolution, what Kiview didn’t.
No need to handle every formats, start images and then pdfs, then other documents. Multimedia can come later…
The preferred place for design discussion is on invent issues.
You can see the kiview discussions:
Agreed.
KPart was recommended for pdf only, as this was for C++ code.