-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display 256x256 icons in full size #298
Comments
"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 Feel free to propose a choice of names for the 256 enum if you are in a creative mood :) |
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
|
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. |
Haha thanks for the name :) |
No go as in not priority or have you've come to the conclusion this is a bad idea?Quel dommage 😢
|
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. |
Galère ! Ok this makes sense, thanks for the reply.
|
The |
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.
The text was updated successfully, but these errors were encountered: