On 04.03.2012 03:07, Greg Ercolano wrote:
[ ... about setting menu labels, images, ... ]
> ..which turns around *again* and tells the item that its label
> is an _FL_IMAGE_LABEL type, and to use the image as the 'text'!
> Fl_Menu_Item::label() is implemented as:
>
> void label(Fl_Labeltype a,const char* b) {labeltype_ = a; text = b;}
>
> This was surely not a design so much as a hack of some kind,
> comments say to make fluid work.
>
> I imagine that somewhere in Fl_Menu_Item::draw() this all gets
> sorted out, and the reason the text isn't shown is cause the text
> is the image pointer.
>
> This is probably a mess that needs some cleanup.
>
> Perhaps this was all done to avoid ABI issues, and perhaps now
> that we have an ABI workaround, this can be fixed properly as
> another ABI breaking feature..?
Maybe, but probably not. :-(
We should not touch internal structures (such as what the "text" pointer
is representing) if they are public in any way, although (!) we could
mark it as an ABI breaking feature. Doing so would maybe break existing
programs - we still need backwards compatibility for all public and
protected API's and all public and protected data.
Even in FLTK 3.0 we try to be backwards compatible (at least with FLTK
1.3), so this might also be difficult to handle. However, IIRC Matt
proposed to change the menu widgets anyway (make them a hierarchy of
widgets), so *this* would probably be the point to do changes like this.
A possible solution with API compatibility in mind could be to add new
methods and data items to the menu structures to support features like
images plus text in menu items, but this might introduce another point
of incompatibility if we want to do a cleanup in a later version. Sigh,
I really don't know...
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
