[GSoC 2012][Collaboration] ScDocFunc and Collaboration

Matúš Kukan matus.kukan at gmail.com
Tue Jul 31 10:09:45 PDT 2012

Hi Eike,

On 31 July 2012 16:54, Eike Rathke <erack at redhat.com> wrote:
> On Tuesday, 2012-07-31 15:15:18 +0200, Matúš Kukan wrote:
>> There will be new Collaboration abstract class in tubes/ and something
>> in sc/ should implement it.
> Sounds good. Designing this carefully hopefully will enable other LibO
> applications to implement it as well.


> You want the input (typing side) to send the processed input as command
> and the receiver will apply the input to the document. To be able to
> call the same methods from the view regardless of whether we have direct
> or collaborative input we need ScDocFuncDirect and ScDocFuncSend,
> otherwise we'd have to distinguish between direct and collab in each
> method.

Right, it would be about adding one 'if' into each method.

> For the receiver we need ScDocFuncRecv to process the command and send
> it as input to ScDocFuncDirect. The functionality of ScDocFuncRecv
> theoretically could be implemented anywhere, but deriving it from
> ScDocFunc gives access to ScDocShell (currently available as member in
> ScDocFuncRecv also, but see abstract base class below), and IMHO
> deriving it clarifies the relation between ScDocFunc* classes.

But currently ScDocFuncRecv is not deriving from anything and there is
just ~one method,
which is possible to move into ScDocFuncSend.
See attached diff as illustration for what I have in mind.

> Chaining ScDocFuncRecv into ScDocFuncSend in real collab mode is only
> needed for ScDocFuncSend::SetCollaboration() so could be passed there
> instead, but in dev/demo mode it is also needed in
> ScDocFuncSend::SendMessage() to emulate the broadcast, having it always
> as member IMHO is fine.

I was ignoring demo mode for now, I believe it can be solved later.

>> Also ScDocFuncDirect is just ScDocFunc with own costructor, not sure what for.
> Ideally we'll have ScDocFunc as an abstract base class later, do not
> construct the derived classes with an extra ScDocShell and have
> ScDocFuncDirect implement the then abstract methods for which
> implementation currently still lives at ScDocFunc. Just ignore that
> little indirection for now.

Sorry if that's obvious but I don't understand why ScDocFunc should be abstract.
I've never understood the comment in sendfunc.cxx:
// FIXME: really ScDocFunc should be an abstract base, so
// we don't need the rDocSh hack/pointer
ScDocFuncSend::ScDocFuncSend( ScDocShell& rDocSh, ScDocFuncRecv *pDirect )
        : ScDocFunc( rDocSh ),

How does that depend on whether ScDocFunc is abstract ( that means it
has at least one pure virtual method I guess ? ) or not ?

>> 2,
>> For class ScCollaboration : Collaboration there are two possibilities I think.
>> a, We will use just one ScDocFunc and make it work when (not)collaborating.
>> Then we can use ScCollaboration directly wiith this ScDocFunc but it
>> would complicate it a little more.
> I'd prefer if we kept the current design there (well, it's more just
> a sketch now)

sounds fine

>> I am not sure what's more ideal.. b, is probably more similar to the
>> current state but it's messing also with ScDocShell.
> I wouldn't call that messing ;)  it just switches functionality.

sure :-)

>> a, could be nicer because there would be only one ScDocFunc but that
>> may not be best.
> I actually see no benefit in having one ScDocFunc, why do you think it
> would be nicer?

Hmm, because there would be only one but that may be also (ideo)logically bad.
Depends where you want to distinguish between collaboration modes,
what ScDocFunc means ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScDocFuncRecv.diff
Type: application/octet-stream
Size: 2763 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120731/387e64b6/attachment.obj>

More information about the LibreOffice mailing list