Re: [Vala] maemo5 hildon input mode

[pHilipp Zabel <philipp zabel gmail com>]

2010/2/9 Jiří Zárevúcky <zarevucky jiri gmail com>:
> pHilipp Zabel píše v Út 09. 02. 2010 v 22:05 +0100:
> > 2010/2/9 Jiří Zárevúcky <zarevucky jiri gmail com>:
> > > pHilipp Zabel píše v Út 09. 02. 2010 v 16:37 +0100:
> > > > On Tue, Feb 9, 2010 at 3:53 PM, Levi Bard
> > > > <taktaktaktaktaktaktaktaktaktak gmail com> wrote:
> > > > > > While this is indeed correct workaround, the Hildon binding should
> > > > > > probably be updated (so you get type-checking from the compiler).
> > > > >
> > > > > In that case, can that be a different vapi so that we can still use
> > > > > hildon-1 with diablo (maemo 4.x)?
> > > > > Or at least keep the legacy version as hildon-1-diablo.vapi or something?
> > > >
> > > > These are Maemo specific changes to GTK+ (properties of Gtk.Entry, not
> > > > of Hildon.Entry). This lead to the slightly awkward Hildon.gtk_...
> > > > helper functions. I forgot to wrap all of them - here is a patch that
> > > > adds the missing Hildon.gtk_entry_... functions to
> > > > hildon-1-custom.vapi.
> > > >
> > > > The helper function in question is Hildon.gtk_entry_set_input_mode
> > > > (Gtk.Entry entry, Hildon.GtkInputMode mode). I guess we could also
> > > > manually add the hildon-input-mode property without accessor methods
> > > > to Hildon.Entry, but this is the official API.
> > >
> > > You could manually specify the names of the accessors. Is there any
> > > valid reason for binding those as ugly static methods except being
> > > "politically correct"?
> >
> > Vala doesn't let me add methods to Gtk classes from hildon-1.vapi.
> > Changing upstream gtk+-2.0.vapi for a vendor specific modification
> > doesn't seem right. What would you suggest?
>
> I would suggest that adding vendor specific modifications to existing
> classes is way too ugly

Agreed.

> to be accepted and you should bind it to hildon
> classes. How can they even add more properties to an already defined
> class?

They ship a modified GTK+ library. Hildon depends on that.
I guess we could get away with just binding the hildon_gtk_entry_*
methods to Hildon.Entry instead of Gtk.Entry. Is there a way of doing
this via metadata before the vapigen step?
But there are a few others like hildon_gtk_widget_set_theme_size or
hildon_gtk_window_set_progress_indicator that can't be mapped to
Hildon classes, as they are needed to work on Gtk.Button and
Gtk.Dialog, for example.

regards
Philipp