Hi,
Having a few thoughts about schemes and highlighting for 1.3, here is my
proposition. It is rather continuation of 1.1.x approach than that of
2.x so it should not break too much at source level.
I would like to hear your comments and if you like it, I will make a
patch and commit that.
a) Dynamic boxtype table
------------------------
Function Fl::set_boxtype(...) would check if the enumeration value does
not exceed current table size and if so, it would increase the table
size by a certain additional space using realloc(...). There would be
additional function Fl_Boxtype Fl::free_boxtype() which, unlike static
FL_FREE_BOXTYPE enumeration, would be dynamic and poin to "maximum enum
value set" + 1. Also the internal size of box_, down_box_... within
Fl_Widget must be increased at least to 16 bit (is "short" at least 16
bit on all platforms or do we need to use some config-generated 16 bit
integer type? or should we just use int?)
b) Shuffle little bit values of boxtype enumerations
----------------------------------------------------
The idea is that for all schemes the enumerations are shifted by a
certain offset. For instance FL_PLASTIC would be a constant offset
between all corresponding boxtypes, ie
FL_PLASTIC == FL_PLASTIC_DOWN_BOX - FL_DOWN_BOX
FL_PLASTIC == FL_PLASTIC_THIN_DOWN_BOX - FL_THIN_DOWN_BOX
FL_GTK == FL_GTK_DOWN_BOX - FL_DOWN_BOX
etc.
This is recently not true for rounded boxtypes and should be fixed. This
would allow easy scheming (see below) and also some systactic sugar like
use of FL_PLASTIC+FL_DOWN_BOX instead of FL_PLASTIC_DOWN_BOX etc.
After each "style" some space should be left for future additions to the
boxtypes without breaking binary compatibility again. We could probably
also remove these pesky fl_define_xxx() which are here probably as a
work arround to keep binary compatibility (or am I wrong?) but seem a
little dirty to me...
c) Addition of enumerations for clasic boxtypes
-----------------------------------------------
These would have a look of standard FL_DOWN_BOX, FL_UP_BOX... without a
scheme applied. For backward compatibility I would call them
FL_CLASIC_DOWN_BOX, FL_CLASIC_UP_BOX... and these would be used if
Fl::scheme("clasic") or Fl::scheme("none") (for backward compatibility)
is used. The "themeable" enumerations FL_DOWN_BOX, FL_UP_BOX would work
as they do now - being schemeable.
d) Use "offset" enumerations
----------------------------
Adding FL_PLASTIC, FL_GTK, FL_CLASIC (see above) which are offsets
within the boxtype table. We can also mofify
void Fl::scheme(const char *)
function to
Fl_Boxtype Fl::scheme(const char *)
so that it would return that offset. It would be also possible to add an
alternative function Fl::scheme(Fl_Boxtype offset) which would take the
offset within the table as an argument instead of "const char *" string
so that user can easily create and apply his own set of boxtypes as a
global (or per-widget) scheme.
e) Per-widget schemes
----------------------
Addition of functions
void Fl_Widget::sheme(Fl_Boxtype offset){scheme_ = offset;}
Fl_Boxtype Fl_Widget::scheme() const {return Fl_Boxtype(scheme_);}
would allow to override global scheme on per-widget basis, like
w->scheme(FL_GTK). To accomodate that scheming, we would just modify
Fl_Widget::draw_box(Fl_Boxtype b, int x, int y, int w, int h, Fl_Color
c) function which is recently used only to handle active/inactive status:
void Fl_Widget::draw_box(Fl_Boxtype b, int x, int y, int w, int h,
Fl_Color c){
// Setting active flag
draw_it_active = active_r();
// Setting scheme. If boxtype is not the schemeable,
// (above Fl_SCHEME_MAX), it is not changed.
// Global scheme has offset 0.
b = (b<FL_SCHEME_MAX)? b + scheme_ : b;
fl_box_table[b].f(x, y, w, h, c);
draw_it_active = 1;
}
f) Highlighting
---------------
Most modern toolkits can highlight a widget not only by changing color
but also widget appereance (aka boxtype). For fltk 1.3, both color and
boxtype change could be a sole property of the boxtype functions. They
could check not only if Fl_Widget::draw_it_active flag is set but also
for additional Fl_Widget::draw_it_highlighted() (by default false). This
checking is optional and depends on particular function implementation.
For instance highlighting-aware function could be implemented as
(hihglights both color and shape):
void fl_highlighted_plastic_thin_up_box(int x, int y, int w, int h,
Fl_Color c)
{
if(Fl_Widget::draw_it_highlighted()){
// changing color to brighter version:
c = fl_lighter(c);
// drawing bolder (not thin) version of the boxtype
fl_plastic_up_box(x, y, w, h, c);
}else{
// drawing normal thin version,
// also no color change
fl_plastic_thin_up_box(x, y, w, h, c);
}
}
Making widgets highlight-aware could be made in steps for each widget
class by modification of handle() and draw() methods. For instance
normal buttons could just add a HIGHLIGHT bit to the flags which would
be modified in handle() upon FL_ENTER/FL_LEAVE evens and the
Fl_Widget::draw_it_highlighted() flag would be set accoring to that in
the draw() method. Note that because only parts of a widhet could be
highlighted (like for Fl_Slider etc), this should be handled individualy
for particular class.
g) Making a highlight-example program in /test directory
--------------------------------------------------------
This peogram would derive "highlighted" slyle versions from existing
ones. The functions would use fl_lighter(c) to highlight the color and
bolder versions of boxtypes (like Fl_GTK_UP_BOX from FL_GTL_THIN_UP_BOX
etc.) This would be simple to do using template parameters to implement
the boxtype fonctions. Can we use templates (no fireworks) in the /test
directory?
Roman
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
