Re: Signal argument names
- From: Owen Taylor <otaylor redhat com>
- To: Matthias Clasen <maclas gmx de>
- Cc: gtk-doc-list gnome org
- Subject: Re: Signal argument names
- Date: Thu, 7 Nov 2002 11:32:11 -0500 (EST)
Matthias Clasen <maclas gmx de> writes:
> > It doesn't quite fit in with the way we do things elsewhere, but
> > it would be really nice if we could get the argument names from
> > the template files or inline docs instead of creating yet
> > one more file.
> >
> > That is, be able to do in the C file.
> >
> > /**
> > * GtkWidget::heirarchy-changed
> > * @widget: the object which received the signal.
> > * @previous_toplevel: The toplevel that was previously
> > * an ancestor of the widget, or %NULL if the widget
> > * was previously unanchored.
> > *
> > * Emitted when there is a chance in the hierarchy to
> > * which a widget belong. More precisely, a widget is
> > * <firstterm>anchored</firstterm> when its toplevel
> > * ancestor is a #GtkWindow. This signal is emitted when
> > * a widget changes from un-anchored to anchored or vice-versa.
> > **/
> >
>
> I have this mostly working, see the attached patch. There are some
> complications, because we have to be careful to prefer the param names
> from source over those generated by gtkdoc-scangobj (those pesky argn),
> unlike normal functions, where we prefer the names from the templates
> over the source names (why ?).
I think the idea is that it won't matter because the template
file names have to match the names found by gtkdoc-scan, or
gtkdoc-mktmpl will replace them when updating the template
files.
See, OutputParam() in gtkdoc-mktmpl
> Also, I haven't touched the automatic addition of the user_data
> parameter.
>
> Comments ?
Looks reasonable to me. I don't think the user_data parameter
should have to be documented for each signal, so leaving it
autogenerated should be fine.
> + $name = $$sourceparams[2 * $j];
Perl style note:
This is consistent with what is elsewhere, but I'll point
out that
$sourceparams->[2 * $j]
Is generally the preferred syntax for this these days; it avoids
confusing visual ambiguity over whether the above is
${$sourceparams}[2 * $j] or ${$sourceparams[2 * $j]}.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]