Since FLTK2 and FLTK1 are emulated in FLTK3, there is no need to comply to 
either of the predecessors in API naming. 

At first I thought that the fltk2 naming is so much better, and it is for 
classes, but the global function names are inconsistent and annoying.

Example:

Fl_Group became fltk::Group
Fl_Tabs became fltk::TabGroup etc.

but also

Fl_XPM_Image became fltk::xpmImage, which I do not like. IMHO, class names 
should always start with a capital letter, so I changed this to 
fltk3::XPMImage, etc.


Now, with some functions, especially the drawing functions, I am very unhappy, 
and the warning about using "using namespace fltk3" suddenly makes much more 
sense.

Example 1:

Fl::args() became fltk:args(). Now if you use "using", the variable name "args" 
(and "arg") is now ambiguous. Ouch! 

Example 2:

Fl_Widget::color(c) became fltk::Widget::color(c), which is fine

but

fl_color(c), which is frequently used in a derived Fl_Widget::draw(), can not 
be fltk::color(c), because it would be ambiguous if not prepended with fltk:: 
or Widget::. Bill solved this by changing fl_color(c) into setcolor(c), but 
there is also get_color_index() vs. getcolor().

A few more bad decissions IMHO:

fl_push_clip became fltk::push_clip which is fine (the underlines keep it 
legible)

but

some new or modified functions are called setcolor_alpha, fillstrokepath, 
addvertices_transformed, etc. which make little sense to me in how they mix 
underscores.


Any suggestions on how the global function naming should be in FLTK3?


- Matthias
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to