| | [ Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #2340
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | X11 |
|---|
| Summary: | Allow setting both a window icon and a mask pixmap in the X11 version. |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | csaba |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | csaba
13:52 Apr 09, 2010 |
| The current 1.3 development version only allows setting a solid window icon in the X version. To get a transparent icon it is necessary to pass two pixmaps to X: the image and a pixel mask to designate the opaque and transparent pixels. Attached patch (for 1.3.x-r7473) implements this. | |
| |
| #2 | ianmacarthur
17:20 Apr 10, 2010 |
| This looks reasonable to me, and if we are to do it, I suppose it is better done now than later...? (Might be ABI difficulties if we added this later on? I'm not sure...)
Anyway, I currently do this (or, something very like this) with target specific code, so this might be a handy feature to have.
Though... I wonder if we should only call:
hints->icon_mask = (Pixmap)win->icon(1);
if (and only if) the mask is non-zero?
And, if we do set the icon_mask, should we also update the hints? E.g. something like:
hints->flags |= IconMaskHint; // ensure transparency mask is enabled
Just some thoughts... what do you think? | |
| |
| #3 | matt
17:32 Apr 10, 2010 |
| My preferred solution would be a more general way to set the app icon, but I guess I am out of luck here. IMHO perfect would be
myWIndow->icon(Fl_Image *img);
where img can be anything that FLTK understands, including a PNG with alpha channel or an XPM with transparency. The interface would be identical for all platforms, but can we fiddle Alpha and RGB out of this and generate the required data on MSWindows and X11? OS X uses an entirely different system anyway. Um, actually, now taht I thin about it, MSWindows uses resources as well... .
So maybe this should be a X11-only extension? | |
| |
| #4 | csaba
17:50 Apr 10, 2010 |
| For Ian: (1) I think setting it only if non-zero is a no-op as the field in the hints structure was zero to begin with... (2) Yeah that flag should probably be added. I did not need it, but this is probably window manager dependent.
For Matt: I also would love the generic solution. Question is what is necessary to convert an Fl_RGB_Image under all supported environments (X11, Windows and Mac) to the pixmap/resource/image format the OS expects. To me X seems to be straightforward, Windows would be trickier, and I don't know anything about the Mac. | |
| |
| #5 | csaba
18:07 Apr 10, 2010 |
| Well, did some digging on MSDN. There is a CreateIcon API function that can be used to build the icon from bitmap data. Using this instead of LoadIcon and a built-in resource could do the trick. So at least Windows and X11 could use the same Fl_Window::icon(Fl_Image *) approach. | |
| |
| #6 | ianmacarthur
02:53 Apr 11, 2010 |
| OK - I like Matt's idea, and it sounds like it *might* be feasible on X11 and win32.
I don't know if that is possible under OSX though, I only know how to set app icons via the bundle plist under OSX, so don't know if "building that in" is even possible there.
If someone had code to contribute, for any platform, I'm sure we'd be very interested! | |
| |
| #7 | matt
02:58 Apr 11, 2010 |
| It should be possible on OS X. Many applications (Mail for example) change their Icon at run time to add more information (like the number of unread EMails). You'd still have to put an application and document icon into the resources (on OS X and MSWindows) | |
| |
| #8 | csaba
07:50 Apr 11, 2010 |
| OK, I will post some code that does the Fl_Image to icon conversion on X11 and Win32. This will eliminate the need on Windows to include an icon resource in the executable. | |
| |
| #9 | spitzak
01:07 Apr 15, 2010 |
| There is a MUCH better api to set the icon used by new desktops. It takes an ARGB32 image packed into an array. Therefore it could be set directly from any fltk image.
I think there is some code in fltk2 to set it but it was never finished. | |
| |
| #10 | spitzak
14:27 Apr 18, 2010 |
| This is hardly finished but a hack was inserted into fltk2.0. The window->icon() value points at exactly the data, which is an array of unsigned. array[0] is the width, array[1] is the height, and array[2..n] are all the pixel values as ARGB. Note that as implemented this does not port to any other system, a better approach would be to use an fltk Image and set it as the icon, and use platform-specific code to extract the image and send it correctly to the system.
// FLTK2 uses the freedesktop.org new-style icons. This is an
// array of 32-bit unsigned values: w,h,(w*h)*argb, repeated
// for multiple sizes of image. Currently only a single image
// is allowed since otherwise the size of the data cannot be
// figured out...
// warning: this code assumes sizeof(unsigned)==4!
unsigned* data = (unsigned*)(window->icon());
unsigned size = data[0]*data[1]+2;
static Atom _NET_WM_ICON = 0;
if (!_NET_WM_ICON) _NET_WM_ICON =
XInternAtom(xdisplay, "_NET_WM_ICON", 0);
XChangeProperty(xdisplay, x->xid, _NET_WM_ICON,
XA_CARDINAL, 32, PropModeReplace,
(uchar*)data, size); | |
| |
| #11 | matt
12:54 Nov 14, 2010 |
| Not essential for the 1.3.0 release. Temporarily moved to 1.4 . | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
