Albrecht Schlosser wrote:
> MacArthur, Ian (SELEX GALILEO, UK) wrote:
>>> This is a common need and trivial to code.
>> Hmm, is it though? I'm not sure... In practice, I've seldom found it
>> necessary to detect most (any?) of these things at runtime.
>
> Yes, I think so as well.
>
>>> Why not make it an FLTK class? Something like this...
>> I guess we'd accept contributions in this area.
>
> I guess we shouldn't.
>
> This would open a can of worms, add platform-specific coding,
> and would be of no use for FLTK internally. Thus, this should
> IMHO be handled in user code and not be part of the FLTK lib.
Ya, I'm -1 on this too; FLTK should stick to its goal
of being a GUI widget toolkit, and not a general solution
for cross platform programming.
That has long been a tenet that I think we'd do well to stick to.
And indeed it gets complicated to get things like OS version
info. For instance, how to tell if Microsoft Windows is
XP Pro, or Vista, or Win2k, etc. You'd think it's easy, but it's not!
It's very specific and goofy code for each OS release.
I think it's best FLTK doesn't get into that, so that old FLTK code
can still work on new OS's. But it's fine we show examples or if users
provide /external libs/ that show how to do this.
This keeps porting FLTK easy (eg. to embedded platforms) and prevents
opening up that pandora's box of people requesting e.g. TCP libraries,
thread libs, matrix math libs, etc. all become part of FLTK.
Already some of this is creeping in; we find complex widgets
like file browsers need cross platform directory walking
(opendir/readir..), and I could see e.g. robust HTML widgets
might someday need TCP (though hopefully we prevented that need
with fl_open_url())
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
