DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2563 Version: 1.3-feature Disclaimer: I don't know what the official ABI policy of FLTK is. My assumption has been that breaking existing things is a no-no but adding more stuff in a backwards compatible way is okay. The basic idea is that I will at a later point add more methods to set the icon. These will most likely take a Fl_Image and/or some platform specific format. They also need to deal better with the fact that a window needs several icons of different sizes. In order to do the above without breaking ABI, there are three things to consider: 1. The new methods cannot be virtual. 2. We cannot add any new member variables. 3. The existing methods need to continue making some kind of sense, at least for programs not aware of the new ones. The first one is simple, but the other two require the suggested patch. Since the icon_ variable is a void* and private, we can actually re-purpose it to hold something completely different, say a structure with as many fields as we need. However, with inline functions then icon_ is really a public variable (ABI-wise). Un-inlining also means that we can handle the third point gracefully as we can write conversion routines between whatever new internal format we have and the format those functions originally used. We can also turn the argument around. Why do these functions need to be inlined? They are hardly performance criticial. And inlining breaks encapsulation, which is really what the problems outlined above are all about. Feel free to shoot down my suggestions for a new icon API once I present them, but I ask you to at least give me this chance to present them without having to wait for FLTK 1.4. Link: http://www.fltk.org/str.php?L2563 Version: 1.3-feature _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
