Set icon in window title bar for MinGW? (not application icon)

[Team Prii]

To set the icon in the window title bar (not the application icon) I copied and pasted this piece of code from one of the FLTK pages:

void seticonfixed(Fl_Window *window){
//    printf("set icon fixed\n");
    Fl_Pixmap icon(favicon_xpm);
    //Fl_Pixmap icon(favicon24x24_xpm);
    seticon(window, &icon);
}

void seticon(Fl_Window *window, Fl_Pixmap *icon) {
//    printf("set icon\n");

    Fl_Window *dummyWindow = new Fl_Window(50, 50);
    dummyWindow->show();        /* needed to define a graphics context */
    dummyWindow->make_current();
    int maxDim = icon->w();
    if(icon->h() > maxDim)
        maxDim = icon->h();
    Fl_Offscreen pixmap = fl_create_offscreen(maxDim, maxDim);
    fl_begin_offscreen(pixmap);
    fl_color(FL_BACKGROUND_COLOR);
    fl_rectf(0, 0, maxDim, maxDim);
    icon->draw((maxDim - icon->w())/2, (maxDim - icon->h())/2);
    fl_end_offscreen();
    dummyWindow->hide();
    delete dummyWindow;
    window->icon((char *)pixmap);
}

This works well for Cygwin but not MinGW (nor VC). In other words when I run my program the desired icon shows up in the Cygwin version but a generic icon shows up in the MinGW version. I followed the steps in this page:

http://seriss.com/people/erco/fltk/howto-windows-app-icon.html

and then realized that it was for the application icon, not the window title icon. However I suspect there is a similar procedure to set the window title icon for the MinGW version. Please help! Thanks!

[Ian MacArthur]

On 17 Jun 2013, at 20:52, Team Prii wrote:


> and then realized that it was for the application icon, not the window title icon. However I suspect there is a similar procedure to set the window title icon for the MinGW version. Please help! Thanks!

Take a look at the Sudoku demo in the test folder; does it show icons correctly, as you would like them?

If so, just copy what it does.
Basically, you just need to use the mingw "resource compiler" to "compile" your .ico file into a binary .o file that you then link into your app like any other .o file, and you provide a basic stub .h file that describes what is in the icon file.
Your main() code then needs to read the icon from the binary blob at runtime, before you show your first window, and there after all should be well.

