[Spice-devel] [RFC PATCH spice-gtk] Adjust SpicePortChannel method names

[Marc-André Lureau]

Hi

----- Original Message -----
> On 18 September 2017 at 15:03, Frediano Ziglio <fziglio at redhat.com> wrote:
> > >  {
> > > +    G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> > > +    spice_port_channel_write_async(self, buffer, count, cancellable,
> > > callback, user_data);
> > > +    G_GNUC_END_IGNORE_DEPRECATIONS
> >
> > Why you need to disable deprecation warnings if you are calling a
> > non deprecated function?
> 
> You are right, I originally had the functions the other way round
> (non-deprecated calls deprecated). Updated patch to follow

Ok, that could reduce a bit the churn.

> 
> > Which compilers are we using?
> > Cannot we use alias attribute (gcc/clang) or other options?
> > As far as I can see they are just renames.
> 
> In case it's not clear, in terms of the introspection interface, this
> changes these functions from e.g.
>    SpiceClientGLib.port_event(...) [an unbound library function]
> to
>    SpiceClientGLib.PortChannel.event(...) [a properly bound method of
> the PortChannel class]
> 
> 
> As far as the C interface is concerned, what you suggest should work,
> but in terms of g-ir-scanner and gtk-doc I'm not sure it's a solution.
> I don't see any mention that gobject-introspection knows about
> __attribute__(alias), and indeed
> gobject-introspection/giscanner/scannerlexer.l suggests that
> __attribute__() is silently ignored, so that isn't going to result in
> both ways being bound properly.
> 
> Equally, gobject-introspection provides a (rename-to ...) annotation
> that would make the interface right moving forward, but this would
> remove the old unbound functions in the introspected interface,
> breaking compatibility with existing code, and leaving no hint in the
> gtk-doc as to the old deprecated functions.
> 
> 
> There are quite a few others cases like this - most of the content of
> https://lazka.github.io/pgi-docs/SpiceClientGLib-2.0/functions.html -
> so if a method can be agreed, I would like to submit a series of
> patches for all the improperly bound functions.


Your approach looks good, in fact I think we used similar patches in the past. You are welcome to send a series for the remaining functions.