Re: [Vala] maemo5 hildon input mode

[pancake <pancake youterm com>]

I wonder why nokia break gtk instead of contributing to the main  
branch or make hildon work on normal gtk.

I would suggest fixing hildon :)

On Feb 9, 2010, at 11:31 PM, Jiří Zárevúcky  
<zarevucky jiri gmail com> wrote:

> pHilipp Zabel píše v Út 09. 02. 2010 v 22:44 +0100:
> > 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.
>
> That's evil (for binding creators at least). Well, what about  
> shipping a
> modified Gtk bindings for Maemo? It would be much more natural than
> trying to fit a separate extension package on top of the original  
> ones.
>
> Just out of curiosity, will that changes get pulled to mainstream,  
> or is
> it just mission-specific stuff?
>
> > 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.
>
> Ah, then it's not so simple. Thanks for enlightening. :)
>
>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list