Display 256x256 icons in full size

[trosh]

Windows Explorer does not handle 128x128 icons, but deals quite gracefully (at least on Win7) with 256x256 ones. I am using Keypirinha as a games launcher (amongst other uses) and enjoy using jumbo icons for game covers, but satellitesize=jumbo displays 256x256 icons as 128x128. I feel like using 256x256 display would be an improvement, and a slightly more integrated interface; at least for this specific use case.

[polyvertex]

"Jumbo" does not have the same meaning in KP (128) than for the system (256). This limitation is purely out of cosmetics concern and significant efforts have been made to render smooth 128/256 icons in KP, ending up with better results in KP than in Explorer (shell32 being bugged for some well-defined cases).

Historically, jumbo icons in KP were meant to be sized the same than the system (i.e. 256), hence the name. But after several tests, it occurred 256 was too large for common use (HiDPI excluded).

It's too late to just change the one line in the source code that would make you happy since users now rely on it, but I guess one more enum to the satellitesize setting wouldn't hurt in a future release.

Feel free to propose a choice of names for the 256 enum if you are in a creative mood :)

[trosh]

Oh yeah that's what I meant! I was just thinking of a superjumbo value or something 🙂

…

On June 7, 2018 8:18:32 AM GMT+02:00, Jean-Charles Lefebvre ***@***.***> wrote: "Jumbo" does not have the same meaning in KP (128) than for the system (256). This limitation is purely out of cosmetics concern and significant efforts have been made to render smooth 128/256 icons in KP, ending up with better results in KP than in Explorer (shell32 being bugged for some well-defined cases). Historically, jumbo icons in KP were meant to be sized the same than the system (i.e. 256), hence the name. But after several tests, it occurred 256 was too large for common use (HiDPI excluded). It's too late to just change the **one** line in the source code that would make you happy since users now rely on it, but I guess one more enum to the `satellitesize` setting wouldn't hurt in a future release. Feel free to propose a choice of names for the 256 enum if you are in a creative mood :) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #298 (comment)

-- Sent from K9-Mail on my Android device. John Gliksberg PhD student @ BuLL (Atos), UVSQ, UCLM +33640607695

[trosh]

Ok, this might be better: a scalable jumbo size which shows 128x128 as usual, unless the icon is available in 256, then shows the 256 one. This would mean leaving enough space for big icons.

In terms of name… maybe spaceship lol? Anyway I don't actually think the default display should be bigger than jumbo, so maybe something like jumboscale might describe it better.

[polyvertex]

Haha thanks for the name :)
An adaptative size feature is a no go for now unfortunately.

[trosh]

No go as in not priority or have you've come to the conclusion this is a bad idea?Quel dommage 😢

[polyvertex]

I don't think it's a bad idea but shell32 does not offer a proper API to deal with file icons. For instance it does not allow to get the original sizes of an icon, nor to get the original icon data. KP works around that partly already by extracting some icons of some types of files by itself, which allows proper icon scaling. A lot of work has been put in this already, really. However doing that for any kind of file is a lot more work for very little benefit. I.e. reinventing the wheel by doing what shell32 is supposed to do already. So as things are currently, implementing this feature would only bring inconsistent behavior unfortunately.

[trosh]

Galère ! Ok this makes sense, thanks for the reply.

[polyvertex]

The satellite_size setting now accepts the superjumbo value in v2.19