Commit 8a7ecf2c authored by Scott Wheeler's avatar Scott Wheeler

Some design stuff that I'm kicking around.

svn path=/trunk/kdemultimedia/juk/; revision=286643
parent e60c466d
This is not being used for small-ish one-off type of things (at least for the
moment anyway) but rather as a place for me to note some of the design stuff
that I'm considering that may take some time and thought.
= Making PlaylistSplitter go away
Strip down PlaylistSplitter so that it's not such an abomination of a class
like it is now. Currently the structure is something like:
JuK -> PlaylistSplitter -< PlaylistBox
Playlist stack
With the PlaylistSplitter to mediate between them. This doesn't make sense to me
any more and I think a top-down structure is feasable. So:
JuK -> PlaylistBox -> Playlists
Here the PlaylistSplitter would be stripped down to a much more basic structure
that just handled basic layout -- as it should be.
More complex tasks like item or playlist creation may be split out into separate
files and factory-like classes.
The Playlist stack that's currently in the PlaylistSplitter will just become a
QWidget pointer that's passed to the Playlist factory to use as a parent.
= Adding a mechanism for caching something other than tags
Create an abstraction layer that exists between the Cache and Tag levels that
allows for caching of something other than the Tag structure. There's nothing
really preventing more stuff from just being in the Tag interface, but for
clarity of design it would be better two have two components that the sum JuK
associated meta-data is composed of -- file based and aquired.
= Move tag data based guessing into a unified and asyncronous API
I don't like #ifdefs mixed through JuK's code. I'd like to take do an
equivalent to the Player's abstraction to the track data guessing that is more
generic and simplifies the MusicBrainz related code.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment