Re: [Ayatana] (In)sensitive menu itens for displaying information

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

On Wed, Nov 3, 2010 at 16:59, Alex Launi <alex.launi@xxxxxxxxxxxxx> wrote:

On Wed, 2010-11-03 at 10:15 +0000, Matthew Paul Thomas wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cmaglothin wrote on 20/10/10 04:43:
>
> Why not try this:
> 
> 1. Instead of having the obscure "copy track data" feature, why not
> simplify the buttons in indicator-sound to something
> like http://imgur.com/ueC7X.jpg

Because that's a visual scope error: clicking a button would change
things both above it (track data) *and* to the left of it (album art).

I'm not sure I agree with this reasoning. The buttons there are clearly nestled into the warm embrace of the album art and the track metadata. If the controls were not clearly associated with both then this could be a reasonable argument, but the three are all very tightly coupled visually.

The Sound Menu as i understand it was made to enable also other music players to place themselves inside of it. Totem is the default player for single .mp3 files on every Ubuntu installation i have made so far, ironically it never appears in the Sound Menu. 

To experience the Sound Menu the way it was intended fully, i'm sure it is critical to have the possiblity to control the DE's default audio file player first. It doesn't make much sense to have all these pretty controls in the Sound Menu only if i'm prepared to take the payload of a heavy music database management application like Rhythmbox.

I think if we use a lean player to test the usability of playback controls in the Sound Menu, for example Totem, which is system default already, we run a good chance that we soon will notice how best to usefully display track metadata.

Just like in the talk about People Metadata, here we should not pull the metadata from the management application, but rather let the DE handle it. Rhythmbox may be a management interface to our music library, but it is not per se the library itself, that's all i'm trying to say. The metadata is Application independent and should be treated that way. It should also be represented that way imo.

Representing the metadata per track in a more generic way means to me that if there is no track data being represented, we should consider using that space for some other information, too. I suggest indicating playback position in that field, using saturation. The information (album art, title and artist) can be overlayed with a progress bar, that's how Epiphany-browser displays loading progress for example. Is there anything wrong with overlaying an object's thumb with a progress bar for playback position?