Show info about selected folder, or parent folder if no selection

[RedBearAK]

@Nyre221

Hey, I just saw that you responded to a comment on Reddit asking about what the previewer does when no file is selected. And I confirmed that when a folder is selected, or if no file or folder is selected, the preview window will just show a random file (or the last file it viewed, maybe?).

I'd like to ask that you have it do something more logical and useful. In Apple's Quick Look, if you have a folder selected it will show you some basic info about the folder, like the number of files inside, a modification date, and the size (might want to restrict that to only local folders where it can calculate the size quickly, or have a reasonable timeout or a "Calculating..." on display). On the other hand, if you have no files or folders selected, QL will show you the info for the parent folder. In other words, it shows you info about the folder that is open and showing its files in the files pane. If you think about it, that's the thing that is always "selected" in a file manager, even when nothing is technically "selected".

GNOME Sushi doesn't show anything at all when nothing is selected. In my opinion this is a design bug, that can lead the user to wonder if the previewer is working. Something should always appear when the previewer is activated, whether it is by keyboard shortcut or from the context menu. Sushi at least shows info on the folder if you have a folder selected.

Pretty sure the Windows Explorer plugin also shows info about selected folders, but I'm not sure if it will show the parent folder info if nothing is selected.

Oh, and closely related to this, when I have multiple files and/or folders selected I get the same result as when nothing is selected (I think it's the last file that was previewed). For the case of having multiple files selected, the logical choice would probably to be to present some info about the group of files, like you would for a folder. A file count, total size of all selected files. Perhaps a list of file types among the selected files. But that last one might be more complicated to implement.

Basically, just show a simple version of what you'd see in a "Properties" dialog.

Note: You might want to tweak a setting to have yourself assigned to new issues automatically. I always forget where it is, maybe in issue templates.

No hurry on addressing anything in this issue. Just presenting ideas.

[Nyre221]

Basically, just show a simple version of what you'd see in a "Properties" dialog.

This will be added in the future.

On the other hand, if you have no files or folders selected, QL will show you the info for the parent folder.

Frankly I like that it currently opens a list of all files. What I can do is put an option on the shortcut to make it change the mode (see folder details or preview all files in the folder). by doing this the user can choose and it is not a problem if the user uses the single click mode to open files and folders.

For the case of having multiple files selected, the logical choice would probably to be to present some info about the group of files

Interesting and complicated to do.

Could you take some screenshots of the other programs and show me how these things are implemented?

[RedBearAK]

Sorry, forgot to respond to this earlier.

Frankly I like that it currently opens a list of all files.

I can understand that point of view, if you are thinking of your previewer as a separate app. The way Quick Look and Sushi work, they are more like transparent extensions of the file manager. Arrow keys move the selection around in the files pane, even if you don't click back on the file manager window to put the focus back on the main window.

Since your Quick View isn't integrated with Dolphin that tightly, the comparisons I'm making might not make that much sense ultimately. And that's fine. It's still an excellent companion for Dolphin.

Could you take some screenshots of the other programs and show me how these things are implemented?

Here's GNOME Sushi, when a folder is selected:

And the button will indeed open the folder, in a new Nautilus window.

When multiple files are selected, Sushi just seems to show the preview of the first file in the selection. Arrows continue to be able to move the selection around, cancelling the multi-selection.

Quick Look in macOS, with a folder selected:

Quick Look with multiple files selected (not what I was thinking, but note the arrows on header bar that let you go between the files in the selection, and they don't cancel the selection):

This is more of what I was thinking, but the Finder and other file managers typically have this covered with properties dialogs:

Select a collection of files and folders and this is the "Get Info" dialog:

Up to you if you want to let any of this influence the behavior of your Quick View app.

The main thing I'm not a fan of is having a random file (or the last file?) show up in the previewer when nothing was selected. If it was consistently the first file in the folder, I could understand that. But it seems to want to keep opening the "quick_view.desktop" file, even if that wasn't the one last previewed. And that isn't the first file in the folder.

It also keeps wanting to show me that file when I'm in a different folder with nothing selected. Which doesn't make a whole lot of sense. Even after I've previewed something else, like the tar.gz file.

When you have a valid file type selected, this program really is something. It's quite fast.

OK, that up arrow to open in default app thing is really going to bother me if I can't turn it off easily. I spend most of my time in some kind of list view, and it's just going to be second nature to use up/down to move to different files.

[Nyre221]

The main thing I'm not a fan of is having a random file (or the last file?) show up in the previewer when nothing was selected. If it was consistently the first file in the folder, I could understand that.

This is how it works if there are no subfolders.

If the path given is a folder, quick view chooses a file at random since it doesn't currently have a folder viewer and dolphin doesn't offer a way to select files only.

keep in mind that the shortcut can only receive one path, not a list of paths.

OK, that up arrow to open in default app thing is really going to bother me if I can't turn it off easily. I spend most of my time in some kind of list view, and it's just going to be second nature to use up/down to move to different files.

I'm going to use the arrow keys (up and down) for scrolling the pages in a document.
I didn't do it initially because using the arrows was horrendous.

I will create the folder viewer, but unfortunately the multi selection is not possible if you want to use the shortcut.

Remember that the shortcut uses tricks to work and it is not possible to integrate everything.

[RedBearAK]

dolphin doesn't offer a way to select files only

Ah, I see. So you would have had to check that the path is a directory and just not show anything (since there's no folder viewer yet).

keep in mind that the shortcut can only receive one path, not a list of paths.

I did wonder about that. If Dolphin doesn't provide some easy method to get the full list of selected paths, not much you can do. Though I do wonder if there isn't something in the D-Bus interface that might allow it. Maybe I'll poke around in the QDBus Viewer sometime. (Narrator: "He never poked around in the QDBus Viewer...")

I'm going to use the arrow keys (up and down) for scrolling the pages in a document.

That would be good. I might be the opposite of mad about that.

I think the other previewers don't allow for this, even if you click on the preview dialog to make sure the keyboard focus is there. They are really designed to pass those key events (or at least somehow ignore and repeat them) back to the main window. So you can zip around in any direction to preview different files.

The only way to scroll seems to be with the mouse/touchpad. So that could be a really welcome feature.

I will create the folder viewer, but unfortunately the multi selection is not possible if you want to use the shortcut.

You'll probably keep getting comparisons with the thing you literally announced Quick View as an alternative to 🤣 but as long as users understand it is a separate app that can't fully integrate in the same way, I think most will find it easy to get used to the differences.

Remember that the shortcut uses tricks to work and it is not possible to integrate everything.

Hopefully someone can convince the Dolphin devs to make it possible for a plugin like yours to have a better two-way integration at some point.

Just a little note before I forget, this will probably happen naturally depending on how you do it, but make sure the up/down arrows for scrolling don't do anything weird on something that isn't a "page-able" document, like an image or a folder. That's the kind of thing that often bites me when I get to the testing phase of trying to implement something like that.

Thanks for the replies. I'm already subscribed to releases since day one, so I'll see a notification for any new drops. 👀

🌹 🌷 🌹 🌷 🌹 🌷 🌹 🍪 🌹 🌷 🌹 🌷 🌹 🌷 🌹

[Nyre221]

I did wonder about that. If Dolphin doesn't provide some easy method to get the full list of selected paths, not much you can do. Though I do wonder if there isn't something in the D-Bus interface that might allow it. Maybe I'll poke around in the QDBus Viewer sometime. (Narrator: "He never poked around in the QDBus Viewer...")

Trust me, I checked everywhere 🤣🤣

You'll probably keep getting comparisons with the thing you literally announced Quick View as an alternative to 🤣 but as long as users understand it is a separate app that can't fully integrate in the same way, I think most will find it easy to get used to the differences.

I still can't believe it was so successful. It's my first application that has attracted so much interest and it's also one of the "simplest".

For me it's not a problem to add some functionality, but there are still things that I don't know how to do on my own. For example, I have tried in various ways to show the odt and docx in a decent way but I have always failed.

Covering all the features of quick look (where possible) is not an easy job.

Just a little note before I forget, this will probably happen naturally depending on how you do it, but make sure the up/down arrows for scrolling don't do anything weird on something that isn't a "page-able" document, like an image or a folder. That's the kind of thing that often bites me when I get to the testing phase of trying to implement something like that.

For now the scrolling is managed by the widgets I'm using. The only problem I've encountered is that the scrolling speed is very slow and I'm not sure how to change it.

Thanks for the replies. I'm already subscribed to releases since day one, so I'll see a notification for any new drops. 👀

Thank you too for the advice and help you are giving me 😄

[RedBearAK]

I checked everywhere

I wouldn't be surprised.

tried in various ways to show the odt and docx in a decent way but I have always failed

Weird. Some kind of failure of the tools? Font issues? I don't know nuthin' 'bout that so maybe don't get into it.

Covering all the features of quick look (where possible) is not an easy job.

Actually you kind of had most of it nailed down even with the first version. That's why everybody got so fired up. Lots of different file types already working, and a usable interface.

The only problem I've encountered is that the scrolling speed is very slow and I'm not sure how to change it.

Perhaps it might be possible to translate the arrow key events into triggering PgUp/PgDn actions? Which would probably be seen as much more useful for scanning through a multi-page document. Not sure how else you could control the speed other than changing the keyboard repeat rate.

Speaking of actual PgUp/PgDn actions, is that going to be something that would work also?

Thank you too for the advice and help you are giving me 😄

I think you meant, "Most mosquitos I know personally are less annoying," but I'll take it. 👍🏽 🤣

[Nyre221]

Weird. Some kind of failure of the tools? Font issues? I don't know nuthin' 'bout that so maybe don't get into it.

The odt and doc are not simple text, they are like archives. I tried converting them to pdf, it works but extremely slow and impractical, and to html and markdown (very fast but poor text formatting). With html and markdown the images were displayed (too large and badly placed), but the tables were illegible and the graphs were missing. text extraction (which I use now) instead allows you to have tables, but no graphs and headers.

Perhaps it might be possible to translate the arrow key events into triggering PgUp/PgDn actions?

I know how to do it but I've avoided it because it seems like a bit of a hack that can lead to problems. I already had to do this to map the "s" and "w" keys to the arrow keys, so the code is already there: https://github.com/Nyre221/dolphin-quick-view/compare/f913e6440eb27f94ceed5be58a61621dc422f02c...14506113eace285b98d3c1d3b74b2e297ac1ba44

My fear is that Qt might give strange problems if I try to send a signal that performs a function similar to the automatic one of the arrow keys.

Speaking of actual PgUp/PgDn actions, is that going to be something that would work also?

They already work.

changing the keyboard repeat rate.

the code I wrote above can also be used to do that if you want (set the key to its own automatic action = 2 times the signal). It's just that it doesn't seem like a very clean solution... maybe I'm worrying too much.

I think you meant, "Most mosquitos I know personally are less annoying," but I'll take it

hahaha no no, it's good to have someone who is helping me improve it.

initially I wanted to make a very simple application and not waste too much time on it, but now I think it's worth working on it a little more. It is currently my only application that will probably be used by other people over the years, and it is not difficult to expand.

The most annoying thing is using github... I don't understand it and I don't have time to understand it.

[RedBearAK]

PgUp/PgDn - They already work.

Cool. I've been distracted by other things and haven't had a chance to try that.

The odt and doc are not simple text, they are like archives.

For ODT I would have thought that would be well-supported by the available tools, since it's an open standard. But the DOC/DOCX I can understand. Not easy problems.

But that should sort of be up to those who know how to work with those formats and create all the neat tools you're using already.

the code I wrote above can also be used to do that if you want (set the key to its own automatic action = 2 times the signal). It's just that it doesn't seem like a very clean solution... maybe I'm worrying too much.

That's actually one of the options I was also going to suggest, if it's easy to do. Though if it also interacts with the user's key repeat rate setting it could get weird if you magnify it. Wonder if it makes sense to have a time-based control that would kind of make it behave the same everywhere. Some people really need slow repeat rates, others have it cranked high for some reason. But in most cases just throwing a 2x on there would probably be fine.

The most annoying thing is using github... I don't understand it and I don't have time to understand it.

The Club. Welcome to it. I'm still figuring many things out.

[RedBearAK]

So the new version seems to use Tab to open in the default app.

This steps on the idea of using Tab to move to the buttons in a window. I was trying to Tab to the button that would open in the default app (planning on activating the button with Space), but it just opened the file immediately instead. I repeated a couple of times to make sure that was what was happening.

There was an occasion where I thought this was showing me the files in a tar.gz file, but I think it was one of those times when I had used the up arrow to accidentally open the archive in its app, and the windows looked very similar and were in a similar location, so I got confused with what I was seeing. Seems like showing the list of files in archives would be a fairly simple viewer to put together, given the wealth of archive tools available.

Maybe, if you highlighted the button that opens in the default app and then conformed to the common UI convention that Enter activates the highlighted button (even if it's not selected), I might feel like that makes sense. But I think I'll always expect Tab to move to the window controls/buttons.

You're right about the slow scrolling with up/down. It seems like barely one line for each key press, and still fairly slow even if the hold the key down until it starts repeating.

I think it would be safe to try a 2x magnification of the input for up/down.

[Nyre221]

This steps on the idea of using Tab to move to the buttons in a window.

I chose the tab key because it is close to the navigation keys (w,a,s,d). In the future I will probably put a QPushButton to configure the shortcuts.

Enter activates the highlighted button (even if it's not selected), I might feel like that makes sense.

The way I see it, it's as if the displayed file is selected. It's a bit like when on Dolphin you press enter and it opens the highlighted file.

Then there's also the fact that I needed an open button close to the other navigation keys (arrows)

It's best not to highlight the button if it's not really selected: in the future I could add other buttons (settings, etc) and it wouldn't make sense if that was always visually selected.

Seems like showing the list of files in archives would be a fairly simple viewer to put together, given the wealth of archive tools available.

I will see

edit:

I tried and I can't repeat the arrow signal with that code. The problem is that the key calls itself in a circle and causes the application to crash.

I have two solutions: 1: the arrow keys have the page(up/down) function 2: write better code...

[RedBearAK]

I chose the tab key because it is close to the navigation keys (w,a,s,d).

I figured that was part of the choice. But since the window has visible buttons, I'm not sure how many users will find it intuitive.

It's best not to highlight the button if it's not really selected: in the future I could add other buttons (settings, etc) and it wouldn't make sense if that was always visually selected.

Just to be sure we're talking about the same thing, there's the little rectangle that follows the keyboard focus around as you tab through window controls, and then there is the button that is always a different color (blue, or the user's highlight color), even when it doesn't have the keyboard focus.

This is a thing in macOS and GNOME/GTK apps, but I'm not sure it's an obvious thing in KDE/Qt apps. Mostly you'll see this in windows you'd usually call "dialogs". And the Enter key should theoretically always activate that "default" button, even if that button doesn't have the rectangle or outer highlight indicating the keyboard focus. Like the "Save" button in file dialogs. Whether your cursor is in the file name field or you just clicked on something in the file pane, hitting enter should activate the "Save" button.

But maybe it's a little awkward to treat the Quick View window like it's just a dialog.

the key calls itself in a circle and causes the application to crash

Been there. Done that. Did not buy the t-shirt.

Given the rather limited usefulness of the slow scrolling when "previewing" a document (even if you did manage to double it up), I kind of feel like most users wouldn't be bothered much by the up/down being PgUp/PgDn by default. Maybe you could remap Ctrl+Up/Down onto the real Up/Down if someone really wanted to do the slow scroll once they get to the right page. That's still usable with the one hand strategy, I think.

[Nyre221]

Just to be sure we're talking about the same thing, there's the little rectangle that follows the keyboard focus around as you tab through window controls, and then there is the button that is always a different color (blue, or the user's highlight color), even when it doesn't have the keyboard focus.

ah, now I understand what you mean. I could do it, but I think in this case it's visually strange if one button is a different color than all the others. As I said before, I may put more buttons in the future and the open file button will no longer be in the center like it is now.

I'm not sure how many users will find it intuitive.

Intuitive, no, but they will understand it when they try to use the tab key to move through the buttons like you did🤣.

Another reason why I chose the tab key was because you said that you used it to select the open file button, so I thought of using that key directly to open the file (among other reasons). Probably in the future I will put a way to customize them so that users can choose what is best.

[RedBearAK]

ah, now I understand what you mean. I could do it, but I think in this case it's visually strange if one button is a different color than all the others. As I said before, I may put more buttons in the future and the open file button will no longer be in the center like it is now.

Yes, it is a paradigm that works well for "dialogs" like Open/Save kinds of things that really have one primary purpose, but if your app is really working more like a separate app maybe not so much. Maybe something to think about, just having the open-in-default button be the first in the Tab order if Tab did work that way, and letting Enter at least activate the button. Something to look at if it becomes possible to more closely integrate with Dolphin.

Intuitive, no, but they will understand it when they try to use the tab key to move through the buttons like you did🤣.

Nothing like the old, "Just pull the pin and see what happens, Bob!" 😆

Another reason why I chose the tab key was because you said that you used it to select the open file button, so I thought of using that key directly to open the file (among other reasons).

You wound me, sir! You cut me to the quick! 😱 🙀 But that's actually sort of logical... which is irritating. 😆

Probably in the future I will put a way to customize them so that users can choose what is best.

In case you do get around to that, I hope you're already aware that the Qt framework has some stuff that is specifically about the saving and loading of settings. I ended up using that through PySide6 for my little image backdrop displayer, so that it can save the theme choice, background color/transparency, image file and positioning/scaling options.

That was after I wasted some time trying to do an INI file with the built-in Python module for that.

[Nyre221]

Hi, I have an update for you:

when I was creating the zip viewer I thought that it was better to create a more general viewer (container_viewer) and so I'm using it for folders too.

Other things that I will change or have already changed: 1: If the shortcut is invoked without having selected a file, quick view shows some information of the parent folder via the new viewer (it is still possible to navigate between other files).

2: I will remove the "w" and "s" keys to scroll through the pages and the tab key will be used to navigate between the interface elements.

Problems:

1: Now the action behavior in the dolphin menu does not match the shortcut behavior. Unfortunately, Dolphin does not provide a way to understand whether a file has been selected or not and therefore if you use the Dolphin action the behavior is the same as before.

2: Linux does not save the creation date of a file and therefore I cannot put this non-existent data in the information shown. It's technically possible to use bash with "ls" to get a similar information, but that's not something I'm going to do.

Please note that I have not finished this new viewer.

edit: I forgot to mention that the folder opens in a new dolphin tab if you press Return.

[RedBearAK]

Wow, looks interesting. Makes sense having a common "what's inside this" viewer. Probably want to make sure that it shows something immediately and won't get bogged down on a folder/archive with thousands of files inside. Edge case.

I will remove the "w" and "s" keys to scroll through the pages and the tab key will be used to navigate between the interface elements.

I just saw someone posting on the issues of a different keymapper how they implemented "Wordstar" navigation shortcuts. They are substantially similar to what you were going for, but designed to turn ESDX into arrow keys (and the surrounding keys into other navigation keys) when you hold down the CapsLock key. Might want to look into that if you still want to have a potential shortcut scheme that allows the one-handed stuff.

Now the action behavior in the dolphin menu does not match the shortcut behavior. Unfortunately, Dolphin does not provide a way to understand whether a file has been selected or not and therefore if you use the Dolphin action the behavior is the same as before.

Not sure what this means since I haven't been using the shortcut that much. Like if you use the one from the context menu it can't know there is no file selected? Sounds weird. Don't you at least wind up with an empty path or something?

Please note that I have not finished this new viewer.

Looking good already. More than I even thought of.

I forgot to mention that the folder opens in a new dolphin tab if you press Return.

Yes, that or a new window are probably wise, since if the user wanted to navigate away from the folder they are already looking at they could just do it the usual way.

I'm actually leaning more toward a new window being the default, since it makes drag-n-drop or visual comparisons between folders easier, and [Task switching modifier]+Grave will switch between two windows of the same app a bit more easily than using a tab navigation shortcut like Shift+Ctrl+Tab/Ctrl+Tab or Ctrl+PgUp/PgDn (or in my case Cmd+Shift+Braces).

Users can be particular about whether they prefer new tabs or new windows in file managers. If you're setting up a configuration file of some kind, you might want that as one of the configurable options.

Kind of wondering about icons. I assume it's not so easy to apply the same kind of matching icons that the file manager uses to help identify filetypes. But there's no subfolders in the folder example. Would folders also show up in the list with the same "document" style icon? If folders end up with a folder icon and files end up all having the same generic document icon, that would probably be fine for the situation. 👍🏽

[Nyre221]

Wow, looks interesting. Makes sense having a common "what's inside this" viewer. Probably want to make sure that it shows something immediately and won't get bogged down on a folder/archive with thousands of files inside. Edge case.

I ran what I could on separate threads to make the data load faster.

Sounds weird. Don't you at least wind up with an empty path or something?

Selecting nothing means selecting the parent folder. There is no sure way to distinguish whether you have selected a subfolder or not. The only way I've found is to use pwd to figure out what the working directory is, but it has a strange behavior and I don't want to waste time coding something unstable.

Kind of wondering about icons.

I'm taking the icons from the breeze theme. It is possible to grab the icons that the user is using (already done on another project) but it is very slow and I don't think it's worth it for a viewer that needs to be fast.

Would folders also show up in the list with the same "document" style icon?

I wrote the code for the folders yesterday, today I did the code for some file type. I didn't have to do much, I just used kdialog --geticon to find the icon name and locate to find it.

Result:

I don't plan on adding anything else to this viewer.

[RedBearAK]

I ran what I could on separate threads to make the data load faster.

Probably a good idea. Although a time limit or a generator function with a limit on the number of results it returns before just saying "And a lot more..." might also be something to look at for the edge case of ridiculous numbers of files.

Selecting nothing means selecting the parent folder. There is no sure way to distinguish whether you have selected a subfolder or not. The only way I've found is to use pwd to figure out what the working directory is, but it has a strange behavior and I don't want to waste time coding something unstable.

I see. Probably won't be a big deal, if it still goes through the rest of the files when you left/right or use the buttons. Most users may not notice anything odd even if the behavior is a bit different between the menu item and the shortcut.

I'm taking the icons from the breeze theme. It is possible to grab the icons that the user is using (already done on another project) but it is very slow and I don't think it's worth it for a viewer that needs to be fast.

Reasonable approach.

I wrote the code for the folders yesterday, today I did the code for some file type.

That was more than I expected. Perfect for getting a quick idea what kinds of files are in a folder (or archive).

The presentation of the other metadata in the sidebar is also nicely done. I should have said before.

👍🏽 👍🏽

[RedBearAK]

I was about to leave a note about making sure the sorting of folders-first matches the option the user chose in their settings for the file manager (if it's not automatic), but then I noticed that the files list is not sorted lexicographically. The sorting seems the same in the older example and the new one. Is the sorting order being picked up from the existing sort order in the file manager, or defaulting to something like the natural inode order as files are created/added to the folder?

Most users will likely expect the files list to be sorted by name, if it can't match the sorting set in the folder. I'm not sure where the sorting choice is stored when doing per-folder sorting as an option. Dolphin can do that, right?

After using Windows for years I eventually got used to macOS not sorting folders first in the Finder. But it's one of those things people can be particular about wanting one way or the other.

[Nyre221]

Although a time limit or a generator function with a limit on the number of results it returns before just saying "And a lot more..." might also be something to look at for the edge case of ridiculous numbers of files.

I don't think it's possible to read only part of the archive. Also, even if it were possible, putting a time limit could cause quick view to show little or nothing if the first file in the archive is huge.

Folders, on the other hand, load very quickly and therefore there is no need of something like this.

Most users will likely expect the files list to be sorted by name, if it can't match the sorting set in the folder.

I can sort them alphabetically.

I'm not sure where the sorting choice is stored when doing per-folder sorting as an option. Dolphin can do that, right?

if I remember correctly it is possible to get that information via dbus, but there is the risk that quick view then becomes slow to open. Keep in mind that dolphin can sort by various data (last modified, size, etc) and trying to replicate its sorting can be a slow process.

[RedBearAK]

putting a time limit could cause quick view to show little or nothing if the first file in the archive is huge.

Quick Look on macOS will time out and just show very basic info on the file if it takes too long to read it. This often happens on large PDF files or images stored on slow NAS drives, or cloud folders where the file needs to be downloaded first.

It's a choice whether you want to do that or let the user wait and close the window if they get tired of waiting. Maybe not timing out so easily would be considered more useful.

Which reminds me, one major issue I had with Sushi is that it would try to load the entire file into memory (apparently) and would not stop the process in the background when closing the preview dialog window. Or maybe it even refused to close the dialog. It would also peg a CPU core while doing this, and on a single or dual-core system it would really bog things down. The weird thing is that this could happen on files that were just text files at the beginning (like the ".run" Bash installer for the Private Internet Access client), and if you just renamed the file with ".txt" the previewer would use a different way of reading it and immediately show the first part of the file.

Make sure that your app window will terminate any attached thread(s) automatically if the window process is stopped by any means, even if there is a read attempt in progress in any separate thread. If you're using the threads module and daemon=True this should already be taken care of. The separate threads will be stopped when the main process terminates. I had to make sure to get this right in my own project because the separate threads are running watchdog loops.

if I remember correctly it is possible to get that information via dbus, but there is the risk that quick view then becomes slow to open.

Yes, I think that just sticking with a normal lexicographical/alphabetical sorting for the preview will suit the task quite well. No need to get fancier if there is any risk of slowing things down.

[Nyre221]

This often happens on large PDF files or images stored on slow NAS drives, or cloud folders where the file needs to be downloaded first.

the problem is that partially reading something is not so easy when it comes to archives. with pyexcel I tried to partially read the data (pyexcel_xlsxr,etc) but it doesn't work. I think it's something that pyexcel can only do sometimes and not always. btw, an xlsx with 33000 rows can be read in 7 seconds on my PC. not very fast, but I think it's decent if it doesn't bog down the interface.

for xlsx,ods,etc: http://docs.pyexcel.org/en/latest/bigdata.html

Which reminds me, one major issue I had with Sushi is that it would try to load the entire file into memory (apparently) and would not stop the process in the background when closing the preview dialog window.

Quick view does the same thing. to stop the archive from opening, the module in use (zipfile,rarfile,tarfile) should implement something that would allow it to be stopped(I guess). My code lets the zipfile/tarfile continue and exits when it finishes.

maybe it even refused to close the dialog

I had to resolve this yesterday.

The weird thing is that this could happen on files that were just text files at the beginning (like the ".run" Bash installer for the Private Internet Access client), and if you just renamed the file with ".txt" the previewer would use a different way of reading it and immediately show the first part of the file.

I think it's because gnome sushi tries to highlight the code in the script (.sh,.run)

daemon=True

done yesterday.

No need to get fancier if there is any risk of slowing things down.

At the moment I think it's already slowed down a bit. I have to compare with another version.

[RedBearAK]

partially reading something is not so easy

Yeah, I figured it's not necessarily easy to stop in the middle (although I'm sure the thread can be terminated by a timer). That's why I suggested a file size check before starting on something big.

In case it's not clear what Quick Look does, when it gives up on something after a few seconds it just shows a super basic dialog like the folder preview, except I think it also says something about being unable to display the preview, some kind of minimal error message. There's no attempt at any kind of partial display of anything on any file type where I've seen this happen. QL is like, "Nope."

If it's just that the file was reading too slowly because a NAS drive needed to wake up, or the file needed to be downloaded from the cloud, trying again would usually work.

I think it's because gnome sushi tries to highlight the code in the script (.sh,.run)

Yes, probably. And to be fair to whatever was trying to parse the file, it was about 80MB and I think the .run files are created by some sort of installer development software and only had text at the beginning of the file, with binary data from then on. It was a very peculiar type of file. But the main issue was just that the thing trying to parse the entire file refused to quit when the main window that called it was dismissed. I was messing with a really old single-core Pentium laptop at the time, and it would completely tank the system for a few minutes. I filed a bug report about it a couple of years ago, but with the proliferation of multi-core systems these days I don't think the devs saw it as a big deal.

to stop the archive from opening, the module in use (zipfile,rarfile,tarfile) should implement something that would allow it to be stopped(I guess). My code lets the zipfile/tarfile continue and exits when it finishes.

I would probably put some kind of timer that could terminate it in unreasonable cases, and then just show a simple error. But it's up to you. It's happening in a different thread already, I assume.

I had to resolve this yesterday. done yesterday.

I knew you'd be on the ball in this area. Cheers. 🍹

[Nyre221]

For pyexcel I "solved" it by using another thread and limiting the rows shown. While it doesn't seem to impact memory (not always at least), showing all rows is heavy for QTablewidget and so with fewer rows the loading time is faster.

I noticed that there is a problem: If the user switches too quickly from one xlsx to another (a normal user wouldn't do this) the program slows down a bit. this happens if you have many xlsx,ods,etc and you go at an unnecessary speed (button always pressed). I think the best thing is to put a minimum waiting time when switching from one file to another (0.3 sec).

I also tried using the multiprocess module and killing the pyexcel process, but sometimes it didn't want to load the xlsx file and therefore I considered it too unstable. This always happened when quickly changing from one file to another.

[RedBearAK]

@Nyre221

Yeah, a small delay before you actually start trying to preview things is probably a good idea.

Did you mean to close this? Seems pretty well taken care of, but just checking. I've accidentally closed an issue once or twice on GH by hitting the wrong button.

[Nyre221]

@RedBearAK

I have uploaded content viewer to github and therefore this report can be closed.

I wanted to close it with the commit but I forgot...

This is getting a lot more challenging than I thought. I already had to fix a problem that hadn't appeared before, and for some reason tableviewer doesn't free the memory when loading a new xlsx. not a huge problem for now, just hoped to be done with the xlsx...

Maybe I could try using the multiprocess module again and see how it goes. With that there was no memory problem and I think I understood why sometimes it didn't load the xlsx.

I'm too tired today, I'll see tomorrow.

[Nyre221]

@RedBearAK

If you want to try this version: https://github.com/Nyre221/dolphin-quick-view/releases/tag/v1.2.3_RC1

[RedBearAK]

@Nyre221

It looks good, but a couple of observations. I'm not sure if this is what you meant by the odd behavior, but if you right-click on a folder and preview it, it starts showing direct previews of the things inside the folder, instead of the folder contents overview.

But if I start Quick View by first selecting something that isn't a folder, and then arrowing (via left/right) to a folder, it will just show the list of files in the folder.

Kind of wondering how that even happens, since if I right-click and start Quick View without having anything selected, it will just show the list of files inside each folder/archive as it should. So it's like when right-clicking on a folder and previewing, it acts as if you had selected one of the files inside the unopened folder... 🤔 Which shouldn't actually be possible.

Setting up a global shortcut to call the script does not result in this behavior.

The window comes up pretty quickly, regardless of file type. Takes about a second in a Fedora 38 VM with 4GB of RAM, running on a Ryzen 3700u host. Quite good, I think. 👍🏽

Up/down scrolls through the list of files inside a "container". Seems like a good choice. 👍🏽

Enter does indeed open the folder in a new tab. And opens other files in the default app. 👍🏽

Tab now moves between buttons. I think no one will be surprised by this. 👍🏽

Not sure I'm a big fan of looping around when reaching the beginning or end of files in the folder, but I don't know how easy it would be to even know you were at the "beginning" or "end" of the list of files. Not a big deal, just not something I've usually found useful when done on purpose.

The container views look fantastic. 👍🏽

So, a couple of quirks but overall just amazing work, and already has more features than Quick Look on macOS (they lost a lot of compatibility with video filetypes years ago and QL doesn't let you peek in folders/archives).

One thing I was just thinking would be a good enhancement at some point might be an indicator somewhere of how many files are in the folder you're currently previewing files in, and maybe something that gives a sense of where you are in the list. Not like the container viewer where it shows the number of files inside, but the number of files in the parent folder you're scrolling through with the left/right arrows.

But that would probably require dumping the whole list of files and sorting and counting, all in the background, in addition to running the preview method for the currently selected file. Maybe put it way on the back burner. Or discard it.

If there's some particular issue that I should test for that is causing you to hold off on calling it a stable release, let me know.

[Nyre221]

@RedBearAK

One thing I was just thinking would be a good enhancement at some point might be an indicator somewhere of how many files are in the folder you're currently previewing files in, and maybe something that gives a sense of where you are in the list. Not like the container viewer where it shows the number of files inside, but the number of files in the parent folder you're scrolling through with the left/right arrows.

This is really a good idea, thanks! what do you think about a dot indicator? Maybe it's more complicated but it would be nicer.

Not sure I'm a big fan of looping around when reaching the beginning or end of files in the folder

The problem is that now the files are in alphabetical order (folders first) and it would be strange if the user opened a file in position number 5 (for example) and then had to go all the way to the right and then all the way to the left to see all the files .

It looks good, but a couple of observations. I'm not sure if this is what you meant by the odd behavior, but if you right-click on a folder and preview it, it starts showing direct previews of the things inside the folder, instead of the folder contents overview.

This is because dolphin does not make a distinction between a parent folder and sub-folders and therefore quick view has two different behaviors depending on what opens it (the old one and the new one used by the shortcut)

But if I start Quick View by first selecting something that isn't a folder, and then arrowing (via left/right) to a folder, it will just show the list of files in the folder.

I'm not sure what you mean. if you select a file and then select the folder with the arrows, does the action in the dolphin menu behave differently?

I've noticed that xlsx files don't always load and I know what causes it. Don't open a report for that problem.

Thank you very much for trying the quick view beta. I probably wouldn't have gone this far if you hadn't helped me.

[RedBearAK]

@Nyre221

This is really a good idea, thanks! what do you think about a dot indicator? Maybe it's more complicated but it would be nicer.

Not sure what you mean by "dot indicator". I was thinking more of how you might see a number of total images in an image viewer app, like "Item 56 of 357". Somewhere near the arrows, or maybe in the title bar.

The problem is that now the files are in alphabetical order (folders first) and it would be strange if the user opened a file in position number 5 (for example) and then had to go all the way to the right and then all the way to the left to see all the files.

Everybody has their own view of whether looping is a good thing. Not sure what you mean by "strange" though. When I'm just using the arrow keys to move the selection (not previewing) in the files pane, it stops at the top and the bottom of the list. See, I'm still looking at it as if it was integrated with Dolphin and was actually moving the selector back in the Dolphin window along with what you select in the previewer with left/right. But that's not how it works, and you'd need something like ydotool to try to move the selector around in the Dolphin window while pretending you were integrated.

But this looping is only encountered in folders with limited numbers of files anyway. It's really not important.

I'm not sure what you mean. if you select a file and then select the folder with the arrows, does the action in the dolphin menu behave differently?

I was in the Downloads folder with just four files. Two were folders, and two were archives. If I right-clicked on a folder and opened Quick View from the menu, it would display a preview of one of the files inside the folder. The left/right arrows would move the preview between the files inside the initially selected folder.

If instead I right-clicked on an archive file and previewed it, then used lef/right to move to where it was showing me a preview of one of the folders in Downloads, it showed the list of files inside that folder (treating it as a container).

When I choose the context menu item after right-clicking on empty space in Downloads, it wants to show me the list of files in the first item in Downloads, which happens to be a folder. It does not show me the info about the parent folder.

With the shortcut (calling the script) and nothing selected, I get the info about the parent folder, and the "parent folder" item remains in the list if I go left/right, so it's like there's an "extra" item in the list of things to preview (which is interesting).

When a folder is selected and I use the shortcut, it shows the preview of the list of files in the folder.

So I guess it's doing the same thing via the context menu item whether I right-click on empty space or on a folder. It's not showing the preview of the thing that is actually selected (the parent folder or the selected folder inside the parent, respectively). By "parent folder" in this example I mean the Downloads folder.

This is because dolphin does not make a distinction between a parent folder and sub-folders and therefore quick view has two different behaviors depending on what opens it (the old one and the new one used by the shortcut)

I'm not clear on what this means. Is the context menu item actually doing something different from what the shortcut script does?

I've noticed that xlsx files don't always load and I know what causes it. Don't open a report for that problem.

No problem. I don't have a lot of xlsx files kicking around anyway. Pretty neat that they work at all.

Thank you very much for trying the quick view beta. I probably wouldn't have gone this far if you hadn't helped me.

It's been fun. 👍🏽 You really put the Dolphin/KDE devs to shame by showing that one person could put all this together with the available tools.

[Nyre221]

@RedBearAK

When a folder is selected and I use the shortcut, it shows the preview of the list of files in the folder.

container viewer, right?

so I guess it's doing the same thing via the context menu item whether I right-click on empty space or on a folder. It's not showing the preview of the thing that is actually selected (the parent folder or the selected folder inside the parent, respectively). By "parent folder" in this example I mean the Downloads folder.

The action in dolphin's menu cannot use container viewer on a user-selected folder (opens a random file in it) and cannot show the parent folder's information.

The shortcut should show information about the selected folder (container viewer) or the parent folder if nothing is selected.

if you select a file and use the action in the dolphin context menu, it is possible to understand which is the parent folder and therefore it is also possible to create the list of files to display based on the contents of the parent folder.

In short, in dolphin there is no difference if you right-click on an empty space or select a subfolder (no distinction between subfolder and parent folder).

with the shortcut it is possible to understand the difference between parent folder or sub folder because if nothing is selected the path returns empty and therefore after sending the "select all and copy a path" signal it is sufficient to cut the final part of the path.

examples:

dolphin:

empty space = /home/user/foldername

selected = /home/user/foldername/subfolder (but no way to be sure whether the action was invoked by clicking on a empty space or not.)

file selected: /home/user/file.xx: parent = /home/user/

shortcut:

no selection = nothing, send the signal and cut the path

selection: /home/user/foldername : parent folder = /home/user/: show info about the selected folder and create the list based on the parent

I'm not clear on what this means. Is the context menu item actually doing something different from what the shortcut script does?

yes

With the shortcut (calling the script) and nothing selected, I get the info about the parent folder, and the "parent folder" item remains in the list if I go left/right, so it's like there's an "extra" item in the list of things to preview (which is interesting).

I did this to avoid having to modify the indexing code. laziness haha

edit:

maybe it's possible to invoke the script via the action in the dolphin menu and bypass the problem... I'll have to try.

[RedBearAK]

@Nyre221

container viewer, right?

Yes, the shortcut always seems to do what you'd expect. Or what I'd expect, from referencing other previewer implementations.

maybe it's possible to invoke the script via the action in the dolphin menu and bypass the problem... I'll have to try.

That's exactly what I was thinking of asking about. But then, if I understand correctly, you'll be handing the script the indistinguishable path rather than an empty path like you get when just invoking the shortcut? Maybe not necessarily an improvement.

In short, in dolphin there is no difference if you right-click on an empty space or select a subfolder (no distinction between subfolder and parent folder).

I see what you mean. You're given a path either way, and can't tell if it's the parent or not.

If there's really no good way to do the equivalent of pwd while invoking the window, it might just be a quirk that you'll have to live with. Sure seems odd though, that it should be so difficult to know what folder is open in the files pane, when being invoked directly from the Dolphin context menu. Can't be determined from the Python side? I'm sure you've tried determining what the Python code thinks the current directory is, under the different circumstances. (Independently of what Dolphin is providing as a path.)

[Nyre221]

@RedBearAK

if I understand correctly, you'll be handing the script the indistinguishable path rather than an empty path like you get when just invoking the shortcut?

no no , run it as with the keyboard shortcut without passing any path. this way there is no need to use strange tricks or write other code. I'll check tomorrow if it works.

equivalent of pwd

this is something that is possible to do, but it has strange behavior (you can still use it) and I don't know if it is the same on every version of dolphin (I don't want to write code for different versions and do 1000 tests). It has already happened to me in the past for another project that I encountered a small differences that I had to work around.

[RedBearAK]

@Nyre221

no no , run it as with the keyboard shortcut without passing any path. this way there is no need to use strange tricks or write other code. I'll check tomorrow if it works.

I see what you're going for. Well, good luck. Let me know if you need more testing sometime.

Reminder if you aren't aware, closed issues on GH may not send out notifications without an "@" mention in each post.

[Nyre221]

@RedBearAK

I made the change and it seems to work fine.

[RedBearAK]

@Nyre221

Took a look at the 1.2.3 RC 3 that just dropped, I didn't get a chance to try the earlier RC.

I noticed that the last couple of RCs aren't ~50 MB anymore. Found a different way to make sure all necessary components are included?

I like the addition of the index, but it has some oddities. When there is nothing selected, I think it doesn't make sense to include the "zero" item (the parent folder) in calculating the total number of items. This leads to not being able to get to an item numbered the same way as the "total" number. The indexing also seems to do a sort of "off by one" thing after starting with something selected and moving to the "zero" item, even though the "total" number is one less in that case.

Nothing selected:

[0/4] -> [1/4] -> [2/4] -> [3/4] -> [0/4] (loops)

Something selected (item is 3 of 3 items in the folder):

[2/3] -> [0/3] -> [1/3] -> [2/3] (loops)

In this latter case, I guess this is just an off-by-one issue, because the item marked as "zero" is just the first item in the list, not the parent folder.

I think it's perfectly rational to keep treating the parent folder item as the "zero" item, since it's not actually "in" the folder. So just fix the off-by-one issue and it should be good.

I made the change and it seems to work fine.

That did indeed seem to make the context menu item now behave the same way as the shortcut (since it's literally doing the same thing now). No more previewing the contents of items inside a selected folder. Just shows the list of files inside. 👍🏽

[Nyre221]

@RedBearAK

[0/4] -> [1/4] -> [2/4] -> [3/4] -> [0/4] (loops)

Thanks for pointing that out to me
I implemented that feature without paying attention and I forgot that the index starts at 0.

I noticed that the last couple of RCs aren't ~50 MB anymore. Found a different way to make sure all necessary components are included?

I dropped pyexcel in favor of libreoffice (not included).

Converting to pdf with libreoffice allows me to give a better preview of xlsx,docx,odt,etc,etc files and the installation is optional. I realized that the slow conversion was due to the example files I was downloading and therefore it made no sense to continue with pyexcel.

the flatpak version of libreoffice is supported but needs to be configured:sudo flatpak override org.libreoffice.LibreOffice --filesystem=/tmp

If you want, you can also use flatseal to give libreoffice access to the /tmp folder

[2/3] -> [0/3] -> [1/3] -> [2/3] (loops)

The file you selected is number 2 in the list generated by quick view and that is why it follows that sequence. remember that quick view generates the list in alphabetical order.

Thanks for trying the RC version

[RedBearAK]

@Nyre221

The file you selected is number 2 in the list generated by quick view and that is why it follows that sequence. remember that quick view generates the list in alphabetical order.

No, the folder was in list view, in alphabetical order, and the item was 3 of 3, and was last in the loop. Notice in the loop depicted there is no [3/3]. When you fix the off-by-one it will be correct.

I guess fixing the off-by-one will also fix the list where the parent folder is included, technically. Then the parent folder will be the "1" item. I liked the idea of there being a "zero" item in that case, and leaving it out of the total, but that would probably just confuse many users, and complicate the code. So ignore that.

I dropped pyexcel in favor of libreoffice (not included).

I see. So the user would need to have LibreOffice installed. Kind of makes sense.

Too bad about the extra hoops that often have to be jumped through to integrate Flatpak apps. They have their advantages, but they are decidedly not the best thing since sliced bread. Could be handled from the installer if the LibreOffice Flatpak was detected, but probably not worth the trouble.

[Nyre221]

No, the folder was in list view, in alphabetical order, and the item was 3 of 3, and was last in the loop. Notice in the loop depicted there is no [3/3].

yes yes, I understand what you mean.
What I was referring to is that the sequence started from 2 (3 if it starts from 1): [2/3] -> [0/3] -> [1/3] -> [2/3]

you selected is number 2 in the list generated by quick view

number 3*

I liked the idea of there being a "zero" item in that case, and leaving it out of the total, but that would probably just confuse many users, and complicate the code. So ignore that.

Now the parent folder is 0 (the list starts at 1 for other files).
I chose to do as you said before because it's easier than editing the code to remove the parent folder from the list.

[Nyre221]

@RedBearAK

Could be handled from the installer if the LibreOffice Flatpak was detected, but probably not worth the trouble.

It requires the use of sudo and I don't think users will like it if I find a way to do it automatically.
For now I have put a button that points to the documentation(to do) that appears if flatpak/libre has an error.

edit:
obviously adding a button to adjust read permissions would be the best thing.

[RedBearAK]

@Nyre221

number 3*

Gotcha.

It requires the use of sudo and I don't think users will like it if I find a way to do it automatically.

I was thinking more of a prompt that would ask whether they wanted it done for them. I have to do a lot of sudo stuff with my installer, so I'm used to it. But yes, that is a valid reason to just avoid messing with it.

For now I have put a button that points to the documentation(to do) that appears if flatpak/libre has an error.

Perfectly valid approach. 👍🏽

obviously adding a button to adjust read permissions would be the best thing.

If I was doing the code, I would probably do something like that for my own convenience if nothing else. But not a pressing need. I wonder though, what happens if LibreOffice is running at the time. Does it need to be restarted to pick up the new permissions? If so, another good reason to just let the user handle it.

I chose to do as you said before because it's easier than editing the code to remove the parent folder from the list.

Hopefully nobody will be confused by that and think there is still an off-by-one error when that item is just being excluded from the total. I guess we'll see. Makes perfect sense to me, but probably mostly because I was already thinking of the parent folder as a separate thing.

Then again, I may be the only one who generally bothers to test it without something selected. 😆

[Nyre221]

@RedBearAK

Hi, can I ask you a question?

Do you think it's better to use Kirigami or Qtwidget for the C++ version of Quickview?

https://develop.kde.org/frameworks/kirigami/

A developer contacted me and told me that there would be more chances of making QuickView an official application if it were written in c++ (like the others) and advised me to try QML (Kirigami). The problem is that I know almost nothing about C++ and above all I know nothing about QML and the interaction with C++. For now I haven't even been able to figure out how to use Kirigami components in an interface...

If I stay with Qtwidget is much easier, but I don't want to have to rewrite everything in the future.

I'm going to at least try to port it to C++ because otherwise someone else will do it (that developer is interested) and I won't be able to direct it anymore.

To be clear, I was hoping someone would take this project further than I can, I was just hoping I could develop it for a little longer. I like the idea of trying to make this an official plasma application and it's an experience that's hard to repeat.

I'm happy however it goes.

In the end what matters most to me is that this application can still exist in the future and I'm happy that there is someone interested in carrying it forward.

[RedBearAK]

@Nyre221

Unfortunately that is pretty far out of what I know anything about. I leveraged pre-existing projects and extensive use of GPT-4 (the smarter $20/month version of ChatGPT, with quite impressive reasoning, analysis and code example capabilities) to get anywhere with the few small apps I've managed to create.

It's very cool that you're even looking into finding a way to make it an official part of KDE, and I think it deserves to be at least a springboard example of what ultimately becomes an official previewer for Dolphin.

The AI model has some interesting things to say about the question:

In conclusion, if you're aiming to make QuickView an official KDE application and want it to have a modern touch and adaptability, Kirigami is a better choice. However, it will require an investment in learning QML and its interaction with C++. If you're looking for a quicker path to a stable desktop application and are okay with a more traditional interface, QtWidgets is the way to go.

Lastly, remember that it's possible to mix QtWidgets and QML in the same application, so you could potentially start with QtWidgets and incorporate Kirigami components as you become more comfortable with them.

So, most likely it would be quite involved to port the app from Python and attempt to do the same thing in QML/C++. It may be easier to do as it says here and start with mostly QtWidgets. There isn't much argument that QuickView needs to be "adaptable" for use on mobile devices, for instance. So maybe moving to Kirigami can wait until later.

I would highly recommend that you at least try interacting with ChatGPT on a free OpenAI account. It is already excellent for just providing code examples and explaining code mistakes and helping with troubleshooting errors. But the GPT-4 model is the definition of next level. Ask it specific, complex questions, and it can explain things in highly useful ways. Details, or overviews that help you orient and move forward.

The training for the model now cuts off at January 2022, I think, but Kirigami has been around since 2016, so it should have a good handle on being able to introduce you to QML, C++ and Kirigami. It had a good idea of how to use PySide6 already, because it's been complete for a while now. Take it one basic step at a time and I think you may be shocked at what you can end up with in a very short time, while actually understanding it as you do it. Don't get how something works? Ask it to explain. Still confused? Ask it to explain a different way (explain to it which aspect you didn't understand). Show it some Python and ask it how to do something similar in QML/C++.

Some of what I've done has been by using the AI to explain how to convert code from a Rust module (which I know nothing about) into Python. It's an incredibly powerful tool. Like having a private tutor that is always available.

There is still a limit of 50 messages every 3 hours on GPT-4 (was 25 for a couple of months), but that hasn't really been a problem. Try to ask extensive, multi-part questions each time, and it should be difficult to hit the limit even when you're starting out and need a lot of feedback.

I also ask it to analyze new code a lot, to catch little errors and get suggestions about how to do things better. Even the free tier is pretty good for that.

[Nyre221]

@RedBearAK

I think it deserves to be at least a springboard example of what ultimately becomes an official previewer for Dolphin.

I think that goal is already almost achieved.
I'll try to make a request to the dolphin developers to allow better integration with applications like mine and I'll see how it goes.

I'll try to make them understand that this is just one of the applications that could be made if Dolphin allowed more intercommunication between applications.

In conclusion, if you're aiming to make QuickView an official KDE application and want it to have a modern touch and adaptability, Kirigami is a better choice. However, it will require an investment in learning QML and its interaction with C++. If you're looking for a quicker path to a stable desktop application and are okay with a more traditional interface, QtWidgets is the way to go.

I'll probably use Qtwidget initially so I can practice C++.

So, most likely it would be quite involved to port the app from Python and attempt to do the same thing in QML/C++. It may be easier to do as it says here and start with mostly QtWidgets.

Frankly, it's not even C++ that scares me, It's QML with the Kirigami extensions. Anyway, yes, it makes more sense to start with simpler things and avoid doing everything at once.

Now I'm installing kde neon developer edition and I'll try to do some tests from there. The developer libraries (qt/kirigami) are already installed so, in theory, I don't have to configure much.

I would highly recommend that you at least try interacting with ChatGPT on a free OpenAI account.

It seems very useful and I will definitely use it in this project.

Thank you very much for helping!