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