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
Attachment:
pgpJ1AM8UHhax.pgp
Description: PGP signature