Take a look at the sudoku example sources to see how the icon is read in (Around line 705 of sudoku.cxx, see the use of the WIN32 LoadIcon() function.) and take a look at the test/Makefile to see how the resource compiler is invoked. (Around line 447, note the use of the resource compiler to create sudokures.o from sudoku.rc - you can pretty much use that .rc file verbatim, just change the #include at the top to point to your own name_rc.h file, which can also be copied verbatim from sudokurc.h...)

Works fine for me, with Mingw, and I get application icons, taskbar icons, window title bar (in the top left corner) icons and so forth...

Though note that you will need to create a Windows .ico file, and it will need to have a few different sizes in it to make sure there is something for Windows to display at the various different sizes. Though if there is a "near" size it will try and scale to fit, but that can often look pretty ugly!

At any rate, you will need 16x16 and a few bigger sizes, like 64x64 and 24x24 I think; Win7 likes to have some large icons too, IIRC, maybe 128x128 or 256x256 or such...

If you don't already have one, there are various tools around the web to generate WIndows .ico files from other more usual formats, e.g. from PNG files or etc. Usually, I make up a few PNG's at suitable sizes then merge them into the one .ico file for the app to use.

[Greg Ercolano]

On 06/17/13 12:52, Team Prii wrote:
> I followed the steps in this page:
> http://seriss.com/people/erco/fltk/howto-windows-app-icon.html
> and then realized that it was for the application icon, not the window title icon.

In step #6, change this line:

echo 0 ICON "../icons.windows/foo.ico" > foo.rc

..to instead read:

echo 101 ICON DISCARDABLE "../icons.windows/foo.ico" > foo.rc

..and in your code:

your_window->icon((char*)LoadIcon(fl_display, MAKEINTRESOURCE(101)));

Apparently that extra 'DISCARDABLE' in the resource is what makes
the titlebar icon work.

The relevant bit being the '101' value in both
the "101 ICON DISCARDABLE" part of the .rc
and the MAKEINTRESOURCE(101)
must match up. (The 101 value doesn't matter, it can probably be 0,
as long as it's the same in both the .rc and the code)

For reference:
http://www.fltk.org/newsgroups.php?s13795+gfltk.coredev+v13718
http://www.fltk.org/newsgroups.php?s13795+gfltk.coredev+v13723

[Greg Ercolano]

On 06/17/13 12:52, Team Prii wrote:
> I followed the steps in this page:
> http://seriss.com/people/erco/fltk/howto-windows-app-icon.html

I fleshed out the example on that page to show how to get the icon
into the title bar as well.

Just Reload that page to see the new info; an added step,
and some example code showing the context.

I verified this worked with VS 7 ".NET" on Win XP;
Not sure if it works for all Windows versions or compilers.

[Team Prii]

Thank you Ian and Greg! I followed the instructions and built the program. I found it sometimes works and sometimes doesn't. Then I found the one window that always works has  Fl::check()  following the  show() , and the two windows that only works sometimes don't have Fl::check()  following the  show() .  So I added  Fl::check()  after  each  show()  and that seems to make things work. Does that make sense or is there something wrong? Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/3kFWRLOUGw0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[MacArthur, Ian (Selex ES, UK)]

> I followed the instructions and built the program.
> I found it sometimes works and sometimes doesn't.
> Then I found the one window that always works has
>  Fl::check()  following the  show() , and the two
> windows that only works sometimes don't have
> Fl::check()  following the  show() .  So I added
>  Fl::check()  after  each  show()  and that seems
> to make things work. Does that make sense or is
> there something wrong? Thanks!

That sounds a bit odd... are you sure you are setting the icon before you show() any of your windows?

Also, I seem to recall that it helps if you pass argc/argv to the first window that is shown, i.e. do:

my_first_window->show(argc, argv);

Rather than just:

my_first_window->show();

(This may just be superstition on my part however. But if show() is called with the CLI params that first time, it does perform additional initialisation operations, that may be pertinent here.)


Though note that *all* subsequent calls of show() for any and all windows must be just show(), without the CLI parameters passed in.

Anyway, it is not really obvious what difference an extra call to check() would make at that point...

What happens if you hide() the windows then show() them again? Does that also "fix" the problem?


Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Greg Ercolano]

On 06/18/13 06:16, Team Prii wrote:
> Thank you Ian and Greg! I followed the instructions and built the program.
> I found it sometimes works and sometimes doesn't. Then I found the one window
> that always works has Fl::check() following the show() , and the two windows
> that only works sometimes don't have Fl::check() following the show() .

Doesn't sound right.

Fl::check() is just going to do a momentary version of what Fl::run() does,
and Fl::run() is what should eventually be called after all the windows
have been built.

It wouldn't hurt to check the return value of LoadIcon() for an error,
in case for whatever reason the ico files are inaccessible due to
permissions or missing ico files.

I'd look for other causes, and take the Fl::check() out, as it's probably
a sign something else is wrong.

Try making a small program that opens as many windows as you have
and assign each an icon and test with that.

[Team Prii]

Yes the icon was set before the window was shown.

I didn't know (argc, argv) need to be passed into the first window shown. I will try.

Isn't the ico file compiled into the exe file so it's not needed at run time?

[Greg Ercolano]

On 06/18/13 10:35, Team Prii wrote:
> Yes the icon was set before the window was shown.
>
> I didn't know (argc, argv) need to be passed into the first window shown. I will try.
>
> Isn't the ico file compiled into the exe file so it's not needed at run time?

Actually yes, you're right, the file is resolved during the resource compile
(res -r foo.rc), so I don't think LoadIcon() would fail due to a file error.

Must be something else.

Might still check all the values being passed in when the icon(..LoadIcon())
calls are being made though, including fl_display.

I think if you're going to have multiple icons, you probably need to have
unique numbers for each resource (eg. 101, 102, ..) so that both the .rc file
and the LoadIcon(..) calls reference those numbers.

I imagine you've done this though, as you've had some success.
Are you sure commenting out the Fl::check() makes it break,
and then putting them back makes it work? Is there anything odd
about when you're creating the windows, or is it all at once in main(),
e.g.

int main(..) {
Fl_Window *win1 = new Fl_Window(..);
..
win1->end();
win1->icon(...);
win1->show();

Fl_Window *win2 = new Fl_Window(..);
..
win2->end();
win2->icon(..);

..etc..
return Fl::run();
}

[Team Prii]

Well I just commented out the Fl::check() but now it always shows the icon correctly. I have no idea why it wasn't working the same before. Weird. Sigh.

I don't have different icons - all windows uses the same icon.

Oops I don't have end() before icon(...) . Is the end() required?

}

[Team Prii]

Update: end() is included in the code that has been automatically generated by fluid so I may be OK.

[Greg Ercolano]

On 06/18/13 11:21, Team Prii wrote:
> Well I just commented out the Fl::check() but now it always shows the icon correctly.
> I have no idea why it wasn't working the same before. Weird. Sigh.

Right, was wondering if it'd be something like that.

Sometimes one fixes the real problem without realizing it
somewhere along development.

However, to test fully, make sure you:

o Do a completely clean rebuild
o Reboot and re-run the binary (sometimes I think I've seen Explorer
"cache" icons)

> I don't have different icons - all windows uses the same icon.

I see, then that should be OK I guess.

I don't actually know much about windows, I just study to figure out
how to solve the problem, beat on it to make sure it works, publish what
I find, and summarily try forget everything about it, and refer back to my
own docs later and just copy/paste.

> Oops I don't have end() before icon(...) . Is the end() required?

No, end() isn't required, but it's a good idea for other reasons
(so that other windows/widgets don't get 'absorbed' into an un-end()ed window).

[MacArthur, Ian (Selex ES, UK)]

> Oops I don't have end() before icon(...) .
> Is the end() required?

It is not required for the icon setting and etc.

It is required that you end() and container widget though (i.e. group, window, etc.) before you create any other widget that is *not* meant to be contained by the container-widget.

So in your case, where you are creating multiple windows, it is important that you end() each window before you create the next one, or you can end up with windows nested inside each other, which is a valid option, but I don't think it is what you want!

On the other hand, I think your code is doing this OK anyway, so I don't think this is the key here.

[Manolo Gouy]

To create a window title bar icon under X11/Linux, I do as follows:

- save my icon in the xpm format in file foo.xpm

- global declarations
#include "foo.xpm"
Fl_Offscreen foo_icon;

- early in main(), before any window is shown:
fl_open_display();
Fl_Pixmap *pixmap = new Fl_Pixmap(foo_xpm);
foo_icon = XCreatePixmap(fl_display, RootWindow(fl_display, fl_screen),
pixmap->w(), pixmap->h(), fl_visual->depth);
fl_gc = XCreateGC(fl_display, foo_icon, 0, 0);
fl_begin_offscreen(foo_icon);
pixmap->draw(0,0);
fl_end_offscreen();
delete pixmap;
XFreeGC(fl_display, fl_gc);


- at each window show:
foo_window->icon( (void*)foo_icon );
foo_window->show();


Is this correct?
Is there a simpler way to achieve that?
Shouldn't FLTK give some support for that?

Thanks.

[MacArthur, Ian (Selex ES, UK)]

Hi Manolo,

I'm not sure I follow what you are doing with the Fl_Offscreen here, so you may be doing something too clever for me to understand!

Anyway, what I have in my code looks like this...

------------- code -------------------

// Set icon for window before we show it (MacOS uses app bundle for icon...)
#ifdef WIN32
main_window->icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(IDI_ICON)));
#elif !defined(__APPLE__)
fl_open_display(); // Make sure the display is available before we try and change it!
Pixmap pixmap, mask; // create pixmaps to hold the icon image and its mask
// load the XPM and prepare the mask
XpmCreatePixmapFromData(fl_display, DefaultRootWindow(fl_display), (char**)fn5x64_xpm_data, &pixmap, &mask, 0);
// assign to the fltk main window
// note that the fltk icon handling DOES NOT honour transparency,
// so we fix that AFTER the window is shown (see below)
main_window->icon((char*)pixmap);
#endif // WIN32

main_window->show();

#ifdef __APPLE__
fl_mac_set_about((Fl_Callback*)cb_about_box, NULL);
fl_open_callback(osx_open_callback);
#endif

#ifdef WIN32
// The fltk icon code above only loads the default icon.
// Here, once the window is shown, we can assign
// additional icons, just to make things a bit nicer.
{
HANDLE bigicon = LoadImage(GetModuleHandle(0), MAKEINTRESOURCE(IDI_ICON), IMAGE_ICON, 32, 32, 0);
SendMessage(fl_xid(main_window), WM_SETICON, ICON_BIG, (LPARAM)bigicon);
HANDLE smallicon = LoadImage(GetModuleHandle(0), MAKEINTRESOURCE(IDI_ICON), IMAGE_ICON, 16, 16, 0);
SendMessage(fl_xid(main_window), WM_SETICON, ICON_SMALL, (LPARAM)smallicon);
}
#elif !defined(__APPLE__) /* Not Apple and not win32 - assume Xlib */
// The fltk icon code doesn't handle XPM transparency well, work around that here...
{
// read in the current window hints, then modify them to allow icon transparency
XWMHints* hints = XGetWMHints(fl_display, fl_xid(main_window));
hints->flags |= IconMaskHint; // ensure transparency mask is enabled for the XPM icon
hints->icon_mask = mask; // set the transparency mask
XSetWMHints(fl_display, fl_xid(main_window), hints);
XFree(hints);
}
#endif // !WIN32

