Re: Need approval to submit a patch



> First of all the main reason there isn't a function for this is that
> with the new gdbus-codegen(1) tool, this is automatically handled.
> That was always the plan and it's why pre-gdbus-codegen(1) is so
> low-level.

I've looked at gdbus-codegen(1). I also extensively use GStreamer.
When my pipeline changes, I have to update several variables at one
time, as they should be considered atomic. It means, that I want to
send notification signal with all of them, at one time. I see no way
how it could be automatically handled by gdbus-codegen(1).

In more complex applications there always would be situation like one
described above. It would be nice to have convenient function to
*send* such custom signals. Example shown here:
http://people.freedesktop.org/~david/gio-gdbus-codegen-20110412/gdbus-example-gdbus-codegen.html
currently covers only automatic *receiving* PropertyChanged signals.

> Is this really shorter than?
>
(...)

Yes, and it follows DRY paradigm.

> For starters, I don't really like varargs functions because they are
> not available to language bindings (GVariant is an exception and we
> can assume each language will bind it separately). And I just don't
> think it's that much shorter than the code I pasted above... and with
> gdbus-codegen(1) it's kinda a non-issue because it happens
> automatically.

As I wrote above, length of the code is not the case. DRY is the case.
Do-Not-Reinvent-The-Wheel is also the case.

And as far as I understand, gdbus-codegen provides only tool to handle
receiving of such signals.

> g_dbus_connection_emit_properties_changed_signal() method that takes
> two GVariant* (GVariantBuilder is probably not bindable) instances,
> then you can insert g_variant_builder_end() calls at that place? That
> should be bindable...

To be honest, I do not understand what "bindable" means  in this context ;)

m.


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