* Interface to Telepathy Tubes.
The idea is to provide 1-1 collaboration between contacts and many-many
collaboration via MUCs, using Telepathy DBus Tubes over Jabber/XMPP.
First stab is at 1-1 contact channels, hopefully MUCs can be realized using
the same TeleConference abstraction.
To enable configure LibO with --enable-telepathy
Currently (2012-04-14) at least telepathy-glib 0.18 is needed, which doesn't
come with distributions. Download it from
and make install it locally, e.g. with --prefix=$HOME/usr
For LibO configure then use PKG_CONFIG_PATH="$HOME/usr/lib/pkgconfig
To not have tubes and sc cppunittests stumble (LD_LIBRARY_PATH is not evaluated
in unit tests and thus not a solution) copy the libs to the solver, i.e.
cp -p $HOME/usr/lib/libtelepathy-glib.* $SRCDIR/solver/$INPATH/lib/
If you have a Telepathy-enabled LibreOffice installed to /usr (including
liboapprover) you may also want to install the .service and .client files to
make everything service-activatable:
mkdir -p $HOME/.local/share/telepathy/clients
ln -s $PWD/tubes/LibreOffice.client \
mkdir -p $HOME/.local/share/dbus-1/services
ln -s $PWD/tubes/org.freedesktop.Telepathy.Client.LibreOfficeApprover.service \
Otherwise, you need to make sure liboapprover and a Telepathy-enabled
LibreOffice are running.
* Demo modes
This allows you to play with the interposing without having a telepathy
INTERCEPT=demo ./soffice -calc
Create a bit of a document, type 'saveas' with spelling auto-correction
disabled, and bingo.
* Status 2012-03-23:
* To do interesting things with this code build and run calc thus:
SAL_LOG=1 LIBO_TUBES=slave ./soffice -calc # user one
SAL_LOG=1 LIBO_TUBES=master ./soffice -calc # user two
hope that a nasty race-condition doesn't occur during startup:
which is flagged by "we are supposed to handle only one channel" you
hit it: bang - just try again.
you also require only a single jabber connection enabled (in
empathy) and to have your opponent added and approved on both sides.
Now type simple strings into cells, rename sheets, or type
'saveme' to transfer your document as-is to the other side ...
* Status 2012-03-20:
* no LibO code depends on this module yet, so it is not built in a regular
build, even if configured with --enable-telepathy, so cd tubes and make here
* to enable the various SAL_INFO and SAL_WARN messages emitted during
cppunittest pass SAL_LOG=... and do a debug build
* SAL_LOG="+WARN+INFO.tubes" make -rs debug=true
* the cppunittest will currently fail anyway (even if it wouldn't for other
reasons), this is on purpose to be able to see the output as otherwise it
is silenced down ... :-(
* for the cppunittest needed:
* Configure two Jabber accounts in Empathy
* Both must be online and on each other's contact list
* Copy qa/test-config.ini.example to qa/test-config.ini, and specify those
two accounts' JIDs in it.
* very nasty GMainLoop handling for cppunittest, HOPEFULLY we will get rid of
that in a real LibO
* contact channels are setup
* tube is offered/accepted
* packets are sent and received
* cleanup code to use a refcounted single instance thats holds mpAccountManager
and stuff and actually releases them, instead of statics
* TeleManager should be a single instance, not holding any account information;
instead, the start...Session() methods should also get the account passed
* implement master/slave mode in 1-1 buddy conferences, master would do strong
* associate a document with a conference
* use SfxObjectShell as an abstraction and broadcast incoming changes?
* use UNO API?
* first setup just to get something working could share a document
accessible by all parties on a network share or some such
* may need one master responsible to save the document
* later document transfer will be needed, use Telepathy File Transfer
* dialog to pick own account
* dialog to pick contact or MUC to work with
* dialog to accept/reject collaboration requests
In applications, e.g. Calc:
* stricter model,view,controller
* disable all actions we cannot process collaboratively
* separate input from view
* preprocess input to determine data type (text, number, date, ...)
* send typed/categorized data over wire before actually processing in model
* process serialized input as received
* Calc specific:
* use existing shared document feature with change-tracking enabled to
* may have the benefit of having already only a subset of trackable change
* let ScDocFunc handle also received changes
* have dialogs send their result item sets over the wire