wine/dlls/x11drv x11drv_main.c x11drv.h palette.c
speeddymon at gmail.com
Thu Jun 16 00:16:06 CDT 2005
I'd have to agree with you guys on this one. One thing I can think of
that I would like to take on (given enough time to do it all) is create
a wiki page that I can use to document all of the fixme's, warn's and
err's that occur in the source, and then ask anyone that is contributing
code to update it when they add/remove one of those. For example, it
might be helpful to a user to know that "err:midi:OSS_MidiInit ioctl on
midi info for device 0 failed" is more of a fixme than an error, and
exactly what that "gibberish" means, so that they dont go reporting it
(making a dupe report), etc..
Dimi Paun wrote:
> On Wed, 2005-06-15 at 13:25 +0200, Alexandre Julliard wrote:
>>Yes, but it doesn't really help if the comments are not up to
>>date. I'd prefer to make sure it's dead easy to update the doc
>>directly rather than ask people to maintain comments and then have to
>>come back and sync with the doc. That may mean putting the doc
>>directly in the source, or having a wiki page than everybody can
>>update, I don't know; but I think we should be able to find a better
>>mechanism than these magic comments.
> Putting the documentation into the comments may very well be the way to
> go. But this implies putting a more embellished magic comment in. If you
> don't want it in the code, at lest we need a pointer/marker. So either
> way we need an easy to parse/grep comment.
> Personally I think that embedding the docs in the documentation is
> probably the way to go. For code related docs, I think it's the only
> feasible approach (see how successful Javadoc is).
> We can start with a just a marker and a Janitoral task of enhancing the
> markers with the appropriate markup and documentation. We just need to
> decide what to do, and document it on the Wiki. I'm sure folks will help
> out with this if there is a clear direction on where we want to go.
More information about the wine-devel