./..
>Yes, whatever's 'consistent' with FLTK's API currently would be best.
> I figure you could have all of those 'set' methods have an optional
> bool, where the default is to do what the method name says, while
> allowing an optional flag, so that an app can easily code this:
>
> win.maximize(someflag); // maximize or don't
>
> ..instead of having to do this:
>
> // maximize or don't
> if ( someflag ) { win.maximize(); } else { win.normalize(); }
Yes, that's the idea of passing a bool, but this param should not be optional
to avoid confusion with the get version of maximize() that would get the
current status. This would enforce api orthogonality
with other get/set methods infltk, i.e : value().
These 4 api could be written without to much effort, and if we consider the
user can override them to customization purpose, it could sufficeand we may not
need more internal events / finer granularity at least in a first fully working
increment.
Fabien.
Fabien
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
