pHilipp Zabel píše v Út 09. 02. 2010 v 22:44 +0100: > 2010/2/9 Jiří Zárevúcky <[email protected]>: > > pHilipp Zabel píše v Út 09. 02. 2010 v 22:05 +0100: > >> 2010/2/9 Jiří Zárevúcky <[email protected]>: > >> > pHilipp Zabel píše v Út 09. 02. 2010 v 16:37 +0100: > >> >> On Tue, Feb 9, 2010 at 3:53 PM, Levi Bard > >> >> <[email protected]> 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. :)
signature.asc
Description: Toto je digitálně podepsaná část zprávy
_______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
