That is interesting for me because Gwenview comes to an grinding halt when cycling through raw files, or rather the ones I got, olympus raw files (.orf), maybe other more mainstream formats dont have that problem. When sorting photos I fell back to XnView MP but that crashes on me if I am to fast so its not optimal either.
I don't get how an app like this makes a difference. Isn't an image viewer just reading from disk, using whatever image decoding library that's standard, and copying to screen?
Of course you can get any of the above arbitrarily wrong, but supposing you don't, you have performance baseline. You can get cute and prefetch a few images or maybe downsample them and store the thumbnails somewhere, but that's something users might be unhappy about.
I don't know, can you handroll a jpeg implementation that can beat libjpeg?
Personally the image viewer I'm happiest with has been Quick Look in macOS, largely down to performance.
> I don't get how an app like this makes a difference. Isn't an image viewer just reading from disk, using whatever image decoding library that's standard, and copying to screen?
Memory leaks could happen anywhere in the process. Allocate a surface for the bog standard decoder to draw on, forget to release the surface, boom you have a leak.
It possibly doesn't help that raw files are likely to be especially heavy.
burnoutdv should report a bug if not done already.
No it really shouldn't. Try finding help with a problem with you're having with "photos". In an open source operating system you shouldn't have marketing people trying to compete for what is the one and only photo viewer or file browser so you need actual names to tell them apart.
> KDE application naming is so consistently terrible that their default application launcher has to subtitle them with descriptions.
So they are discoverable after all and that is a problem how?
It's not about fighting over the "one and only", it's about sane human-friendly defaults. A desktop environment can and should express opinions over those defaults, because they are what make or break the experience for a new or novice user. If a power user wants to swap things out, rename/disambiguate them or whatever then ultimately nothing stops them.
The subtitles are a user interface bandaid that has to exist because the naming is bad. With discoverable naming, the bandaid would not be needed. When you keep compounding bandaids, user experience breaks down.
Gwenview is already the sleek image viewer alternative compared to fully-featured programs.
> But development on Gwenview has slowed
Good, it doesn't need constant changes.
That is interesting for me because Gwenview comes to an grinding halt when cycling through raw files, or rather the ones I got, olympus raw files (.orf), maybe other more mainstream formats dont have that problem. When sorting photos I fell back to XnView MP but that crashes on me if I am to fast so its not optimal either.
Lets see if the new kid can perform here
I don't get how an app like this makes a difference. Isn't an image viewer just reading from disk, using whatever image decoding library that's standard, and copying to screen?
Of course you can get any of the above arbitrarily wrong, but supposing you don't, you have performance baseline. You can get cute and prefetch a few images or maybe downsample them and store the thumbnails somewhere, but that's something users might be unhappy about.
I don't know, can you handroll a jpeg implementation that can beat libjpeg?
Personally the image viewer I'm happiest with has been Quick Look in macOS, largely down to performance.
> I don't get how an app like this makes a difference. Isn't an image viewer just reading from disk, using whatever image decoding library that's standard, and copying to screen?
Memory leaks could happen anywhere in the process. Allocate a surface for the bog standard decoder to draw on, forget to release the surface, boom you have a leak.
It possibly doesn't help that raw files are likely to be especially heavy.
burnoutdv should report a bug if not done already.
I don't know why, but for my needs everything except Viewnior is slow as hell.
That's some really ... general name.
Naming should be general. Ask a new user whether names like Dolphin, Okular, Kdenlive, Kate, Gwenview and Dragon are even remotely discoverable.
KDE application naming is so consistently terrible that their default application launcher has to subtitle them with descriptions.
No it really shouldn't. Try finding help with a problem with you're having with "photos". In an open source operating system you shouldn't have marketing people trying to compete for what is the one and only photo viewer or file browser so you need actual names to tell them apart.
> KDE application naming is so consistently terrible that their default application launcher has to subtitle them with descriptions.
So they are discoverable after all and that is a problem how?
It's not about fighting over the "one and only", it's about sane human-friendly defaults. A desktop environment can and should express opinions over those defaults, because they are what make or break the experience for a new or novice user. If a power user wants to swap things out, rename/disambiguate them or whatever then ultimately nothing stops them.
The subtitles are a user interface bandaid that has to exist because the naming is bad. With discoverable naming, the bandaid would not be needed. When you keep compounding bandaids, user experience breaks down.
Couldn’t you just prefix your search with KDE? Search engines aren’t that bad. I like the Apple approach where apps are just named what they do.
(Minus Safari. I wonder why they went with Safari.)
The actual app and binary is called koko, but shows up as "Photos" cause it's named that in the desktop file.
Things that are missing for me:
- keyboard shortcut configuration for basic controls such as next/previous image
- always show all meta/exif data
A decently looking KDE application? I’m proper amazed. (And I’m not even joking).