| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2816
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | OS support |
|---|
| Summary: | Add ability to set proper window icons |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | ossman |
|---|
| Assigned To: | ossman |
|---|
| Fix Version: | 1.3-current (SVN: v10197) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | ossman
01:54 Mar 27, 2012 |
| The existing icon system is a bit crude and doesn't really live up to modern expectations. The attached patch adds the ability to set full color icons (via Fl_RGB_Image) on Windows and Unix (OS X doesn't generally have per-window icons).
On Windows you can also specify HICONs to simplify integration with the icons embedded in the exe.
Patch is against the stable release (when are we getting 1.3.1? ;)) | |
| |
| #2 | astrand
05:40 Jun 19, 2012 |
| Updated patch for latest trunk. I think this patch is important because it means that FLTK apps can look better, and people cares about that. | |
| |
| #3 | astrand
06:01 Jan 16, 2013 |
| fltk-1_v3.3.0-icons.patch has been adapted for FLTK 1.3.2. Only offset changes. | |
| |
| #4 | ianmacarthur
06:21 Jan 16, 2013 |
| The patch looks OK to me, but I worry it may be ABI breaking?
If so, we'll need to put ABI guards around it to stop it breaking any builds that are using dynamic loading of the fltk libs...
Thoughts? | |
| |
| #5 | greg.ercolano
10:35 Jan 16, 2013 |
| @Ian: Let me preface by saying I had a weak coffee this morning, so I might be missing something obvious..
I see you're point.. re: 1.3 to me the scary bit is:
- const void* icon_;
+ struct icon_data *icon_;
..in Fl_Window.H
Memory-wise, both end up being pointers, so maybe it would squeak by..?
It appears to be private, so no worries about it being referenced by user code.
I don't think there are changes to the signatures of public functions,
and all the code mods are in .C files.
But someone more awake than I am right now should weigh in.. | |
| |
| #6 | ianmacarthur
11:33 Jan 16, 2013 |
| @Greg:
Quite probably - I'm quite happy to be wrong about ABI issues here, which is really why I flagged it up, so that someone who knows what they are talking about (rarely me) can say!
It seems worth having, so if it will fly right, we should do it... | |
| |
| #7 | greg.ercolano
16:31 Jan 16, 2013 |
| @Ian: Right, I feel the same way. Would like to see Albrecht or Matt weigh in.
OP, feel free to comment as well on the ABI issue with respect to your patch(s). Thanks for all your work on this BTW; it is appreciated.. we just have to be careful we don't break ABI, as we're still in the middle of a patch release stream, ie. 1.3.x. | |
| |
| #8 | ossman
07:52 Jan 21, 2013 |
| This patch is ABI safe as it adds no new virtual functions, doesn't modify the behaviour of existing functions or public members of the class, or changes the memory layout of the class.
Pointers are always the same size, so changing their type does not modify the storage. And as you said, this is not a public member. | |
| |
| #9 | ianmacarthur
13:10 Jan 21, 2013 |
| This being so (the ABI safety of said patch) then I think this would be good to add... What do others think? | |
| |
| #10 | ossman
04:39 Jun 16, 2014 |
| Fixed in Subversion repository. | |
| |
| #11 | manolo
18:32 Jun 17, 2014 |
| Here, with mingw-gcc 4.3.2, file Fl_win32.cxx does not compile because
BITMAPV5HEADER is not found.
(On another computer with mingw-gcc 4.7.2, it compiles without problem).
Would it be possible to do the same with BITMAPV4HEADER instead
that is known by more gcc versions, as packaged by MinGW ? | |
| |
| #12 | ossman
00:42 Jun 18, 2014 |
| Possibly. Would have to test it.
But mingw-gcc 4.3.2 is absolutely ancient. What system still includes that? | |
[ Return to Bugs & Features ]
|
| |
