Re: Problems with Properties and Notify Signal Parts

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

 



On Sun, 2005-07-31 at 12:38 +1000, Richard Cole wrote:
> Owen Taylor wrote:
> 
> >On Sat, 2005-07-30 at 14:05 +1000, Richard Cole wrote:
> >  
> >
> >>So I'm still a bit confused about where the underscores are turned into 
> >>dashes.
> >>
> >>  property names: (yes)
> >>    - registering a property
> >>    - getting a property
> >>    - setting a property
> >>
> >>  signal names: (no?)
> >>    - registering a signal
> >>    - emitting a signal
> >>    - registering a signal callback
> >>
> >>  signal details: (no)
> >>    - emitting a signal detail
> >>    - registering a signal callback
> >>
> >>One doesn't register signal details anywhere does one?
> >>
> >>I recognise that you want to stay backwards compatible, but that you 
> >>also want to be as regular as possible. So my argument is for something 
> >>regular and expected.
> >>
> >>I would argue that: signal -> no, property -> yes, is simpler than 
> >>signal name -> yes, signal detail -> no, property -> yes. Cause it is 
> >>more rules and property names sometimes get put into signal details and 
> >>so then even this simple statement of the rules is wrong. So I ask, 
> >>whose code would break if it was: signal -> yes, property -> yes? By 
> >>signal -> yes I mean that both signal names and signal details have 
> >>underscores converted to dashes, and by property -> yes I mean that 
> >>property names have underscores converted to dashes.
> >>
> >>For someones code to break from signal -> yes, property -> yes, they 
> >>would have to have details with both underscores and dashes that needed 
> >>to be distinguished. Who would need such a thing?
> >>    
> >>
> >
> >So, you proposal in particular, is that g_signal_emit_by_name() and
> >g_signal_connect() should transform _ to - in details before converting
> >the string detail to a quark?
> >
> > - The fact that details are just arbitrary strings; that they aren't
> >   constrained by all the other rules that apply to signal names makes
> >   doing that transformation a bit odd.
> >  
> > - As you say, it isn't compatible. Compatibility isn't just a "should"
> >   it's a must. Can I prove that there are people out there using the
> >   detail mechanism for things other than properties? Not off-hand.
> >   But we can't just break an API because we don't think anybody is
> >   using it.
> >
> >   Compatibility trumps consistency every time when it comes to API
> >   maintenance.
> >
> >Since there is no legitimate reason (other than the tons of example
> >code that doesn't do it right) to use "_" in signal and property names,
> >I don't think we'd gain a whole lot. Even if compatibility allowed
> >us to change the detail handling at this point.
> >  
> >
> Ok.
> 
> So am I right to believe the situation is: property names -> yes, 
> signals -> no. There are constraints on signal names, (you get warnings 
> if you violate them), but there's no underscore translation? I'm not 
> arguing for anything now, just asking to see if I have it straight.

Signal names are treated more or less the same as property names - there
might be some differences in how things like mixed - and _ work, but
the basics are the same ... you can use either - or _.

The difference is in detail strings - the thing after the :: in 

 notify::foo-bar

There is no magic in detail names, so if a detail name is a property
name (like for the notify signal) it much match the *real* canonical
property name, which has -, not _.

Regards,
						Owen

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________

gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux