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
