>> - abstraction of underlying OS libraries
> 
> not sure what in particular you have in mind, you would be reinventing 
> the wheel - there are lot of projects which already do that.

        I'm thinking he might mean abstracting things like the way FLTK
        currently has wrappers around walking the file system directories
        and searching for filenames, things the higher level core widgets
        (like file browsers) need.

>> - built in scripting via Python
> 
> Although I like Python, we do not want to make fltk dependent on it.
> Python bindings and optional scripting should be (and are) separate 
> projects.

        I'd agree, though maybe it can be one of those
        'optional core' things.

        I've always pushed for the idea there might be an
        'offical fltk extensions' library, a separate add on library
        for widgets that are 'too heavy' for the FLTK core, but stuff
        so useful most high level apps need.

        This 'official extensions package' would be a collecting pot
        of 'accepted' high level widgets like tables, trees, speadsheets,
        date inputs, ttys, callback wrappers etc. that are all more or less
        considered 'ready for prime time, usable and maintainable'.

        Basically a package where folks can offer stuff be added, and
        have it tested and voted on for inclusion, and once accepted,
        can be maintained by the person(s) that included it, or by
        anyone with access to the project.

        A nice thing would be each feature could selectively disabled
        during build, so that the app developers can download the
        whole package,  but only build what they need. This way if a
        particular widget was causing trouble on a particular platform,
        it could easily be turned off.

>> - direct support for communication like TCP/IP and serial ports
> no, this should be third party libs again...

        Agree, unless there's some compelling widget or core-ish
        thing that really needs it. (Like maybe an interprocess
        message passing system)

        Sounds like an 'extension' rather than a core item; in my world
        that would fall into the 'official extension library' described above.

>> - built in multimedia support (sound, video)
>> - simple OS support (threading, pipes, locks, messaging)
>> - maybe even a simple scene graph
> the same as above...

        Yes, ditto.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk

Reply via email to