[openbeos] Re: bounties for the new website...

  • From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 31 Aug 2006 11:35:21 +0200

> From: "Fredrik Ekdahl" <fekdahl@xxxxxxxxx>
>
> Here are some suggestions for bounties:
>

[...]

> Finish OpenGL add-on framework
>
> OpenGL software renderer
>     Adopt the software renderer to the new GL add-on API and update
>     mesa

Yep. I've yet to find free time to finish these tasks but all are mandatory.
Additional task: OpenGL nVidia renderer add-on. Aka adapt Rudolf's 3D driver to
the new GL add-on API. Except I've no nVidia card. Beside no free time, I mean
:-(

[...]

> CD/DVD burning application

Both libburn (recently forked/restarted) and cdrecord could provide enough help
to add some Disc Recording capabilities to our storage kit, beyond R1. Still,
for R1 we have to provide something like Be's CDBurner... a
cdrecord/dvd-tools/[grow]isofs frontend ?

I guess the quite enhanced Haiku Disk API should help here, regarding volume
building, resizing, needed size computation. We need to be able to build on the
fly an BFS image, for best backup experience...

These are more 3rd parties opportunities than Haiku mandatories:

> Scanning application
>     Maybe Sanity could be acquired

No problem, I've licensed Sanity under MIT. Most of this crap app needs to be
rewrite anyway, as it's a pretty ugly code (as usual). And without scan area
widget, it's a very dumb tool. Today scanners speed hide this more than in the
past, though (full scan at highest resolution -> ShowImage -> crop -> save
selection...).
But Sanity require SANE port, so what about:

> SANE port
>     Or is this already up to date? In that case, could it be included?

I think François Revol patch was accepted by SANE project, so it should be
up-to-date. But SANE comes with some unix way that is not really the BeOS way.
Like these settings files to tell each driver how to find their scanner. It
should be more autodetection based.

> We might not want to add SANE to SVN as it already has a public repos,
> I don't like forking stuff.
> We can probably provide external scripts or makefiles to cvs co &&
> configure && make && zip.
> I actually integrated it into Zeta's build system once so it's
> possible.
> Some kind of "haiku-ports".

Hum, I think we prefer to import in /vendors as-is but fully every external
stuffs we needs to build or use in Haiku and branch in our /trunk, adding
Jamfiles to build them.

PS: Hello guys, I'm back from summer "new baby" vacation.

Other related posts: