Le May 6, 2007 17:32, Olivier Goffart a écrit : > Le dimanche 6 mai 2007, Michaël Larouche a écrit : > > Hello folks > > > > I started to work on one point of our roadmap for Kopete 1.0 (see > > http://techbase.kde.org/Projects/Kopete/Roadmap) > > > > As a first proof-of-concept, I implemented Kopete::DeleteContactTask. > > Thanks for the work. > > > The design is to have Kopete::Contact create the DeleteContactTask with > > the correct parameter. To handle deleting using protocol specific, it add > > a sub job coming from protocol code (via protocolDeleteTask()), thanks to > > KCompositeJob, the base of Kopete::Task > > I don't see the need of having a "global" deletecontacttask with always one > subclass > Also, why does the DefaultJob inherits from DeleteContactTask , does that > mean that every FooProtocolDeleteContactTask has to inherit from > DeleteContactTask ? > > I mean, i think that the DeleteContactTask should delete the contact. the > task may have no subtask (if the protocol doesn't want to perform any > action)
Okay, how do you handle the deletion of the contact on the protocol server in
your vision ?
> > As in the future we will have many tasks that will depend on some
> > protocol code, I think a factory class to create protocol subjobs will be
> > better for a cleaner design than instead keeping adding protected methods
> > to Kopete::Contact or other classes.
>
> One factory per kind of task ? that's alot.
>
> I suggest to have a TaskManager singleton
>
> class Kopete::TaskManager {
> void emitTask( Task* t ) { emit newTask(t); }
> static TaskManager* self();
> signal:
> void newTask( Task * );
> }
>
> Task* Kopete::Contact::deleteContact()
> {
> Task *t= new deleteContactTask( this );
> TaskManager::self()->emitTask(this);
> t->start(); /* or not ? */
> return t;
> }
>
>
> FooProtocol::init()
> {
> connect(TaskManager::self , SIGNAL(newTask) , this , SLOT(slotNewTask) );
> }
>
> FooProtocol::slotNewTask(Task *t)
> {
> if(qobject_cast<DeleteContactTask>(t) && t->contact()->protocol() ==
> this)
> t->addSubTask( new FooDeletecontactTask( t->contact() ) );
> else .....
> }
>
>
> So that plugins can also add subtasks (to remove information they could
> have about this contact)
>
> I hope this will not kill performance as lots of task may be emits when
> doing bigs operations. we could add more different signals regarding task
> kind.
My idea was more like:
class Kopete::ProtocolTaskFactory
{
virtual KJob *createDeleteContactTask() = 0;
virtual KJob *createAddContactTask() = 0;
};
class JabberTaskFactory : public Kopete::ProtocolTaskFactory
{
virtual Kjob *createDeleteContactTask()
{
return new JabberDeleteContactTask();
}
};
Though your idea isn't bad either.
> > As now, the task doesn't support undo or redo, it could be added to the
> > design if we really need it.
>
> Undo and Redo would be nice. But one need at least one option to cancel
> the task (in case of error)
Proper-designed Command/Task class has a method to execute and unexecute a
task. For designing a proper Undo/Redo framework, we need to design a
load/save and recovery storage for objects implied in the framework.
At least what I figured when reading Command pattern in the book "Design
Patterns"
> > Also, some actions like removing a metacontact
> > will need to be recoded to take into account the job properly.
> > For example, the metacontact will not be removed from Kopete if one of
> > the contacts can't be deleted. We need to handle this case.
>
> yes
--
Michaël Larouche
KDE developer working on Kopete, Gamefu(KDE), Solid...on dial-up :P
--------------------------------------
Website: http://www.tehbisnatch.org/
MSN: [EMAIL PROTECTED]
IRC: irc.freenode.org/DarkShock
Jabber/email: [EMAIL PROTECTED]
pgppWj2sdeeRr.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