------------- end code -------------------

So the crux for me is using XpmCreatePixmapFromData() where you seem to have opted for just using

XCreatePixmap() instead.

Or am I missing something subtle here?

Anyway, once the window is shown, I then adjust the transparency hints and etc. for the X11 case (and in the Win32 case I load some extra icon sizes too.)

The Apple case of course just gets its icons from the bundle anyway.



> Is this correct?

It is not quite what I do, but I guess if it works, it must be correct!

> Is there a simpler way to achieve that?

I think my way is maybe simpler? Not sure... matter of opinion I guess!

> Shouldn't FLTK give some support for that?

Tricky... Every platform is different, and while Win32 and X11 might be wrapped up to look similar, I don't know if we can sort the Apple icon other than via the bundle? You would know about that better than anyone else here I'd guess?

Note that the ThinkLinc guys have posted a few patches in the STR's to try and improve the icon handling. There may be some scope for merging their patches and improving things from there?

[Manolo Gouy]

Le 19 juin 2013 à 14:07, "MacArthur, Ian (Selex ES, UK)" <ian.ma...@selex-es.com> a écrit :

> Hi Manolo,
>
> I'm not sure I follow what you are doing with the Fl_Offscreen here, so you may be doing something too clever for me to understand!

What is done in my code is just
- read the .xpm include file in an Fl_Pixmap,
- draw it in an Fl_Offscreen, which is in fact an X11 Pixmap
- give the Fl_Offscreen to Fl_Window::icon()

>
> Anyway, what I have in my code looks like this...
>
> ------------- code -------------------

> xxxxxxxxxxxxxx

> ------------- end code -------------------
>
> So the crux for me is using XpmCreatePixmapFromData() where you seem to have opted for just using
> XCreatePixmap() instead.
>
> Or am I missing something subtle here?
>
> Anyway, once the window is shown, I then adjust the transparency hints and etc. for the X11 case (and in the Win32 case I load some extra icon sizes too.)
>
> The Apple case of course just gets its icons from the bundle anyway.
>
>
>
>> Is this correct?
>
> It is not quite what I do, but I guess if it works, it must be correct!
>
>
>> Is there a simpler way to achieve that?
>
> I think my way is maybe simpler? Not sure... matter of opinion I guess!
>

Thanks for the code. Using XpmCreatePixmapFromData() is indeed simpler and also helps support transparency.

>
>> Shouldn't FLTK give some support for that?
>
> Tricky... Every platform is different, and while Win32 and X11 might be wrapped up to look similar, I don't know if we can sort the Apple icon other than via the bundle? You would know about that better than anyone else here I'd guess?

There's no such thing as a window icon in Mac OS X. What is done via the bundle concerns the program icon that
is another subject. So a common API to set window icons under MSWindows and X11 may be possible and useful.
In any case, it would be good to have some explanation given somewhere in the FLTK distribution,
possibly in one of the test applications. At present, the sudoku app shows how to deal with black&white icons,
so an example with a pixmap icon would be useful.

>
> Note that the ThinkLinc guys have posted a few patches in the STR's to try and improve the icon handling. There may be some scope for merging their patches and improving things from there?

Thanks for this info.

>
>
>
> Selex ES Ltd
> Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
> A company registered in England & Wales. Company no. 02426132
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>

> --
> You received this message because you are subscribed to the Google Groups "fltk.general" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

[Team Prii]

Yes the window creation code is done automatically by fluid and it did add end() at the end of each window so it should be fine. I will do a clean build and test on a different PC and report back. Thanks!

[Ian MacArthur]

On 19 Jun 2013, at 13:58, Manolo Gouy wrote:

>>> Shouldn't FLTK give some support for that?
>>
>> Tricky... Every platform is different, and while Win32 and X11 might be wrapped up to look similar, I don't know if we can sort the Apple icon other than via the bundle? You would know about that better than anyone else here I'd guess?
>
> There's no such thing as a window icon in Mac OS X. What is done via the bundle concerns the program icon that
> is another subject. So a common API to set window icons under MSWindows and X11 may be possible and useful.

Though the mechanism shown for X11 and Win32 sets not only the window title bar icon but also the app icon, so in that regard is analogous to what the bundle icons do in OSX. Or is it?

So... is it possible to set the app icon programatically in OSX, or does it have to be done via the bundle icons? If it can be set programatically, I guess that might be wrapped up in the same API the we might use for the X11 and Win32 icons too?

