RE: Missing API and API that needs improvements

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-08-24 at 13:47 +0300, Dirk-Jan Binnema nokia com wrote:

> "_by_header"? What should that do?
> 
> And there should be error handling, at the very least a gboolean
> return value, but probably some error code.

To be honest, I haven't yet put a lot time in the message-transfering
API ideas. Feel free to cook something (different) together.

ps. It would be great if you could use the wiki for that.


> void tny_folder_store_iface_remove_folder (TnyFolderStoreIface *self,
> TnyFolderIface *folder);
> TnyFolderIface *tny_folder_store_iface_create_folder
> (TnyFolderStoreIface *self, const gchar *name);

> Same here, they need error handling. And I guess you'd need the parent
> folder as well for these functions.

Ahaaaaa but there you miss the ball. TnyFolderStoreIface is that
instance! But note that it can also be a TnyStoreAccount. Both are
suitable as parent to remove a folder from. There's two implementations
but one API. Simple for the developer.

> You seem to like out-params... Can't they return the list as the
> return value?


No. Because then you can't choose the list implementation. Then it will
always return the same list implementation (TnyList for example).

The developer might want to use a MySpecialListModel or like a
TnyFolderListModel or a TnyAccountStoreModel in libtinymailui-gtk.

The list is owned and created by the client that needs the folders. It's
not created by the framework that gets the items.

Look at the tny_folder_iface_get_headers API. It's exactly the same and
it's the reason why it's possible to use a GtkTreeModel as list type
without having to copy-over items to for example a GtkListModel type.

> Regarding the query functions and "Just an idea", it's quite hard to
> do  that correctly. For example, 'mutt' has nice patterns:
> http://mutt.org/doc/manual/manual-4.html#ss4.2

> But it's quite easy to over-engineer this. Or make it too inflexible.

I agree. I'm for now going to leave that out.

> The mutt-list mentions a great deal of things you'd want to search
> for, the most important one being body-text of course. Which does not
> really go very well with tinymail I guess. Also, for dates and other
> ordered sets you'd want to be able to specify > and < instead of just
> ==. Regexen are bad for numerical comparisons.

It's important (for speed) that you do te comparison only when it's
really needed. This means that you do it the ListModel versus View
implementation. Because those implementations know when an item will be
needed (to be viewed).

A GtkTreeModelFilter over an existing model would be suitable for this.

What you basically do is to hide the items that didn't match the query.

But only on-row-becomes-visible. Just like the messages that are flagged
as deleted.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be