Re: GtkBindingSet etc

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,

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.

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