eye-of-gnome was nearly perfect. But the "modernization" (e.g. GTK4 and some small ux changes) made me un-usable for me. I settled on eye-of-mate but there's still a few things I'd rather change (e.g. with zoomed-in pictures you can't use left/right arrow to go to the next one in the folder because now it move the viewport of the zoomed picture).
It's really unfortunate that those UX changes are not behind flags (I would have no issue with those being turned on by default which I could revert back easily)
EDIT/ But to be fair its more related at everything related to GTK4 for me, All the GTK3-era app were amazing, now I can't stand any of them and it pretty much made me switch to QT equivalent for most of them
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?
Yes it really should. It’s much easier for users to identify what “Photos” does instead of “Koko”. It’s infinitely easier to identify at a glance what a “Files” app does versus “Nautilus”, same goes for “Epiphany” and “Browser”.
Off-the-wall crazy names only work for non-defaults because then you guarantee that those who need it will know what it does whatever the app’s called.
Your comment is the prime example of why Linux sometimes gets a bad rep for being too obtuse or inscrutable for the general public. These small things matter. They make a a real difference for the end user. And friction when trying find a single default app/utility is the last thing you want when trying to get people to use your OS.
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.
If I were to guess I’d say they went with Safari because of Internet Explorer that used to be the Mac’s default browser. In a safari tour you discover and explore, so keeping up with the discovery theme we have Internet >Explorer<, Netscape >Navigator< and Apple >Safari<.
This is all just conjecture though so take it with a grain of salt.
This was meant complimentarily, mind you. KDE apps more often than not tend to land on the “so full of options with conflicting text hierarchy, icons and weird spacing rules” that opening a KDE app sometimes feels like a risking complete sensory assault. It’s truly refreshing to see a good, competent UI that doesn’t feel like the devs just gave up and made every variable a button with some insane icon.
eye-of-gnome was nearly perfect. But the "modernization" (e.g. GTK4 and some small ux changes) made me un-usable for me. I settled on eye-of-mate but there's still a few things I'd rather change (e.g. with zoomed-in pictures you can't use left/right arrow to go to the next one in the folder because now it move the viewport of the zoomed picture).
It's really unfortunate that those UX changes are not behind flags (I would have no issue with those being turned on by default which I could revert back easily)
EDIT/ But to be fair its more related at everything related to GTK4 for me, All the GTK3-era app were amazing, now I can't stand any of them and it pretty much made me switch to QT equivalent for most of them
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?
Yes it really should. It’s much easier for users to identify what “Photos” does instead of “Koko”. It’s infinitely easier to identify at a glance what a “Files” app does versus “Nautilus”, same goes for “Epiphany” and “Browser”.
Off-the-wall crazy names only work for non-defaults because then you guarantee that those who need it will know what it does whatever the app’s called.
Your comment is the prime example of why Linux sometimes gets a bad rep for being too obtuse or inscrutable for the general public. These small things matter. They make a a real difference for the end user. And friction when trying find a single default app/utility is the last thing you want when trying to get people to use your OS.
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.)
If I were to guess I’d say they went with Safari because of Internet Explorer that used to be the Mac’s default browser. In a safari tour you discover and explore, so keeping up with the discovery theme we have Internet >Explorer<, Netscape >Navigator< and Apple >Safari<.
This is all just conjecture though so take it with a grain of salt.
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).
This was meant complimentarily, mind you. KDE apps more often than not tend to land on the “so full of options with conflicting text hierarchy, icons and weird spacing rules” that opening a KDE app sometimes feels like a risking complete sensory assault. It’s truly refreshing to see a good, competent UI that doesn’t feel like the devs just gave up and made every variable a button with some insane icon.
Kudos KDE Photos team.