[GSoC 2012][Collaboration] ScDocFunc and Collaboration

[Matúš Kukan]

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

Thanks,
Matus
-------------- 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>