Re: Can my application, which contains dirty code, become an official kde application?
On 2024-01-17, Danilo Agostini wrote: > It allows the user, through the use of a keyboard shortcut or a dolphin > servicemenu, to have a quick preview of the files that are shown in the > folder without having to open the default application. > > Similar applications are Gnome Sushi and Quick Look (Mac os). Isn't this in the similar realm as what we can do with thumbnailers and/or kparts ? > Technical Limitations/Defects: > > 1) The way it integrates with dolphin is not clean due to dolphin's > limitations: I currently use dbus to copy the path of the selected file I'd suggest to fix whatever limitations there is in Dolphin to not have to do workarounds. > 2) The preview of some files (odt,doc,docx,xlsx,etc) is obtained by > converting the documents to pdf using the "libreoffice --headless > --nolockcheck --norestore --convert-to pdf" command. This obviously > requires libreoffice installed on the system and the conversion may fail/be > slow in some cases. I don't think this as such is a bad idea except maybe ... doesn't this negate the whatever speedup you are trying to do with a 'quick preview' instead of launching the app when you now actually launch the app headless in the background ? I just browsed around in the code and I do think there is quite some cleanups to do. I'm sure cppcheck, clazy, clang-tidy and other static analyzers can find a lot. oh. Don't use rand(). And consider using something to create a temporary working directory rather than work directly in tmpdir. Some members are m_ prefixed. others aren't. Some member vars shouldn't be member vars. Consider using much more const refs or views. I'm confused about when you use std::string and QString. It seems to be a bit random which one you pull out of the tool chest. And std::thread and QThread. Why are you using std::filesystem::__cxx11::path ? (Especially the __cxx11 part) Also there seems to be a pattern of |QString foo; |foo = someFunction(); Just having |QString foo = someFunction(); Is normally easier to work with. Also note that we are about to move everything to Qt6/KF6; This seems to be stuck on quite ancient frameworks and qt versions. /Sune
Re: Can my application, which contains dirty code, become an official kde application?
> Isn't this in the similar realm as what we can do with thumbnailers and/or kparts ? The preview is larger and allows you to scroll through all the files in the folder. Example with another program of mine written in Python: https://www.youtube.com/watch?v=mCfPZ5dgIZs I created this program (initially in python) to get better at programming and because some people were used to Quick look/Gnome sushi and were not satisfied with the thumbnails shown in dolphin. Example: https://www.reddit.com/r/kde/comments/165aqp8/any_kde_dolphin_replacment_sugestion_or_quick/ > I'd suggest to fix whatever limitations there is in Dolphin to not have > to do workarounds. Unfortunately I don't have the skills now and that's why I had to use a workaround to make it work. > I don't think this as such is a bad idea except maybe ... doesn't this > negate the whatever speedup you are trying to do with a 'quick preview' > instead of launching the app when you now actually launch the app > headless in the background ? Yes, but for many documents it takes a second or so (with the libreoffice flatpak package the time increases). > I'm confused about when you use std::string and QString. It seems to be > a bit random which one you pull out of the tool chest. This is my first project in C++ and I learned the language while writing this code. > And std::thread and QThread. Used to not block/slow down (I don't know a better word) the application when loading a document and to insert a minimum waiting time before being able to scroll to the next file. The point of this application is to be able to scroll through the various files without having to close and reopen the program. > Also note that we are about to move everything to Qt6/KF6; This seems to > be stuck on quite ancient frameworks and qt versions. When I started creating this application, I followed an example in the documentation on how to create an interface using Qml and Kirigami and I believe I used the version of Qt5/KF5 used in that example.I had already intended to port it to Qt6, but since I had no experience (I didn't even know how to use Cmake), I decided to stick to the examples provided and the code that was more available. This is also why, as you pointed out, there are things that don't seem to make much sense and the code requires a cleanup. > Why are you using std::filesystem::__cxx11::path ? (Especially the __cxx11 part) std::filesystem::path : I needed to extract information from the file (extension, name, parent directory, etc) and use std::filesystem::directory_iterator.__cxx11 : hmm, I probably used Qt creator's autocorrect/hint and made a mistake. I will fix this part of the code in the future and remove what is not necessary. Thank you very much for pointing out some things that need improvement. For now I think it's better if I port this application to Qt6/KF6 and continue to improve it myself until I have more experience. There are a lot of things that confuse me and I'm probably not ready to be part of such a big project. /Danilo
Re: Can my application, which contains dirty code, become an official kde application?
On 1/17/24 03:12, Danilo Agostini wrote: Hi, I developed an application and was thinking about doing the incubation process but I'm not sure if my application will be accepted due to some defects. What my application does: It allows the user, through the use of a keyboard shortcut or a dolphin servicemenu, to have a quick preview of the files that are shown in the folder without having to open the default application. Similar applications are Gnome Sushi and Quick Look (Mac os). Hi, this looks like a cool project, congrats! From a KDE perspective code quality concerns are mostly secondary, because we can always fix/improve things there. The most important question is what UX do we want to provide. Any implementation has to follow that, and not the other way around. Technical Limitations/Defects: 1) The way it integrates with dolphin is not clean due to dolphin's limitations: I currently use dbus to copy the path of the selected file into the clipboard and read it from my program. This, in addition to not being a clean way, also causes corruption of the content that was previously copied to the clipboard. I was able to get the previously copied text to be restored, but there is no way to restore the contents if what was copied to the clipboard before opening my application was a file. It seems like what you would need is a way to obtain the currently selected file from Dolphin via DBus (without detouring through the clipboard). I don't think that exists right now, but it should be easy enough to add. 2) The preview of some files (odt,doc,docx,xlsx,etc) is obtained by converting the documents to pdf using the "libreoffice --headless --nolockcheck --norestore --convert-to pdf" command. This obviously requires libreoffice installed on the system and the conversion may fail/be slow in some cases. I'd recommend you look at https://api.kde.org/frameworks/kio/html/classKIO_1_1PreviewJob.html. That's what Dolphin uses to create thumbnails and it has support for a huge variety of file types. While Dolphin typically generates rather small thumbnails it should be able to give you thumbnails of any requested size. https://github.com/Nyre221/Kiview https://github.com/Nyre221/Kiview/blob/master/src/dolphinbridge.cpp https://github.com/Nyre221/Kiview/blob/master/src/documentviewer.cpp I'm writing this here because it's what was suggested to me. Is there any chance that something like this could be accepted, or is it better if I continue to develop it myself? Thank you.
Re: Can my application, which contains dirty code, become an official kde application?
> this looks like a cool project, congrats! Thanks! > It seems like what you would need is a way to obtain the currently > selected file from Dolphin via DBus (without detouring through the > clipboard). I don't think that exists right now, but it should be easy > enough to add. What would need to be added is: 1) a boolean to indicate whether a file has been selected or not: this is necessary because the program changes its behavior depending on whether something had been selected or not. 2) the file path, or the parent folder path if no file/folder was selected. 3) Although not necessary, it would be nice if dolphin provided a list of the files sorted the same way they are sorted in the open folder. There are probably also other things that would be good to add to allow applications like mine, and not only, to integrate with Dolphin in a clean way. > I'd recommend you look at > https://api.kde.org/frameworks/kio/html/classKIO_1_1PreviewJob.html. > That's what Dolphin uses to create thumbnails and it has support for a > huge variety of file types. While Dolphin typically generates rather > small thumbnails it should be able to give you thumbnails of any > requested size. Thanks very much for the info! For now I will focus on porting the application to Qt6/KF6 and then I will see about making a feature request to the dolphin developers. In any case, thanks again. Il giorno mer 17 gen 2024 alle ore 20:27 Nicolas Fella ha scritto: > On 1/17/24 03:12, Danilo Agostini wrote: > > Hi, I developed an application and was thinking about doing the > > incubation process but I'm not sure if my application will be accepted > > due to some defects. > > > > What my application does: > > > > It allows the user, through the use of a keyboard shortcut or a > > dolphin servicemenu, to have a quick preview of the files that are > > shown in the folder without having to open the default application. > > > > Similar applications are Gnome Sushi and Quick Look (Mac os). > > Hi, > > this looks like a cool project, congrats! > > From a KDE perspective code quality concerns are mostly secondary, > because we can always fix/improve things there. The most important > question is what UX do we want to provide. Any implementation has to > follow that, and not the other way around. > > > Technical Limitations/Defects: > > > > 1) The way it integrates with dolphin is not clean due to dolphin's > > limitations: I currently use dbus to copy the path of the selected > > file into the clipboard and read it from my program. This, in addition > > to not being a clean way, also causes corruption of the content that > > was previously copied to the clipboard. I was able to get the > > previously copied text to be restored, but there is no way to restore > > the contents if what was copied to the clipboard before opening my > > application was a file. > > It seems like what you would need is a way to obtain the currently > selected file from Dolphin via DBus (without detouring through the > clipboard). I don't think that exists right now, but it should be easy > enough to add. > > > 2) The preview of some files (odt,doc,docx,xlsx,etc) is obtained by > > converting the documents to pdf using the "libreoffice --headless > > --nolockcheck --norestore --convert-to pdf" command. This obviously > > requires libreoffice installed on the system and the conversion may > > fail/be slow in some cases. > > I'd recommend you look at > https://api.kde.org/frameworks/kio/html/classKIO_1_1PreviewJob.html. > That's what Dolphin uses to create thumbnails and it has support for a > huge variety of file types. While Dolphin typically generates rather > small thumbnails it should be able to give you thumbnails of any > requested size. > > > https://github.com/Nyre221/Kiview > > https://github.com/Nyre221/Kiview/blob/master/src/dolphinbridge.cpp > > https://github.com/Nyre221/Kiview/blob/master/src/documentviewer.cpp > > > > I'm writing this here because it's what was suggested to me. > > > > Is there any chance that something like this could be accepted, or is > > it better if I continue to develop it myself? > > > > Thank you. >
