Re: [Rhythmbox-devel] Magnatune catalog/purchasing plugin



On Thu, 2006-06-15 at 09:14 -0700, Adam Zimmerman wrote:
> I've made all the changes you suggested, and my source now shows up in
> the list. But when I click on it, I just see a blank grey box. Do I need
> to create my own EntryView? I can't see where the ipod source does it,
> but that could just be my weak (i.e., nonexistent) C skillz :P

Does your source class derive directly from rb.Source? If you do that
you will need to manually create the entry view, set it up and pack it
into the source (which is a gtk.Box).

The iPod source doesn't directly derive from that, instead it derives
from rb.BrowserSource (well actually it's rb.RemovableMediaSource, but
it makes no difference). That takes care of a lot of the standard entry
view stuff, and gives you working browsers and search box for free.


Basically what you need to do is derive from rb.BrowserSource instead of
rb.Source. You don't need to worry about query models (it's handled
automatically), just "entry_type=self.entry_type" to gobject.new
instead.


> Also, duplicate URIs cause rhythmdb to give a warning. This happens a
> few times in song_info.xml, but it also happens for every track after
> the plugin is unloaded and then loaded again.

This is because the entries are still in the database, you need to get
rid of them when you plugin is unloaded. The easiest way is to add the
following to the plugin's "deactivate" function:

db.entry_delete_by_type (self.entry_type)
db.commit ()


Really there should be a function to delete the entry type which does
this and cleans up the entry type properly (which currently gets
leaked), but that's a post 0.9.5 change.


> Finally, loading the plugin blocks the UI for about 2 minutes while the
> tracks are being parsed. I tried (as you can see from the code) putting
> the call to xml.sax.parse into a Thread object, but when I tried that
> the method didn't run at all (the source showed up, but the "Adding
> artist - title" string never got printed). Is there something else I can
> do so my code doesn't block the UI?

Currently we don't activate threading for the embedded python
interpreter, which is why it doesn't work.

This isn't a solid reason for not activating it, except it's non-trivial
to ensure that we correctly take the global python lock when calling
things and fixing any re-entrancy issues. If you (or anyone else)
actually needs it, we can activate it.



By doing a bit of thinking it's usually possible to find a good method
that doesn't require threading. In this case it is asynchronous SAX
parsing.

I'm not sure exactly how to do it in python, but basically you create a
parser, load the data in chunks with asynchronous gnome-vfs or urllib,
and pass the data to the parser as you get it. So you never do anything
that will block for a long time.


Cheers,

James "Doc" Livingston
-- 
On two occasions I have been asked [by members of Parliament!], `Pray,
Mr. Babbage, if you put into the machine wrong figures, will the right
answers come out?' I am not able rightly to apprehend the kind of
confusion of ideas that could provoke such a question. --Charles Babbage




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]