Merging the UI branch

Wed Feb 28 03:30:56 CET 2007

Though there are problems, I do like the proposal and I think it
should be merged. Right now it does't look very good, but with the
necessary changes in "context view" (?) and playlist, it could work
well IMO.

Right now the width is a problem, no doubt about it. But with a
smaller playlist (without collumns we can make it much smaller), and a
better designed context, it'll improve.
Maybe the browsers could expand as soon as the mouse move to the
sidebar, and retract as soon as the mouse isn't over the browsers. It
might  be very uncomfortable though, we'd need to test it.

Also, we shouldn't use context only for current song information IMO.
It could show information about the selected item(s) on playlist, and
maybe some other information depending on the browser currently open.

On 2/26/07, Dan Meltzer <parallelgrapefruit at gmail.com> wrote:
> On 2/26/07, Gábor Lehel <illissius at gmail.com> wrote:
> > The single 'unified' toolbar seems like an interesting idea, as does
> > having separate statusbars per component (playlist, browsers). Do you
> > intend on keeping the toolbar above the playlist, though? Because if
> > you move the searchbar to the main toolbar but keep that there, it
> > seems inconsistent. In general, do we want to have controls close to
> > the interface elements they logically belong to, or unified in single
> > long bars along the top/bottom? Your proposal seems to be going from a
> > unified statusbar and separate toolbars to separate statusbars and a
> > unified toolbar. I'm not saying this is necessarily wrong, just maybe
> > haphazard. Why did you choose this way rather than another?
> > (Admittedly, the player controls, volume, scope don't logically belong
> > to the playlist where they previously were -- rather to the entire
> > application -- so this part of it is well-justified. But I don't think
> > there's enough of these to devote an entire horizontal toolbar to
> > them, and pulling bits from other toolbars to fill it out doesn't seem
> > like a good solution either. Maybe we could find additional
> > player-wide functionality which wasn't previously present to include
> > there?).
>
> Firstly, this was basically just implementing the mockup done by mxcl
> seen here: http://www.methylblue.com/images/amarok_2_mockup.png
>
> This mockup seemed to be a good place to start--I agree there are some
> inconsistancies, but thats something that can be looked at closer (and
> probably should be).
> >
> > Lastly, I don't like the three-pane approach; nor the two-plus-one
> > pane approach from K3M, for that matter. Keeping the context always
> > visible is a noble intention, but I'm having doubts whether there's
> > enough space at all to be showing all three of them (browsers,
> > context, playlist) at once. My screen is 1024 pixels wide, which the
> > screenshot extends well past, and it still manages to look cluttered.
> > If the idea is that you will usually only have two of them visible, as
> > the browsers are only used on an as-needed basis, then the UI should
> > somehow reflect this (because otherwise people would leave them open,
> > if closing them requires effort) -- remove the browserbar at the side
> > and instead use toolbar buttons to temporarily open a side panel (this
> > incidentally solves the "what else to include in the main toolbar"
> > problem), and then close it automatically once the intended task is
> > completed. Or something of the sort. The difficulty, of course, lies
> > in determining when the task is completed -- which is why I favour the
> > current UI in the first place.
>
> Screen size was a problem I was wrestling with as well.  That
> screenshot was taken with amarok maximized on my 1400x900 laptop.
> It's still really crowded.
> The crowdedness would get a good bit better if we adapt the playlist
> to be like it was in the mockup.  Thats down the road though.
>
> The main thing I've been working with is keeping the context browser
> always visible.  The context browser is, in my opinion, what makes
> Amarok.  It should always be shown.  Having it always shown allows us
> to show context for items in the collection also, which is something
> that I think could be useful if implemented properly.  Furthermore,
> this central widget is an awesome place to show visualizations or
> videos if we decide to go that route (also been talked about).  I
> think that the layout could use a bit of cleanup still, suggestions
> (or just jumping in and making changes) are welcome!  I will be a bit
> less active this week, and have next week free for all sorts of
> changes.
>
> Dan,
>
> >
> > In the abstract, it seems to me that the two UIs (current and
> > proposed) are in their default state mostly identical (context and
> > playlist visible, rest of the browsers hidden), and the the difference
> > is only when you want to open a different browser. With the current
> > UI, the context temporarily disappears, while with the new, you
> > temporarily get an ugly three-pane configuration. I think I prefer the
> > former -- do you really want/need the context visible while you're
> > using a different browser?
> >
> >
> > On 2/26/07, Dan Meltzer <parallelgrapefruit at gmail.com> wrote:
> > > Resending without the gigantic attachment.
> > >
> > > ---------- Forwarded message ----------
> > > From: Dan Meltzer <parallelgrapefruit at gmail.com>
> > > Date: Feb 25, 2007 10:34 PM
> > > Subject: Merging the UI branch
> > > To: amarok-devel at kde.org
> > >
> > >
> > > Hello,
> > >
> > > After a weekend of work between shash and I, we have achieved a new
> > > proposal for the UI.  I think that it is now in a position where it
> > > would be beneficial to get it back into trunk, isntead of maintaining
> > > two separate branches.
> > >
> > > There are still little things that need to be fixed in it, but I feel
> > > they would be more likely to be found/fixed in trunk then in a branch.
> > >
> > > The one thing that I see for certain as a downside right now is that
> > > the playlist looks really bad until it gets refactored.  Other than
> > > that I personally like this view more.
> > >
> > > Things that this branch does:
> > >
> > > Implements a threepane view, Browsers| context| playlist.
> > > Moves the menu creation and action creation code out of the
> > > constructor//init and into their own functions.
> > > Experimental video support (which has been commented out until we get
> > > a bit further along).
> > > Stops using amarok_ui.rc for the toolbar.  This was to get the search
> > > bar into the toolbar.
> > > Deletes amarokui_xmms.rc (which is really old I believe.)
> > >
> > > Things I would still like to achieve;
> > > Play with the default colorscheme
> > > Move the song progressbar to the main toolbar from the statusbar.
> > > Remove the real progressbar (the one used for collectionscans and
> > > stuff) from the statusbar belonging to the playlist to a statusbar in
> > > the collection panel.
> > > Probably a bunch of other stuff.
> > >
> > > The ui can seen here:
> > > http://perdition.campus.alfred.edu/~hydrogen/amarok-uirefactor.png
> > >
> > >
> > > The diff of changes can be seen in two ways.  It is on my webspace here:
> > > http://perdition.campus.alfred.edu/~hydrogen/branch_changes.diff
> > > or simply run a command like svn diff
> > > $SVNROOT/trunk/extragear/multimedia/amarok
> > > $SVNROOT/branches/work/amarok_uirefactor
> > > The majority of changes occur in playlistwindow.cpp.
> > >
> > > Feedback?
> > > Dan
> > > _______________________________________________
> > > Amarok-devel mailing list
> > > Amarok-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/amarok-devel
> > >
> >
> >
> > --
> > Work is punishment for failing to procrastinate effectively.
> > _______________________________________________
> > Amarok-devel mailing list
> > Amarok-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/amarok-devel
> >
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>