Re: [Vala] maemo5 hildon input mode



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



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