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)
> 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.
>
> 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)
> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