> In any case, it would be good to have some explanation given somewhere in the FLTK distribution,
> possibly in one of the test applications. At present, the sudoku app shows how to deal with black&white icons,
> so an example with a pixmap icon would be useful.

Yes, I think it is not as well documented as it could be; the docs do talk about this...

http://www.fltk.org/doc-1.3/osissues.html

And pretty much describes the mechanisms I was using, as it transpires...

I'd like to get the ThinLinc folks STR's sorted out though too, as that would make things a bit better for us; then see where we go from there?

[Team Prii]

OK I did a clean build and tested on a different PC. The icons all show up correctly. Thanks!

[Manolo Gouy]

Le 19 juin 2013 à 22:06, Ian MacArthur <imaca...@gmail.com> a écrit :

> On 19 Jun 2013, at 13:58, Manolo Gouy wrote:
>
>>>> Shouldn't FLTK give some support for that?
>>>
>>> Tricky... Every platform is different, and while Win32 and X11 might be wrapped up to look similar, I don't know if we can sort the Apple icon other than via the bundle? You would know about that better than anyone else here I'd guess?
>>
>> There's no such thing as a window icon in Mac OS X. What is done via the bundle concerns the program icon that
>> is another subject. So a common API to set window icons under MSWindows and X11 may be possible and useful.
>
> Though the mechanism shown for X11 and Win32 sets not only the window title bar icon but also the app icon, so in that regard is analogous to what the bundle icons do in OSX. Or is it?

My understanding is that, under Linux, a file foo.desktop (placed in an appropriate directory) controls what icon is used
by launchers and the applications menu. I see that as an entirely different mechanism than what controls window icons,
appearing when a window is minimized, and, with some window managers but not all, in the window title bar.
Am I wrong?

Under Win32, the same resource can be used for both kinds of icons.

Under Mac OS X, I see no equivalent of the window icon. Th app icon is normally set by an appropriate file in the
application bundle. But I believe there's also an API to change the app icon because some apps do that.

>
> So... is it possible to set the app icon programatically in OSX, or does it have to be done via the bundle icons? If it can be set programatically, I guess that might be wrapped up in the same API the we might use for the X11 and Win32 icons too?
>
>
>> In any case, it would be good to have some explanation given somewhere in the FLTK distribution,
>> possibly in one of the test applications. At present, the sudoku app shows how to deal with black&white icons,
>> so an example with a pixmap icon would be useful.
>
> Yes, I think it is not as well documented as it could be; the docs do talk about this...
>
> http://www.fltk.org/doc-1.3/osissues.html

Sorry, I had not seen that. So this is already well documented. One missing point is how to deal with icons containing
transparent areas, which requires more than calling the Fl_Window->icon() function.

>
> And pretty much describes the mechanisms I was using, as it transpires...
>
> I'd like to get the ThinLinc folks STR's sorted out though too, as that would make things a bit better for us; then see where we go from there?

Are you referring to STR #732?

[MacArthur, Ian (Selex ES, UK)]

> My understanding is that, under Linux, a file foo.desktop (placed in an
> appropriate directory) controls what icon is used
> by launchers and the applications menu. I see that as an entirely
> different mechanism than what controls window icons,
> appearing when a window is minimized, and, with some window managers
> but not all, in the window title bar.
> Am I wrong?

Perhaps...
Not all X11 WM use the "foo.desktop" style approach.
That seems to be a more recent thing, possibly deriving from KDE or Gnome or such?

Some of the older WM seem to use the "other" icon, so far as I can tell.
X11 is not as "consistent" in this regard as Win32 or OSX are...!

> Under Win32, the same resource can be used for both kinds of icons.

Yes.
Though it appears that at least *some* X11 WM may also use the icon resource loaded by the app as we outlined... Maybe...

> Under Mac OS X, I see no equivalent of the window icon. Th app icon is
> normally set by an appropriate file in the
> application bundle. But I believe there's also an API to change the app
> icon because some apps do that.

Hmm, I wonder if we could use that API to allow fltk apps to set their icon programmatically then, so that would be "the same" as the Win32 case at least?

> Sorry, I had not seen that. So this is already well documented. One
> missing point is how to deal with icons containing
> transparent areas, which requires more than calling the Fl_Window-
> >icon() function.

Yes, on both X11 and W32 there could be extra steps to deal with transparency (in the X11 case) and loading additional icon sizes (in the W32 case) that we could describe here, I think...

> > I'd like to get the ThinLinc folks STR's sorted out though too, as
> that would make things a bit better for us; then see where we go from
> there?
>
> Are you referring to STR #732?

No, I was more thinking of #2816

Also, we might want to think anyway about David Fleury's suggestion for adding an icon to fluid in #2952