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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
