[GSoC 2012][Collaboration] ScDocFunc and Collaboration

[Eike Rathke]

Hi Matúš,

On Tuesday, 2012-07-31 15:15:18 +0200, Matúš Kukan wrote:

> I am working on moving sc/source/ui/collab/contacts.* into tubes/
> 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.

> First:
> 1, Why we have new ScDocFuncSend( *this, new ScDocFuncRecv( new
> ScDocFuncDirect( *this ) ) ); chain ?
> It could be just one class as long as it inherits from ScDocFunc I think.

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.

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. Of
course, if you have something more elegant in mind, please feel free to
express yourself :-)

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.

> 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.


> 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)

> b, We continue to use more versions of ScDocFunc depending on whether
> we collaborate.
> But then, I think, we need to use ScCollaboration with ScDocShell, so
> it has access to it's ScDocFunc and can change it.

Replacing the actual ScDocFunc* at ScDocShell shouldn't be a problem
I think.

> 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.

> 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?

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120731/9b02437a/attachment.pgp>