Re: Units and resolution independence for gtk+

With C99 those functions could be inline (not fully aware of the C-version status in gtk+), which would lessen the impact of it being a function but a macro will undoubtedly always be faster.

2008/8/8 BJörn Lindqvist <bjourne gmail com>
2008/8/8 David Zeuthen <david fubar dk>:
> The thinking is that if the feature becomes default then the macro will
> be resolved to a GtkSize with high bits set at compile time. For 2.x,
> the thinking is that it will resolve to a function call and the
> conversion happens at run time, e.g.

In bindings the macro will always be a function call, obivously.

>  o if RI is enabled, GTK_SIZE_EM(size) will resolve to a GtkSize with
>   some high bit sets: (size | (1<<30))
>  o if RI is not enabled, GTK_SIZE_EM(size) will resolve to the pixel
>   size: size*12
> Right now it just looks like this
>  #define GTK_SIZE_EM(em) gtk_size_em(em)
> with
>  GtkSize gtk_size_em (double em);
> Is this approach a problem for binding authors?

Not a bigger or smaller problem than other macros.

The problem with macros is that they cant be wrapped automatically and
a custom wrap function has to be written (and documented) for each
binding. So you use semantically different code in bindings and
C. "gtk_hbox_new(FALSE,GTK_SIZE_EM (1.0))" in C and something like
"gtk.HBox(False,gtk.size_em(1.0))" in PyGTK and something else in

I think a function-only interface would be preferrable, unless there
are some major performance issues involved here.

mvh Björn
gtk-devel-list mailing list
gtk-devel-list gnome org

Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]