Surphaze's Outline of Objects
Bag is the central repository of the program state, this minimizes the
amount of data traffic we are forced to deal with.
Bottom up design: This is well suited for lymric and open source
in general because it minimizes bottlenecks for features. This is
because we know what things we need to do but, not so much what we may
run, and how they may work together, etc, because it is sort of
vague. The idea here is a class/library does one thing and pretty
much exactly what it is told to do, it can have any number of wrapper
functions or something to simplify statements for the bulk of the cases
but it should minimize assumptions on what the caller is going to
do. This sort of design is also going to be very useful for
threading. If the library/class is never doing something its not
told to do its very easy to understand when and what data it is
accessing and where.
What this means:
The reason we started doing this redisgn in the first place is we
wanted to minimize conflicts and difficulties with controlling
playlists. The simplest way to do this is prevent anyone else
from doing things when you don't tell them too. This means that
player should not know
anything more then it needs to do its job. All it needs is its
current song and its signals. It should not know about playlists
it should not know about global states it just does whats it told to
the best of its abilities. What this means is that the
specialized logic that makes things behave is put together with
everything letting you see the whole picture at once rather then
modifying several classes based on the same condition. This also
makes changing our plans easier and once again less hassle threading.
Stuff player needs that it doesn't have(as of the stuff in test). Signal handling for the following signals:
none of these signals actually change player they are information
layer, sort of the way gtk works or gstreamer works really. They
give you all the control through the callbacks.
- Song End Callback - call the function we tie to the signal, in this case it will
be in player callbacks and we can do whatever behaviour we wish at that
- Metadata Callback - used to grab information about the song
- Tick Callback - used to display location in the song for the ui
Basic control flow as I see it.
player_callbacks has all callback signals for the compact area so I see
it calling helper functions to handle looping, next song etc, we may
make a set of player helpers that bundle a set of common commands to
player. It makes whatever calls to player it needs to do what the
if you look at skin parsing stuff it operates on the same principle (
don't make assumptions on what you may be used for) I did this so that
maybe I could use this skin code outside of just the compact
area. ie skinned playlists
ct's Object Layout
I'm with surphaze all the way except the concept of player_callbacks
needs more love. Sure, LymricPlayer needs to do just what it's told. Meaning, play, pause, stop
operations work *only* on the player *and* a Songdata. That way we've minimized data exposure to
the `this` object that has work to do alongside `that` data the object instance needs inorder to fulfill
LymricPlayer should handle the cases Surphaze discussed above. The question that remains is *who handles
the signals*. So, we make a signal, LymricPlayer emits that signal but, which other data type instance is
listening for that activity? Do we need some kind of signal arbitor? Or does LymricPlayer just respond to
it's own calls? Or does the CompactArea handle that? Also should we just stop there with signal emittion and handling?
I'd say just leave that to K.I.S.S. design philosophy.
Before we start implementing signals we need to pick out the producer and consumer. Ok, we know who needs to
signal but, who is listening for it? B/c right now the tree falls in the woods but nothing ever hears it.
Personally, I think compact area should be handling it b/c compact area is the "issuer of commands". it's the
layer that tells the player what to do and what to work with (from a data sharing perspective). I also think the skin parser
should make use of a simple set of signals b/c we may want other portions of the application to worry about that kind of thing
(granted that's not K.I.S.S.).