Fl_Input_::position shadowing Fl_Widget::position

[pwiecz]

Fl_Input_::position shadowing Fl_Widget::position

[Albrecht-S]

Thanks for the heads-up.

This is true, however it would need an API change which we try to avoid as much as possible.

One possible solution: deprecate Fl_Input_::position() and add a new method, for instance Fl_Input::insert_position() to replace it (all three overloaded methods). Then we could remove Fl_Input_::position() in a later FLTK version, presumably 1.5 (or higher).

[pwiecz]

Oh, I thought that 1.4 is not considered stable, so API changes are still possible.
But I understand, that API is already stabilised.

[Albrecht-S]

Thanks for your feedback. To explain: we try to keep the API (Application Programming Interface) across all versions so developers don't need to change their program code from one FLTK version to another. You could still compile most of FLTK 1.1 code with 1.3 (with a few minor exceptions) and so you will with 1.4.

The ABI (Application Binary Interface) however is not yet final for 1.4, it can still be modified until 1.4.0 gets released, but must be constant during 1.4.x releases.

[Albrecht-S]

FTR: I noticed that Fl_Text_Display and Fl_Text_Editor (by inheritance) already have an insert_position() method. This needs to be checked and can be either

1. good, if arguments and semantics are the same (compatible)
2. bad, if not. Then we'd need another name.

This is just a reminder - code not yet checked.

[Albrecht-S]

Note: we have more than only the methods mentioned above shadowing Fl_Widget::position(). This is what I found (may not be complete):

int Fl_Browser_::position() const { return position_; }
void Fl_Browser_::position(int pos);

void Fl_Help_Dialog::position(int xx, int yy);

int Fl_Input_::position() const {return position_;}
int Fl_Input_::position(int p, int m);
int Fl_Input_::position(int p) {return position(p, p);}

int Fl_Text_Selection::position(int *startpos, int *endpos) const;

void Fl_Tile::position(int oldx, int oldy, int newx, int newy);

void Fl_Widget::position(int X, int Y) {resize(X, Y, w_, h_);}

I wonder if it's worth the effort to change any of these methods, particularly since we need to keep the API for backwards compatibility anyway, at least for some (indefinite) time and you can always use Fl_Widget::position(X, Y) explicitly.

Just thinking aloud: maybe we could add another method like Fl_Widget::set_position(int X, int Y) so users can use this instead (w/o a name conflict).

[MatthiasWM]

PR is in #666

• Fl_Browser_::position -> Fl_Browser_::vposition (mirrors Fl_Browser_::hposition)
• Fl_Input_::position -> Fl_Input_::insert_position (mirrors Fl_Text_Input)
• Fl_Text_Selection::position -> Fl_Text_Selection:: selected()
• Fl_Help_Dialog::position is ok, as it repositions the window
• Fl_Tile::position -> Fl_Tile:: move_intersection (was: adjust)
• update all includes tests

[Albrecht-S]

Fl_Tile::position -> Fl_Tile::adjust

Just for the record: isn't this Fl_Tile::move_intersection() in #666 ?

[MatthiasWM]

Yep, I changed my mind when implementing it. Fixed.