Alan's Lymric Page

or Lymric Development From The Eyes of Alan

I've decided to write up this little page so that I can have some decent place to post information about what I'm doing with lymric and what hairbrained schemes I've come up with for my part of the project. I am mainly responsible for the UI, and am pretty stubborn, so I'll probably have to argue a lot with what I'm working on before I give up and let CT have his way on things.

April 28, 2003
Just a quick update, because I got the normal and reduced mode switching to work. Here's what two ui modes will be available initially in Lymric.

Lymric's Two Modes

April 26, 2003
I've worked quite a bit more on lymric, and have gotten quite a bit of the shell for it finished. One thing, though, that we have decided is to remove Gnome integration from lymric. We've looked, and the cost of trying to be a Gnome application (cutting off other unix users to some extent, or at least making them angry, forcing users to have tons of libraries on their computer, dealing with the politics and corporate control that is so thick in Gnome circles these days, and probably most importantly the fact that Gnome wants to destroy any chance for popularity of alternative applications by choosing 'defaults') far outweight the benefits of integration (vfs support, a few small libraries). So, I took out all Gnome integration from Lymric, and that is where things will stand. We're just not willing to deal with trying that hard to please just a single niche.

April 20, 2003
It's been a while, but I finally did some more work on the lymric ui. If it goes well with all, I think I'm going to go for a more tabbed style interface, with fewer bells and whistles and more plain old ease of use.
I'm writing real code now, not just doing glade tests, so what you see is the real deal.

Real Design

March 28, 2003

Most Recent Design

March 27, 2003
Shortly after putting up the last screeny, Dobey gave me his impressions on the design, and I tried to take a lot of it to heart. I'm not too happy with the search box, just because it makes things look kind of off-balance on that side of the screen, but I'll see what I can do later. You can see the new layout below:

New Lymric Layout

(Earlier March 27)
Finally, I've done some work on the UI. I've been slack lately, what with work and schoolwork going on, but I think my new UI design is infinitely better than what I've done before, and it's going to be what the UI is like, barring any stiff opposition from others on the project.

Lymric UI Rough Design

As you can see above, we've done pretty much the same thing as Rhythmbox and iTunes have done on UI, but I think we're going to have a much richer user experience than the two... just because we're shooting for the easiest ui possible via minimizing clicks and navigation. It should make for a really kick butt interface.

With the UI in mind, I've come up with the following design. I'm jotting this down so that CT and everyone can nit pick it and we can come up with the best architecture possible for our program:

Lymric UI Architecture:
i) Player -- the thin bar across the top of the screen, minus the meta-button.
ii) Views Selector -- the white area on the middle-right of the screen. You select what view you want from here.
iii) View -- the white area on the middle-left of the screen. You actually handle media files or whatever else would go on with the application from here.
Note to CT: This is what we were calling a source... I think the term view describes it much more clearly.

As you can see, lymric has a very component based ui. The only really complex portion of the ui is the view, so I'll talk about that now. The view is simply a programmer defined interface for a specific use-case that the application has. Possibilities in the immediate future are a view for managing a media library, a view for creating an independent playlist, a view for handling cds, a view for putting music onto your mp3 player, etc. The view is basically an easy way for us to abstract these tasks in the eyes of the UI. The view will, in essence, be a struct that contains, but is not limited to, the following:

· Widget for the actual view area.
· Boolean indicating if the view is playable or not.
· Function pointer indicating a function to be called when the view has something dragged onto it.
· Function pointer indicating a function to be called when the view is loaded.
· Function pointer indicating a function to be called when the view is activated (viewed).
· Function pointer indicating a function to be called when the view is closed.
· Function pointer indicating a function to be called when the view is initially added to the user's list of views. (Called when the user adds a new view.)
· Widget for the configuration area of the view. (Called from our options window.)

Views may have more than that functionality, but I know that most probably at least all of those items will be needed.

If I can get around to it, I'll post more about this architecture later on... but for now, I'm tired of typing this stuff out.