Re: Some fixes

[Philip Van Hoof <spam pvanhoof be>]

During discussing this via Jabber it turned out that "into" is indeed
what I have in mind here.

MOVE parent_a->a TO parent_b->b

In this case should "parent_a" receive a delete change and "parent_b" a
create change.

changea = tny_folder_store_change_new (parent_a);
tny_folder_store_change_add_removed_folder (changea, deleted);

changeb = tny_folder_store_change_new (parent_b);
tny_folder_store_change_add_created_folder (changeb, created);

COPY parent_a->a TO parent_b->b

In this case only the create change for "parent_b".

What I was afraid of, was that the create and delete's where sent to ->b
and/or ->a. Those, however, receive a "rename" change in case of a
rename. A MOVE can be implemented using a rename in case parent_a and
parent_b are the same.

In that case I think triggering a rename change to the folder instance
is the best (deletion and creation triggers, in this case, should,
however, also work in theory and are correct by contract in my opinion
too).


If it is, feel free to commit.

On Tue, 2007-03-13 at 19:29 +0100, Philip Van Hoof wrote:
> On Tue, 2007-03-13 at 19:24 +0100, Philip Van Hoof wrote:
> > > The folder store used to create the change object was also wrong.
> > 
> > -       change = tny_folder_store_change_new (TNY_FOLDER_STORE (self));
> > +       change = tny_folder_store_change_new (into);
> > 
> > Are you sure that it should be "into" as the store being changed?
> > Because it's the parent store that is being changed, not the created or
> > deleted folder.
> 
> The folder-store that you need to pass to TnyFolderStoreChange's
> constructor is the one that is being changed. In case of deleting a
> subfolder, it's not the subfolder being deleted that changed but the
> parent of that subfolder being deleted that looses a subfolder.
> 
> Same for creations: it can't be the created one, as no one will be
> listening for that one. For the deleted one: no one will keep listening
> for that one (which reminds me to check whether in case a folder is
> deleted, that all its observers are forcefully unsubscribed too).
> 
> Not the same in case of renames. It's not the parent that notices a
> rename, it's the @self itself that feels the rename. Because other than
> a name change, nothing to @self's state changed (it's not a destruction
> nor a creation).
> 
> We can of course check this this evening a little bit more in-depth.
> 
> > On Wed, 2007-03-14 at 09:27 +0100, Sergio Villar Senin wrote:
> > > Hi,
> > > 
> > > playing with folder copies I noticed that tinymail was not notifying the
> > > UI about the deleted folder, I added the needed coded to the
> > > TnyCamelFolder. The folder store used to create the change object was
> > > also wrong.
> > > 
> > > I changed also a little bit the deleter method of
> > > TnyGtkFolderStoreTreeModel, this method was the responsible of finding
> > > and deleting the removed folder. The problem was that it was always
> > > returning FALSE, so even if you already deleted the folder the
> > > gtk_tree_model_foreach would try to continue, but it wouldn't be able to
> > > because the iter returned by gtk_tree_store_remove is invalid.
> > > 
> > > Br
> > > _______________________________________________
> > > tinymail-devel-list mailing list
> > > tinymail-devel-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/tinymail-devel-list
> > 
> > _______________________________________________
> > tinymail-devel-list mailing list
> > tinymail-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/tinymail-devel-list
> 
> _______________________________________________
> tinymail-devel-list mailing list
> tinymail-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/tinymail-devel-list