Rendered at 11:38:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
account42 1 days ago [-]
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.
Oxodao 21 hours ago [-]
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
burnoutdv 1 days ago [-]
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
torginus 1 days ago [-]
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.
jraph 1 days ago [-]
> 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.
throw-the-towel 1 days ago [-]
I don't know why, but for my needs everything except Viewnior is slow as hell.
feverzsj 1 days ago [-]
That's some really ... general name.
neilalexander 1 days ago [-]
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.
account42 1 days ago [-]
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?
kdjdjdjfjsjd 21 hours ago [-]
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.
neilalexander 1 days ago [-]
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.
varun_ch 1 days ago [-]
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.)
kdjdjdjfjsjd 22 hours ago [-]
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.
hurricanepootis 1 days ago [-]
The actual app and binary is called koko, but shows up as "Photos" cause it's named that in the desktop file.
akimbostrawman 1 days ago [-]
Things that are missing for me:
- keyboard shortcut configuration for basic controls such as next/previous image
- always show all meta/exif data
kdjdjdjfjsjd 1 days ago [-]
A decently looking KDE application? I’m proper amazed. (And I’m not even joking).
kdjdjdjfjsjd 21 hours ago [-]
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.
Melonai 12 hours ago [-]
Absolutely agree here, and this is the main reason why I'm stuck on GNOME (despite not being perfectly happy with it), and why I find it interesting how many people on the internet and here especially love using KDE so much! Don't get me wrong, the KDE project is great, and the design language has notably improved over the recent years, but I just can't get myself to use it! The constant design inconsistencies genuinely bother me, and badly! I find myself struggling to concentrate on work because I just end up staring at some uncentered object, or some misaligning lines, and I gave the whole environment multiple tries over the years. GNOME, despite it's inconfigurability and crazed decision making, genuinely figured out a strong design language across the board of all software under the project, and they enforce it heavily. I do wish I could enjoy using KDE one day though, maybe I should give it another try.
> But development on Gwenview has slowed
Good, it doesn't need constant changes.
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
Lets see if the new kid can perform here
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.
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.
KDE application naming is so consistently terrible that their default application launcher has to subtitle them with descriptions.
> 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?
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.
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.
(Minus Safari. I wonder why they went with Safari.)
This is all just conjecture though so take it with a grain of salt.
- keyboard shortcut configuration for basic controls such as next/previous image
- always show all meta/exif data
Kudos KDE Photos team.