matthiasm <[EMAIL PROTECTED]> writes: > I find the whole idea of labels wrong. Many widgets in a UI have no > label at all, and many widgets may have pretty complex labels with > embedded symbols, images, varying fonts, undelining, etc. . We are > helping ouselves with the @-notation, complicated code, exceptions to > the rule, images that are unpredictable in alignment and so forth.
Your observations about the labels as a target for refactoring is good. However, instead of pushing the labels around, I suggest elminating the label() related stuffin fltk::Widget and making an fltk::Label standalone class. - Removes methods & members in fltk::Widget (simlifies the API). - Possibly removes need for fltk::ALIGN_INSIDE (this becomes implied) - Makes adding layouts (via measure) easier. Implementing virtual fltk::Widget::measure() is a headache specifically because widgets are allowed to have labels that are drawn outside their specified boundaries. Currently each widget has 2 geometry properties. One is the property of the actual widget (checkbox, choice stack, etc). The other is the property of an attached label which at this point can almost be anywhere it wants to be with an almost independent geometry. In this case you have: // note push button makes no sense without an integrated label new fltk::Button(0, 0, w, h, "Some Value"); // Choice stack fltk::Label * lbl(new fltk::Label(0, 0, w, h, "Label:")); new fltk::Choice(lbl->r() + 5, 0, w, h); Ugh, I wonder if the above reasoning results in too much copied code/multi inheritance type conditions. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
