Closed vkareh closed 10 months ago
I still got the application icons and not the document/photo thumbnail icons with atril and eom with this installed. Other than that seems to work fine
Just testing, looks good so far. Is there an icon cache which needs to be delete first for proper testing? Or any other test case for this PR?
Any way to bring back file thumbnail icons in such apps as eom and atril with this?
For proper testing i like to know. Which icons are blurred in eom/atril ? A screenshot describes more than thousand words :)
In my workflow, none of the window icons are blurry with marco from current git master, even with a 4K monitor. All the window icons are clear and sharp, including thumbnails for pdf, jpg files etc. I only use a few filetypes with eom and atril however.
Eom and atril icons are in hicolor direktory. Utilies-terminal for mate-terminal is in mate-icon-theme directory for example. Maybe this makes a different? Any way, i am using mate-icon-theme and i do not really see the blured /eom/atril windows icon with hidipi and Blue-submarine marco-theme with my old eyes and glasses.
What's the status of this.
@lukefromdc Ok now i know what you mean with the file thumbnails. But for me this thumbnails are too small for a picture in eom, tested with blue-submarine theme. I can't recognize any different to a thumbnail from another picture. But maybe your eyes are better than mine. Also i see the picture itself in eom. Should be the same with atril.
@lukefromdc ...really a blocker for you?
Blocker no, just not a change I would have done on my own. Like I said, not my call on how important the per-file icons are for eom and atril. Not sure if users would miss them and file bug reports though.
@vkareh @lukefromdc Is that change possible?
Edit: So this change does not improve something? Icons are not sharper? We only lost previews (which are pixel mud for me= before & later)?
I simply do not know. Again, not endorsing nor blocking. EDIT: on my setup the preview icons are usable, if there are lots of cases where they cannot be read (which may depend on the file) this may be an improvement for those users. Not an improvement for me, but MATE is a major DE with a great many users so that may not be a consideration.
Note that metacity still has the previews, we can look there for how it is done if we want to keep them(as this is only the icon handlng) even though the decorations as a whole are entirely different
Ok, i will test commit for myself again if this commit improve sharpness, because this is the question... But do you really recognize a picture with the preview? For me with damaged eyes it looks like pixel mud in your screenshot.
Any way, i will do a new release without it, not important enough for me.....
I recognize them no problem, my vision is at it's best from computer screen range out to about 4 feet
No image reduced that small or simply scaled that far is SHARP unless it was either created that small or is something like an .svg (or we would not have so many icon handling issues w 4K etc), but with my vision it's not pixel mud either and is easily recognized compared to the contents of the window
Good, than the problem are my old eyes :-)
In a quick test i do not see a different in sharpness of icons, eg. pluma or others of my default applications. The icon of caja will be changed, not bad for me..... . In result this isn't important for me as said before. @vkareh you should start to argue for yourself
@vkareh you should start to argue for yourself
I'm not a fan of this change myself. What it does is ignore the window prop hints and relies on the program name and questionable string matching to see if there's a desktop file it can see. It's not always accurate, though, and gets rid of thumbnails.
I think this should be closed.
Looking up GDesktopAppInfo from the window name we can get a much better match for the icon and load it at the appropriate scale. This results in matching icons to straneous windows and better looking icons overall.