Merging the UI branch

Gábor Lehel illissius at gmail.com
Mon Feb 26 20:09:19 CET 2007


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

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.

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.


More information about the Amarok-devel mailing list