Re: [Rhythmbox-devel] Rhythmbox roadmap

[Douglas McMorris <virage83 mail utexas edu>]

On Mon, 2003-10-13 at 17:17, Colin Walters wrote:
> On Mon, 2003-10-13 at 17:10, Douglas McMorris wrote:
> 
> > i had arch setup for the old branch, but am having problems setting it up
> > with the new... probably my ignorence... heres my problem:
> > 
> > [douglas@neo Code]$ tla archive-setup
> > douglas@d-mak.homelinux.org--2003/rhythmbox--mainline--0.6
> > archive not registered: douglas@d-mak.homelinux.org--2003
> >   (see register-archive)
> 
> Well, did you make that archive (with tla make-archive)?  Maybe you
> typoed the name when you originally created it?  What does 'tla
> archives' say?

well... it seems stuff from when i played with arch and rb before was
still around and caused problems.  after i deleted all that, it worked
fine.

> > Or additions... that i've noticed at least... haven't checked in the last
> > two days though.
> 
> That's fixed now.
> 
> > definately.... is there anything we can do to make the UI not lock, but
> > still have he old content show until the new is compiled??  in other
> > works, get rid of the times when the filtered list temporarily goes blank.
> 
> Yeah, I have a plan for it, I mentioned it in my response to Sriram.

Sounds good, this was my only "big" problem with the new db stuff, but
since its readily fixable, all is well.

> > I'm looking forward to this... this should be pretty simple if we simply
> > use the nautilus-cd-burner code in conjunction with proper gstreamer
> > pipelines... right?
> 
> I assume, yeah.
> 
> > i've been playing with itunes and its UI for this is evolutionesk...
> > somewhat bad IMO...
> 
> It seems a little complicated to me.  Implementing the full semantics
> wouldn't be trivial.
> 
> > how difficult with all this be with in the db code?? is it simple run this
> > function and get a list, or is there more we need to do?
> 
> Designing the widget that creates a query structure is probably the
> hardest.
> 
> > I think shuffle MUST be fix... its a trivial thing... 
> 
> Well, not exactly.  If you limit it to a max of say 50 or something it's
> probably doable though.

well... all you have to do is keep an inorder list of all thats been
played since the last time filtering changed.  this could get pretty
complex though i guess since, like anything else in rb, you have to deal
with deletions and updates to the data and such.  I don't see the need
to place a limit on it if you are carrying around references to
objects.  It should be that expensive to keep an entire list if your
only keep track of whats played in order and don't reorder everything
and keep it in memory.  Most people don't leave rb playing for days and
days without changing the filter.

the reason i'm saying get rid of the list when the filter changes is
because if i am listening to a genre randomly for hours and then decide
to listen to an artist in that genre, i wouldn't expect that artist
songs to be excluded.

i could of course be on crack here since i haven't looked at the new db
code.

> > I think we should ellispize(wrong word, mean make shorter) album, artist,
> > and genre names in the browser.  horizontal scrollbars in those are pretty
> > nasty looking.  Another thing is that the headers for the browser should
> > be brought back.
> 
> Both are done now in the latest arch.

Awesome, thanks.

> > If we can do something about the Iradio browser by 0.6.0 we should... 
> > having it pull Iradio stations from shoutcast and live365 would definately
> > be nice.  
> 
> Yeah.

If I get some spare time this week I may take a look at stream tuner
code and see if we can use any of it.

> > Would make a browser and searching make more since for Iradio
> > then.  Speaking of the browser, is there anything else we could do... just
> > looking at it makes me nausious. 
> 
> Like do a treeview like itunes?  Maybe.

yeah, thats what i was thinking, but both options are somewhat bad.  the
treeview has some usability problems... the more you browse, the harder
it is to browse (if you don't close genres).  Our current setup
eleminates that, but is visually disturbing.  Maybe we can come up with
some other way.  I've thought about maybe a tree view that contained
genres in the source list, but that would be bad too.

> 
> > Another thing we should shoot for is better integration with
> > sound-juicer... is it supposed to be importing to the rb library?? b/c it
> > never has for me.
> 
> It's supposed to work, I haven't tried it yet myself...

I'll do some bug testing.

> > If would going to have cd importing and burning, is it not logical that we
> > should also handle cd playing?  This would be later in 0.6.x i think
> > though
> 
> Yeah.  CD is kind of blocked on better MusicBrainz integration.

I know MusicBrainz support would be really nice for library retagging
and such, but most of its cool functionality is currently blocked b/c of
not being able to tag files(waiting on gstreamer...).  How is this
blocking a CD source?  Sound Juicer does it fine.  I guess if we are
wanting a generic interface(coding wise) to its functionality there is a
problem since we can't use it with the library yet.  Perhaps we can
start on such a frame work and use a CD view as a guinea pig.

> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel@gnome.org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
-- 
<><  ---------------------------------------
Douglas McMorris <virage83@mail.utexas.edu>