Boris Mayer-St-Onge wrote:
> With FLTK 1.1.10 or one of 1.3.x snapshot (7677), I can't change the
> position of widgets Fl_Input and Fl_Output.
You can, you just have to beware of the name collision,
and code accordingly.
We should have some clear docs that describe the collision,
and how to work around it, at very least.
> If we look into Fl_Widget and Fl_Input_, we can see that
> Fl_Widget::position(X,Y) is a shortcut to resize(X,Y,w(),h()) but in
> Fl_Input_, the function position(X,Y) is redefined and is more complicated.
Yes, there's a name collision for position();
Fl_Input_::position() sets cursor position/text selection,
Fl_Widget::position() sets the widget's X/Y position.
Definitely unfortunate API planning ;)
I can think of two ways to solve this:
1) Documentation only: docs for Fl_Input_::position()
warn about the collision with the Fl_Widget::position(),
and show a clear example on how to access them both:
Fl_Input *input = new Fl_Input(..);
[..]
input->position(0,10); // changes
cursor position/text selection
input->Fl_Widget::position(100,100); // change the
position of widget
[..]
- or -
2) Make a new method called e.g. selection(a,b) [or
cursor_position(a,b)]
that does the same thing, and recommend its use for all *new
code*.
Move all of position()'s code into that, and make position()
a wrapper
function for it, so that we have backwards compat for old
apps.
This way new code can use the new method name and be less
ambiguous to read,
while old code still compiles and works correctly.
And, document the old position() method:
o As being the same as the above new method
o As being 'deprecated', but remaining in place for
back compatibility
o Describing the reason for deprecation (the name
collision)
o Show example code (similar to #1), noting the old
usage
with clear commenting (IN RED TEXT) to indicate it's
deprecated, eg:
Fl_Input *input = new Fl_Input(..);
[..]
input->position(0,10); // DEPRECATED: changes
cursor position/text selection. For backwards compat only!
input->Fl_Widget::position(100,100); // how to change the
position of widget
[..]
I'm -1 on *just* renaming Fl_Input_::position() though, because
even though 1.3.0 is a good opportunity to make API changes,
such a change would seem to cause more trouble than the problem
it's trying to solve.
Example: if we changed Fl_Input_::position() to another name,
existing code calling position() wanting to change the text selection
(a common operation) would now move widgets around instead,
causing them to "vanish" or become unresponsive due to stale
redraws. And no compiler errors.
> Since 1.3.x is still under development, should we change the name of the
> function Fl_Input_::position(int,int) to avoid problem like I have? It's
> strange to me that the function position(int,int) does 2 things
> completely different depending of the type of widget.
It is unfortunately named.
But name collisions in classes/subclasses can happen,
and in this case we're cursed with legacy code.
I think the goal of 1.3.x is remain as compatible as possible
with 1.1.x, and only add features and cleanup ABI stuff without
breaking the API. (UTF8 being the main one, but we slid in a lot
of ABI breaking mods)
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
