Surphaze's Outline of Objects

Bag
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.

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 user asked.

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 it's task.

Signals

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.).