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 to be accepted and you should bind it to hildon classes. How can they even add more properties to an already defined class?
Attachment:
signature.asc
Description: Toto je digitálně podepsaná část zprávy