Re: Volume [WAS: Re: [Rhythmbox-devel] yet another new mockup(meta)]

[Jorn Baayen <jorn nl linux org>]

tor 2003-05-15 klockan 09.21 skrev Luca Ferretti:
> Il mer, 2003-05-14 alle 17:36, Jorn Baayen ha scritto:
> 
> > > I don't this so. IMHO there is another reason: rb's volume is a relative
> > > volume, so a different (visual) approach can help to understand that
> > > it's a different volume. Besides (but it's a very personal taste) slider
> > > can show quickly the status so you can better choose between to change
> > > global volume, or change only rb volume.
> > 
> > change global volume in rb? or what are you saying?
> > 
> 
> NO. Just: I see a different icon/control in rb so I can _expect_ it
> isn't a way to change global volume. But it's a personal taste.
> 
> And, obviously we need to write it somewhere in user docs...
> unfortunately people never read manuals :-((

People shouldnt need to read manuals to grok how stuff works.. IMHO we
can just do this (the system volume in the panel is a Bad Thing[tm]
anyway, and if we don't just go forward we'll never get it right)

> 
> > > 
> > > So, placing the slider in the right place (see iTunes), you can align
> > > it's cursor to another widget and you can quickly understand current
> > > status (yeah, we need a little volume icon near slider)
> > 
> > Align its cursor to another widget? I'm not sure I get what you mean
> > here.. 
> > 
> 
> Only visually, don't in GTK+ way. See glade attach or iTunes: when
> slider's cursor is in the middle, it's 'aligned' (vertically and only
> visually) with play button. Yes, you need to place slider under buttons,
> use zero-v and max-v icons, and no way to 'click and mute'

I see. (We don't need mute on this volume imho, I mean, we have pause..)

> 
> > But.. I think it looks pretty ugly under the buttons myself.. of course
> > prettiness is not the most important aspect, but, blah.. :) Also..
> > having two sliders in that top area may be confusing imho..
> > 
> 
> boh... No idea, not so bad IMHO... OK, I like it and I use this approach
> in mochups of mine...

Which is one of the reasons I don't like them so much... :)

> 
> Yes, have 2 kind of slider can help, but it's break the use only GTK+
> default quest [1] :-)

If we use a slider we should use the stock widge tdefinetely..

> 
> BTW time slider appear only when you are listening something (OK,
> always, but don't when you start rb  the first time or while you are
> choosing music :-P), and I suppose it's placed near song info (this is
> because I like the beveled info area: bevel help to distinguish stuff
> and you can use this area as all current action info container[2])

The slider should stay there also if nt playing, just grayed out.. so
that doesnt change things ..

> 
> > I agree thuogh.. the button is far from optimal.. 
> > 
> > Hm..
> > 
> > Just a random idea: having two small up/down buttons next to the volume
> > button, so that you dont have to click the volume button (but still can)
> > to change the volume. (the icon would show more 'audio stripes'
> > according to the volume to show feedback)
> > This way it's not a slider, doesnt take much space, should stil be clear
> > be hopefully.
> > 
> 
> Good, so you can perform 4 action with a single widget: pump up volume
> clicking up arrow, pump down clicking down arrow and normalize it (rb
> volume = system volume) clicking icon, while icon show current status...

Normalize? (rb volume != system volume). The up and down arrows are just
provided as a short cut for not having to open the slider first.. (which
would be rather useful imho..)

I think it's quite simple really..

> 
> > It also has the advantage of fitting the western model of volume better,
> > you turn a volume 'up' or 'down' in English (wheras you seek a song
> > forward or backward). Not sure about non-European langauges though..
> > 
> 
> True.... 
> 
> > About distinguishing from the system volume.. hmm.. actually I think the
> > volume applet in the panel is Wrong, because it makes it easy to change
> > the system volume (where this one actually should be carefully tweaked
> > and the apps should handle their own volume).
> > 
> 
> Yeah, man!
> 
> > > BTW take a look to iTunes and/or Aqua stuff: vertical slider/scrollbars
> > > is _under_ header, don't near as in GTK+, QT, Win32 widgets. 
> > > It's really cool in library browser: can we reimplement it? Pleeeese...
> > 
> > Hm, I think we should use standard widgetes really.. :)
> > 
> 
> Or we can ask to change lists in GTK+2.4. 
> 
> Really: IMHO Apple's one is more logic (and right) then others. When you
> scroll a list, you scroll its contents, don't the header too.

True..

> 
> Can someone open a bug?

Go ahead ;)

> 
> 
> -----------------------------------------------------------------------------
> 
> [1] About time slider: probably GNOME/GTK+ needs a
> multimedia-slider-widget like in old lovely BeOS. 
> Let me explain: current gtk+ slider is something like
> 
> --------[]-----------
> 
> you can control it only moving cursor. So if you have a 03:45 minutes
> long song/video/audiofile and you want to listen only from 01:56 to
> 02:32 you can't, or it's really difficult to find the exact start point
> and you have to stop playing, then if you want to listening only this
> piece again you have to reseek.... boring stuff...
> 
> BeOS multimedia slider is something like
> 
> --->---[]-------<----
> 
> You can move < and > and while moving a tooltip show time.
> 
> 
> [2] BTW do we want a multi dialog app (i.e. show ripping/burning current
> status/progress is showed in a separate window dialog [just like
> nautilus-cd-burner] so you can use main window to play music) or a
> single-window-as-you-can (use the info area in main window to put info
> about progress: you can play music, but you use less CPU)?
> 
> The second one is more like a real device, and help user to perform a
> single task per time (somewhere I read it's better for human). First one
> is more cool for a geek... but... slow down?

I think the status area would be good enough, progress windows are
usually and probably should be modal (you cant use the app while its
working like that) and thats not quite what we want in rb, so..

>