RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
20% Positive
Analyzed from 470 words in the discussion.
Trending Topics
#image#viewer#naming#user#application#don#gwenview#should#discoverable#kde

Discussion (12 Comments)Read Original on HackerNews
> But development on Gwenview has slowed
Good, it doesn't need constant changes.
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?
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.
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.
- keyboard shortcut configuration for basic controls such as next/previous image
- always show all meta/exif data