Re: Some GValue'ization of GtkBinding

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Tue, 15 Jan 2002, Owen Taylor wrote:
> 
> > Hi Tim,
> > 
> > The following is a patch to convert GtkBinding to use g_signal_emitv() rather than
> > gtk_signal_emitv(). Could you check it over? There are two semi-significant behavior
> > changes here:
> > 
> >  A) Negative values passed to UINT typed signal parameters are now cast
> >     rather than producing an error. (Note that no errors were produced
> >     for things like longs cast to chars; we just checked this one special
> >     case of out-of-range values.) 
> 
> yep, though for some types we can do better now. reasonable checks that we
> should support there are:
> - bool: the incoming long should be 1 or 0
> - enums: the incoming long should be found in the enum class
> - flags: the incoming long should be constructable out of the flags value
> 
> >  B) Strings can no longer be used for a single value out of a flags type.
> 
> s/Strings/Identifiers/. i'd rather see the code be adapted to support flags
> regularly, than to disable the support for even a single flag value.

I'm not that keen to touch gtk_rc_property_parse_flags(),
with the GScanner use, and  it seems a little heavyweight to
create a GScanner for ever parameter, though I doubt it would
be at all noticeable in the end...

I throw in the code for a single flags value, as useless as I think
that is, and then I'll file a bug for supporting the full stuff which
we can handle when we have time. (Presumably after 2.0.0.)

> > Neither of these would be hard to fix with a bit of extra code, but
> > neither strike me as really right, so I'm a little hestitant to add
> > that code.
> 
> the point in the checks is, it's common even for programmers to screw
> up with signal parameters eventhough they have docu available and
> usually test code they write.
> but for users who adapt their key bindings in rc-files, the situation
> is even worse, i doubt a significant portion of them even thinks of
> going through the hassle to read the documentation for the signals
> they're using in bindings, so we should provide feedback on
> misconfiguration wherever possible.

I agree that warnings here would be good... I'm not that 
enthusiastic about implementing them since we have far too
many numeric types.

I'll commit as is and file bugs for adding more checking.

Regards,
                                        Owen