It is currently September 21st, 2020, 12:41 pm

[Suggestion] Icon image support

Report bugs with the Rainmeter application and suggest features.
User avatar
jsmorley
Developer
Posts: 21376
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [Suggestion] Icon image support

Post by jsmorley »

I think I would prefer to leave extracting icons from .exe and .dll files to the FileView plugin.

I'm not opposed in principle to having the Image meter look for icons in any ImageName that has an "unknown" extension, but this feels like a lot of code for what I think is a bit of an edge case.

Perhaps when we look at converting Image meters to D2D, we might revisit this. I'm not sure we want to do this in what is old, inflexible existing code, and then do it again later anyway.

One advantage to the FileView approach is that it can solve the ImageTint, ImageAlpha, ImageRotate, ImageFlip etc. issue:

Code: Select all

[MeasureIconExe]
Measure=Plugin
Plugin=FileView
Path="C:\Windows\System32"
ShowDotDot=0
ShowFolder=0
WildcardSearch=notepad.exe
Type=Icon
IconSize=ExtraLarge

[MeterIconExe]
Meter=Image
MeasureName=MeasureIconExe
W=128
H=128
ImageTint=164,230,131
AntiAlias=1
1.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
~Faradey~
Posts: 367
Joined: November 12th, 2009, 4:47 pm
Location: Ukraine

multipage Icon image support?

Post by ~Faradey~ »

I guess this tread is appropriate for my question

Does Rainmeter fully support multipage Icon? i mean an Icon file that contains multiple sizes
i have some problems using these
and worst part is i can't recreate the problem in example skin so at this time i'll try to explain using words :confused:
i spent lot of time figuring out what may cause the problem but can't spot it at the moment and my skin is not finished and in deep WIP state...

when skin has in my case 32 Meter=Image meters and each has its own multipage Icon, they are different. On action icons are changed (scrolling effect)
icons has sizes: 32x32 48x48 64x64 and some 32x32 48x48
Icons placed in @Resources\IconCache (not sure if it is proper place)
Skin controls the size of Meters which showing the icons!

and here where the problem appears:
if meter has one of this sizes (W=32; H=32 or 48...) Rainmeter starts to change icon to whatever it thinks, it seems random, but to one of available icons. So the picture looks like this, all 32 meters has same icon! And !UpdateMeter !Radraw ... actions change the situation back to normal on brief moment :???:
but if size is different from any of available like 49x49 everything is fine, what da heck :confused:

when i create a little skin with one Meter and same multipage icon the issue is not appearing...

later i may record a video or something so you could see in action...
i'm not sure if problem in icons itself...
User avatar
Cariboudjan
Posts: 93
Joined: May 12th, 2019, 8:55 am

Re: [Suggestion] Icon image support

Post by Cariboudjan »

jsmorley wrote: September 18th, 2015, 11:51 am Perhaps when we look at converting Image meters to D2D, we might revisit this. I'm not sure we want to do this in what is old, inflexible existing code, and then do it again later anyway.
Time to revisit this? I'm trying to do exactly this. I have an AHK script that gives me the paths to all of the open programs that I would like to extract the.ico file and display in Rainmeter. I would do this with FileView but each path is to a different location, not contained in the same folder. Plus writing and reading icon files from the disk is a laggy experience on old PCs and laptops.
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Suggestion] Icon image support

Post by Yincognito »

Cariboudjan wrote: August 20th, 2020, 2:56 pm Time to revisit this? I'm trying to do exactly this. I have an AHK script that gives me the paths to all of the open programs that I would like to extract the.ico file and display in Rainmeter. I would do this with FileView but each path is to a different location, not contained in the same folder. Plus writing and reading icon files from the disk is a laggy experience on old PCs and laptops.
Reading and writing from the disk, yes, it's a laggy experience, and not just on old PCs and laptops - operating with the memory is much faster than operating with the disk no matter how you look at it (I believe this is true even for SSDs). In the meantime though, you can minimize the lag by reading/writing icon files at the time of opening a single program instead of doing that for all of the opened programs at once (assuming you open them from Rainmeter, that is). Running a program is already a laggy experience anyway since it too has to be read from disk, so adding a bit of additional lag by extracting the icon from it at (or right before the) running time is probably going to remain unnoticed to the user. You can then "cache" or "flush" the Image meters accordingly when displaying the icons of all open programs in Rainmeter, since they will be already ready for use at that moment. Just saying... :confused:
User avatar
Cariboudjan
Posts: 93
Joined: May 12th, 2019, 8:55 am

Re: [Suggestion] Icon image support

Post by Cariboudjan »

Sure. All that would be OK if the paths/icons stayed the same 100% of the time. These paths are of the applications' EXE's of those applications that are currently showing in the Windows taskbar. They change constantly, and therefor would need to be reprocessed each time the action is called. Which means writing and reading all of the time.

(Also since each icon is located in a different path, using FileView I would need separate parent measures for each icon :thumbdown: being able to use an EXE in an image meter to use its icon might improve this capability)

Honestly it would be nice if FileView could at least use icons of a file without needing to write them to the disk first. That would dramatically improve its speed, wouldn't it?
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Suggestion] Icon image support

Post by Yincognito »

Cariboudjan wrote: August 21st, 2020, 1:36 am Sure. All that would be OK if the paths/icons stayed the same 100% of the time. These paths are of the applications' EXE's of those applications that are currently showing in the Windows taskbar. They change constantly, and therefor would need to be reprocessed each time the action is called. Which means writing and reading all of the time.

(Also since each icon is located in a different path, using FileView I would need separate parent measures for each icon :thumbdown: being able to use an EXE in an image meter to use its icon might improve this capability)

Honestly it would be nice if FileView could at least use icons of a file without needing to write them to the disk first. That would dramatically improve its speed, wouldn't it?
Yep, that's true. I was going to say the same thing about doing everything in memory instead of writing them to the disk first, but then realized that it's made that way so it can seamlessly integrate with how the Image/Bitmap/whatever meters operate. Since all those meters need an image file that can be read from the disk, it was logical to make FileView write what those meters would then read (i.e. the ICO files). Changing that now is a bit overkill.

Regarding changing paths, I'm no expert in FileView but can't the Recursive=2 option be used on This PC or some other high level path so that there would be no need to spawn separate parent measures for each lower level subfolder? Anyway, it seems the C++/C# code for getting the icons you're interested in looks relatively easy, as seen here or here. The root issue I believe is the fact that this should be done in a way that integrates with how Rainmeter operates (FileView is an example, since it integrates well with Image meters, although operating FileView is a bit convoluted and/or laggy in this context) and it should be logical to the user (making Image meters extract icons from executables is probably going to be a bit confusing, since an executable is not an image file per se).

Personally, I thought about being able to extract icons from executables in Rainmeter as well and didn't even know that it was possible through FileView until now, but I would have probably avoided using the method for pretty much the same reasons as you in a "process viewer"-like scenario. In general, I think it's a bit overkill to make Rainmeter act like an operating system by replicating every bit of what Windows does (e.g. taskbar, displaying file icons, all kinds of menus and launchers, etc) and I would use it only for doing the things that the OS doesn't make comfortable for the user, but then, that's just me - folks are free to be ambitious about stuff.