[Changing the subject a bit to avoid a thread jack] On 03/25/13 09:25, Roman Kantor wrote: > Somewhat related, it would be nice if fl_add_symbol() would accept not only > drawing functions > but also images, even without additional scaling and rotations. > In the symbol table there is an "int" flag field (at the moment this flag is > used only > with values 0/1 to indicate scalable and non-scalable symbols), other > value could indicate that the pointer in the internal table is an image (or > other object), > not the function and have to be interpreted differently. This can be > done by overloading fl_add_symbol() which would set appropriate flag.
+1 from me -- sounds like a good approach, and I understand that even though the symbol draw function can draw images, this won't scale well when you have a lot of images (one func per image). Making additional fl_add_symbol()/fl_remove_symbol() methods to accept an image pointer and having those internally make use one of the unused bits in the integer bit flag sounds like a good approach. > Alternative approach would be that for instance "@" convention would accept > something like > "@file:///my/shared/image.png My Label" I prefer the image pointer approach for the reasons you mentioned, and just it's better for modularity to have the image class handle all the image related stuff. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev