On 12/29/11 03:03, Mariwan wrote: > People may code some widgets, they have a home site for some months > or years, then everything vanish since the home site goes down... > Having the files in the core of FLTK under for ex. "other widgets" > could very much be a good help for fltk users.
Agreed on that; widget sites going stale is an issue. I can see, though, where the fltk site managers might not want the responsibility of managing public project code. If a bad guy posts a large widget with some nasty code in it, and checks that in to a public fltk repo, fltk site owners may get blamed for the problem. Also managing and keeping tabs on public contributed code is a job in itself; scrubbing old junk, re-assigning abandoned projects to other people, keeping documentation and code style consistent, etc. Like herding cats ;) Perhaps someone motivated enough could start a 'public fltk widgets' site on one of the public SCMs, and the fltk core site could then link to it. (Similar to Perl's main site linking to CPAN, or the linux kernel guys linking to other projects such as GNU's unix tools) I think the core devs themselves probably don't want to take on fully managing public contributions, the same way the linux kernel guys don't want to manage the GNU tools. Although it's a shame when contributed code sites go stale, it really means the author 'gave up', and in some ways it's best such code takes a natural path to disappearing. Usually well written, desirable code has enough inertia to be reborn when abandoned. I think OkSid's utf8 patch and FLVW's table widget (which inspired Fl_Table) are good examples. But there are probably many more examples of code that fell aside that maybe shouldn't. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev