shiny uno version, events / signals / slots

Michael Meeks michael.meeks at suse.com
Fri Jul 13 06:53:07 PDT 2012


On Fri, 2012-07-13 at 14:27 +0200, Stephan Bergmann wrote:
> > 	Sure - tools' IMPL_LINK - would be the broken, degenerate, gross
> > case :-) More attractive versions would be g_signal or Qt's signals&
> > slots[1], I've used the rather sweet C# bindings of these too to good
> > effect; boost has a nice implementation as well anyhow checkout:
> >
> > 	http://en.wikipedia.org/wiki/Signals_and_slots
> 
> Not sure what improvements you are looking for over UNO's existing 
> listener mechanisms.

	Ease of declaration, use, type safe argument passing and succinctness.

[snip]
IDL:
	event somethingChanged([in] string aName, [in] long nValue);

C++ to emit:
	inteface->somethingChanged.emit( "foo", 3 );

C++ to listen:
	void handleChanged( const rtl::OUString &aName, long nValue);
	...
	interface->somethingChanged.connect(mem_func(*this, handleChanged));
[/snip]

	Where the C++ piece is inspired by the std::sigc bindings - which are
somewhat complicated, but potentially re-usable. The above is notably
less verbose than the existing DECL_LINK horror, and should work nicely
cross-platform too (like sigc).

	Of course, it would need/want some per-language binding work, and of
course it suffers from all the familiar intrinsic thread / ordering
problems that all existing listener methods suffer from :-) but that's
not new.

	IMHO that makes a rather pleasant contrast with the existing UNO
listener implementation logic - but perhaps I'm missing something there;
IIRC you need to declare and implement misc. interfaces on either side,
your a custom listener interface, and more (?).

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot



More information about the LibreOffice mailing list