Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


Hi Eike,

On 16 July 2012 15:16, Eike Rathke <erack@redhat.com> wrote:
Do things work in any way now when the .client files are not installed?

Sure, like always. Registration now happens in TeleManager::registerClients()
So, if you run libreoffice and click Listen in contacts dialog,
telepathy clients are registered and you can accept connection.

We'll need the MUC be configurable and not hardwired anyway. And both,
1-to-1 and MUC collaboration, should be possible. So extending the
dialog for MUCs will be inevitable ;)

Hopefully I have improved the dialog now. It should be more usable.

With the current setup it is impossible to run against a local jabberd
that is not connected to the outer world.. in fact I pulled the changes
and now can't test anything.

Hmm, pull again and hopefully when you do Listen in one soffice and
startBuddySession in another, it will work.

Btw, the contacts list when opened is not populated until the Listen
button is clicked once and the contacts dialog opened again.

I've changed this.
It was not good, I think, to have listed only contacts with
contact_supports_libo_dtube true.
Because later we want there also contacts without libreoffice running
but with installed .service and .client files.
And I am not sure whether it was working the same way. (if telepathy
reports them as supporting dtubes).

    There is no other case when someone sends us file ?

Currently not. Maybe we could distinguish between a "send file" and
"send file for collaboration" later.

    I am not sure how to do this. Some class alive as the whole
./soffice is running could help.

But that did already work with the "saveme" hack, or do I lose track
here?

To receive a file should still work if you begin 1-1 collaboration.
But it will be just new file, not meant for collaboration...

    But still, after receiving new channel [4], I need to accept it,
receive the file and then bind the channel to that file ?

Yes. But also that (except accepting) worked already, if I'm not
mistaken.

...It has worked because every document was meant for collaboration
through TeleManager.
But now the document is bind to TeleConference only if it's being
collaborated on.

The file / channel handling code must be general and be able after
receiving a file
to know which channel bind to it and then tell the file about collaboration.

I have no idea how to set anything for that new, received document.
The code in ScDocFuncRecv::fileReceived is magic for me.
Also note that it's in wrong place. If I understand it correctly it's
not related to any session.
Libreoffice as a whole is something able to accept the signal about
to-be-received-file.
I was tempted to move the code from ScDocFuncRecv::fileReceived
directly to TeleManager::TransferDone
but it would require tubes to link against more libraries etc. so I
let it be for now.

- Also unit test is broken

Hum.. why that? It didn't break here, or is it the slowcheck
subsequenttest?

It's disabled as discussed on irc.

Should I start working on side-bar widget we can dock ? Any hints?
But I think that we need to improve receiving channels and files,
handle TeleManager properly and everything related.

Please work on the channels and file receiving internals first, widget
eye candy can be added later.

Sure, but sometimes it's handy to have more topics at hand in case I
don't know how to continue with something. To switch a work can be
useful.
Removing from unusedcode.easy is always an option ;-)

Hope you can parse this, I am loosing myself,

Seemed to do ;-)

Thanks :-)

Matus

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.