[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
