Greg Ercolano wrote:
> Would it make sense to make a new method that does the following
> common coding pattern to find the inside area of a widget:
>
> int X = yourwidget->x() + Fl::box_dx(yourwidget->box());
> int Y = yourwidget->y() + Fl::box_dy(yourwidget->box());
> int W = yourwidget->w() - Fl::box_dw(yourwidget->box());
> int H = yourwidget->h() - Fl::box_dh(yourwidget->box());
Actually there was some discussion about unification of boxtpes, images
& symbols, making highlighting etc. I started very preliminary hack
with common base for boxtypes, images and symbols with a virtual method
inset() similar to that in fltk2 but with much simpler base class with
only three public functions(apart from const/dest): draw(), inset() and
flags():
class Fl_Symbol {
static int current_flags_;
int flags_;
public:
// Supported flags:
enum Flags{
INACTIVE = 1, // can draw inactive on its own
HIGHLIGHT = 2, // can draw highlifgted
INVISIBLE = 4, // can not to draw - ie to be used with OVERLAY
OVERLAY = 8 // can draw eg better "focus" - (for round box, ...)
};
protected:
void flags(int a){flags_ = s;}
Fl_Symbol(int flags):flags_(flags){}
public:
static void set_flags(int f) {current_flags_ = f);
// Returns supported flags.
/* This can be used for questioning of the capabilities,
setting global flags etc, like: if supported;
set the flags and draw, otherwise do some fallback:
if(Fl_Symbol::INACTIVE & box()->flags()){
Fl_Symbol::set_flags(Fl_Symbol::INACTIVE);
fl_color(color());
box()->draw();
Fl_Symbol::set_flags(0);//must be always switched back to ZERO
}else{
fl_color(fl_inactive(color());
box()->draw();
}
Similar for drawing focus overlay: if supported, set flags to
INVISIBLE|OVERLAY and draw, otherwise use standard draw_focus()
function. Similar for highlighting...
*/
int flags() const {return flags_;}
// Gets the inner area without border etc...
// See also Fl::box_dx() & friends...
vitrual void inset(int &x, int &y, int &w, int &h) const {}
// Draws the thing: for backward compatibility the last
// color argument for "normal" boxtype functions is taken from
// current color set as returned by fl_color().
virtual void draw(int x, int y, int w, int h) = 0;
virtual ~Fl_Symbol(){}
}
Now the inset() function would do more-less the same as you suggested
but the syntax would be:
int x, y, w, h;
widget->box()->inset(x, y, w, h);
and for "no border" boxes it would just live the values in x, y, w, h
untouched.
Old boxtype would be just
typedef Fl_Symbol * Fl_Boxtype;
and implementation of backward-compatible Fl::box_dx()... would be:
int Fl::box_dx(Fl_Symbol *s){
int x = 0; y = 0; w = 0; h = 0;
s->inset(x, y, w, h);
return x;
}
int Fl::box_dx(Fl_Symbol *s){
int x = 0; int y = 0; int w = 0; int h = 0;
s->inset(x, y, w, h);
return y;
}
int Fl::box_dw(Fl_Symbol *s){
int x = 0; int y = 0; int w = 0; int h = 0;
s->inset(x, y, w, h);
return -w;
}
int Fl::box_dh(Fl_Symbol *s){
int x = 0; int y = 0; int w = 0; int h = 0;
s->inset(x, y, w, h);
return -h;
}
and which can be translated as:
"Give me reasonable expectation of the inset border (change) if the
drawing size is unknown, (which you could say is indicated by zero width
and/or height passed to inset())"
But the use of these backward-compatible calls in fltk core should be
later replaced rather by direct call to inset() for performance reasons
(single call to the function).
So all in all I would leave this api change for 1.4. I'll try to finish
this fork in reasonable time(yeah everybody's busy), we will see how
many things this breaks and you could then consider if it would be OK to
incorporate something like this or not.
R.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
