Fabien Costantini wrote:
>> Fabien Costantini wrote:
> ./..
>>> so I believe we are quite numerous in favor of such an addon.
>>> We have some priority work to do with utf8 but I promise I would care for
>>> that one if it's in qn RFE somewhere in the 1,3 roadmap ;-)
>> Yes, I agree get 1.3 solid first.
>>
>> Though it might make ABI issues easier as the 1.3.x path evolves
>> if these methods are included as 'stubs' that just return() for now,
>
> True, but then it should be more analyzed :-)
Yes -- just tossing some names out there.
Regarding prototypes, whatever's most consistent with the current
FLTK API.
Also: thinking about it more carefully, there may actually be no
benefit to stick the method stubs in there now.
IIRC, you can always add new methods and not break the ABI,
it's just changing existing methods that's a problem. So maybe
'nevermind' on my sugg that getting stubs in there now might
actually help.
Probably Mike can weigh in on this, but I'm pretty sure adding new
methods midstream during 1.3.x won't break the ABI, it's only if we
change the prototype of existing methods.
> As an example, it is probably better to further instead of void maximize() a
> maybe a bit richer form like:
> void maximize(bool on_off) to use it for maximize and un-maximize ops.
> This way we would only have 4 get/set methods to maintain.
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(); }
> We should maybe also think about the mac platform and the possibility
> for the developer to provide 'smart' maximize operations, so probably
> it could be interesting to provide them as virtual methods ...
Yes, I suppose making them virtuals could be useful.
> Going a bit deeper in the analysis, then we could also consider
> adding new fl events (i.e: FL_MAXIMIZE, FL_MINIMIZE) and these
> methods would rely on/use them, so that that we could also handle
> them in a custom handle() method.
I guess if they're actually events that can be trapped on
all platforms. ie. if the user hits the 'maximize' button in
the border, they might be confused if the app doesn't actually
receive an FL_MAXIMIZE event. (eg. is there a way to hook into
the window manager of all platforms to get that event.. if not
maybe we shouldn't provide such a thing).
This is where the discussion goes outside of my knowledge,
as I don't know the cross platform specifics of the window managers..
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
