Re: GtkBindingSet etc

[Kevin Ryde <user42 zip com au>]

Torsten Schoenfeld <kaffeetisch gmx de> writes:
> It also shuffles things around a bit.

Oh, which bits do I look at for shuffling?

> â Why call the set_name accessor just "name"?  The "set_" part might
> be redundant, but that's what it's called everywhere else.

I thought a func called set_name() which did a get name would be
confusing.  But named different from the field is confusing too.  I'll
make it set_name().  Don't think a bindingset name can be changed after
creation, so there's no set_set_name() to worry about.

> â gtk_bindings_activate_event, gtk_binding_entry_skip,
> gtk_binding_entry_remove,

I'll try to get something up for them.

> and gtk_binding_entry_add_signal are untested.

Got some stuff for that.

> I tried tackling gtk_bindings_activate_event but I couldn't
> get it to do anything.

One nasty bit is it does a ridiculous reverse lookup of the keyval, so
it will only dispatch an event it the keyval+modifiers exists in the
keymap of the display.  Which in particular means it has to be a widget
target, not an object :-(.  I was thinking of filing a bug that it
should dispatch under the given keyval+modifiers if there's nothing in
the keymap.  Maybe there's a good reason for how it is now, but as usual
the docs are threadbare.

Note gtk_bindings_activate() and gtk_bindings_activate_event() don't
depend on having bindingset stuff wrapped, so those funcs can be
contemplated separately from the present stuff.

> I think I'd prefer the integer-only approach to handling
> GtkPathPriorityType: accept and return only integers, and provide
> constants akin to G_PRIORITY_*.

I've come to the same conclusion, since you're likely to do some
comparisons, arithmetic, etc, rather than treat the levels as opaque.