need EAPI function which get file path to set a window icon on Windows.
and EFL app can set a window icon on dynamically on Windows.
Or maybe what you want is the icons in the resource section. In that case, see
the section "How to set icons to an application".
I did that for Etui : https://github.com/vtorri/etui/blob/master/src/bin/etui_res.rc
i have created the icon with gimp (several layers of .ico)
As @vtorri pointed out, it would be nice to see how is this integrated in the rest of EFL. I would prefer if you actually complete this patch with the code needed in elementary too. I see some potential restriction here (As the image can only come from a file that is supported by Windows and that could perhaps not match our capability on X, leading to missing image on Windows that developper wouldn't detect). Basically if the loading to a pixels buffer was actually done by Evas, I would feel more confident about not having maintenance/portability issue.
Also: note that the used API is not sufficient for Windows >= Vista : https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485%28v=vs.85%29.aspx and icons of several sizes (>2) are best for some parts of Windows (configuration panel with different layout, same for explorer, and even Alt-Tab, can (should) use greater icon sizes)
elm_win: add source code in elm_win_icon_object_set() for WIN32
elm_win_icon_object_set() function doesn't work on Windows.
if the user can apply window icon using this function, it will be useful.
If it's for that, then I think that it is a wrong solution (until you have Enlightenment on Windows). The icon is part of the application, and is linked (during the link of the program)
also, there is no garantee that the icon is stored in the disk, or is in the correct format, etc...
It is the ideal way to set icon in the compilation time.
but many platform has a simple API for icon.
for example in WPF,
this.Icon = BitmapFrame.Create(new Uri(path));
if there is no icon in the disk, or incorrect format, then set basic Windows icon. and another platform can't guarantee user's mistake too.
Basically, Windows can set icon on the running time. So, another window platforms provide both APIs.
What if load fails? (i.e. the file format is not supported by Windows itself)
Can't we create a windows image handle from an evas image somehow?
Also, what is the lifecycle of those icon handles? Are they fully managed by the windows framework (ie, SendMessage() gives ownership).
ICON_SMALL (16x16) and ICON_BIG (32x32) are too small anyway for Windows >= Vista.
Should this API really be "public"? Can and should it be used outside elementary?
- WPF is another beast, which is different to win32 native API (but based on)
- you can set icon at runtime, but you must pass a .ico file. Currently there is 0% of chance you will pass a .ico. You will pass a .png 99.9%. Hence, your code will always set the default icon to your app
- if you pass a .ico, sending the message WM_SETICON will set icons of size 16x16 and 32x32 (or 48x48), which is ridiculously small
do you see any .ico file anywhere in the efl git ?
best practice, in order :
- creating an Ico file specifically for your app and use resource file to set the icon(s). It's at link time
- if you want to add some information above the icon of your app, use shell icon overlay.
- if above are not sufficient, then use SetClassLongPtr (or send a message, but i tend to prefer SetClassLongPtr), you can then create 2 icons (in term of HICON) from the elm icon. It's more complicated but a lot better than what you do. Note that you have to retrieve the icon size(e) from the system to know which size the icon should (must) have
I don't think you are currently looking at the correct icon size before setting it. That's maybe another problem to solve.
Anyway, I think you should open the icon using ecore_evas_buffer and get the image pixels. Then create a HBITMAP from it and from there convert it in an HICON. So the ecore_win32_window_icon_set would not get a path, but instead receive a buffer along with the image size. This would solve the problem where people port an application from a system that support all kind of icon extention to windows which seems to only handle .ico.
@vtorri : What do you think about my idea ?
i still claim that this API is not sufficient for large icons which are needed for windows >= Vista
the only way is using resource files. It is not possible to use an API like on linux for large icons