Re: [Rhythmbox-devel] State Of The Rhythmbox (3)

[Colin Walters <walters verbum org>]

On Sun, 2003-09-07 at 13:35, Colin Walters wrote:

> However, I can't think of a sane way to implement this without modifying
> GtkTreeView.  The part of the main thread we care about for this
> discussion is the GtkTreeView, which is using a GtkTreeModel returned by
> RhythmDB as a model.

Ok, thanks to kris on IRC, there is a fairly sane way to do this.  
First, I should mention that I realized that one nice thing about
returning a new GtkTreeModel for a query is that we can actually do
queries completely asynchronously, in another thread.  So here's what
I'm thinking will happen.

The user types something in the search box.  This causes rb to call:

GtkTreeModel *main_model;
rhythmdb_do_full_query (&main_model, RHYTHMDB_QUERY_PROP_LIKE, RHYTHMDB_PROP_TITLE, "foo", RHYTHMDB_QUERY_END);

This call returns immediately, and sets main_model.  The main thread then does
gtk_tree_view_set_model (main_model) as normal.

Now, main_model is actually a RhythmDBQueryModel.  The do_full_query
call has spawned a new thread which is actually traversing the database,
and pushing results into the RhythmDBQueryModel.  However, the model
doesn't emit row_inserted or whatever signals immediately.  Instead, we
will have an idle handler which periodically polls the active query
model, and emits any changed signals.

While the query thread is active, we'll display a message like
"Working..." in the status area.  It is possible that the user will
change the query while one is still running - so we need a way to cancel
a query.  Probably this will involve passing down a boolean value which
the main thread can set (we shouldn't have to worry about atomicity
issues since this value is only true/false).

Now, the query result also becomes the synchronization point for things
like database additions.  It will attach to the entry_added signal in
the database, and evaluate the query on that entry to see whether or not
it should be added to the query model.  Note that we don't have problems
with a node being added twice (once from the signal, and once from the
query searching), since the query searching holds a read lock on the
database.  Likewise, it will attach to the entry_deleted signal, and
update itself accordingly.

We have to be careful to handle the fact that the UI can be out-of-date
WRT the database.  For example, suppose that a user tries to change the
properties of a song while its deletion has already happened in the
database, but the update to the UI is still queued?  One solution is to,
whenever we enter the database from the main thread for read/property
write/delete, look through the pending deletions that haven't been
processed by the main UI, and if the entry is in that set, just ignore
the request.

I am feeling fairly confident now that the above will work, so I've
started to implement it in the --rhythmdb branch.

Any thoughts?