Discussion:
Time Remaining
dean blackketter
2002-02-23 14:43:35 UTC
Permalink
For this particular feature, though, the PIP button might be
appropriate.
...
Now Playing (n of m) + Remaining time
Now Playing (n of m) + Progress bar + Remaining Time
I've added these.
Great.
1. It might be hard to distinguish remaining time from elapsed time
quickly, but if you wait a second, it becomes obvious. It might be
hard to flip through the choices and pick the right one.
To distinguish between elapsed and remaining, I've added a - before
the remaining time, in imitation of my Sony CD player.
Good solution.
2. This is probably the limit of the number of views we can have for
this button. Otherwise it becomes tedious to find the one you want.
Yeah. My original motivation for not wanting to put these on the PIP
button was that I wanted four time modes (Track Elapsed, Track
Remaining, Playlist Elapsed, Playlist Remaining), and that seemed too
many combinations to page through.
I think we're ok now, but we'll have to find a different solution if
we need more combinations.
If you want to take a crack at adding this to the PIP button (check
out lib/SliMP3/Buttons/Playlist.pm) and submit another patch, that
would be great. It would be particularly great if the settings page
for the client had a pop-up menu that allowed the user to select
between all six combinations.
Done. Attached is a new patch is against the CVS sources, not against
the CVS sources + my previous patch.
Thanks, I'll apply the patch.
The second problem is more systemic then anything specific to your diff. I
haven't brought this up before, but I think that we need to establish some
kind of naming convention for the strings in strings.txt. Not because I
disagree with what you put in there, though.
Whenever a client or server setting is changed we display some kind of
message as a confirmation. We also display a message if the value was
1) if we have a naming convention like SETUP_parametername and/or
SETUP_REJECT_parametername, we can put the display in setup_evaluation and
do it automatically (provided the string gets added to strings.txt)
2) we can add to the setup hash the string names to use and do it
automatically in setup_evaluation
3) for each parameter in the setup we can add a if exists $changed and an
if exists $rejected block and do the string display there
My preference would be naming convention.
I'll defer on this to people with more experience with this way of
handling web input.
I nominate Robert! :-)

-dean

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Secure all your Web servers now - with a proven 5-part
strategy. The FREE Server Security Guide shows you how.
http://us.click.yahoo.com/iWSNbC/VdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2002-02-23 14:41:52 UTC
Permalink
Robert,

I filed a couple of bugs against the ugliness in the web pages during
setup when we display a confirmation or rejection of a change in
settings. Can you attack this problem?

-dean
Excellent job in adding a new client parameter BTW. It looks like you got
everything covered as far as that goes. Two small problems, though. The
clientSet in the setup_player is unnecessary, that is taken care of in the
call to setup_evaluation.
The second problem is more systemic then anything specific to your diff. I
haven't brought this up before, but I think that we need to establish some
kind of naming convention for the strings in strings.txt. Not because I
disagree with what you put in there, though.
Whenever a client or server setting is changed we display some kind of
message as a confirmation. We also display a message if the value was
1) if we have a naming convention like SETUP_parametername and/or
SETUP_REJECT_parametername, we can put the display in setup_evaluation and
do it automatically (provided the string gets added to strings.txt)
2) we can add to the setup hash the string names to use and do it
automatically in setup_evaluation
3) for each parameter in the setup we can add a if exists $changed and an
if exists $rejected block and do the string display there
My preference would be naming convention.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Secure all your Web servers now - with a proven 5-part
strategy. The FREE Server Security Guide shows you how.
http://us.click.yahoo.com/iWSNbC/VdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2003-02-22 12:55:11 UTC
Permalink
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] Time
Remaining</title></head><body>
<blockquote type="cite" cite>dean blackketter said:<br>
&gt;For this particular feature, though, the PIP button might be<br>
&gt;appropriate.<br>
&gt;...</blockquote> <blockquote type="cite" cite>&gt;To use your change we could add two
more displays:<br>
&gt;<br>
&gt;Now Playing (n of m) + Remaining time<br>
&gt;Now Playing (n of m) + Progress bar + Remaining Time<br>
<br>
I've added these.</blockquote>
<div><br>
Great.<br>
</div>
<blockquote type="cite" cite><br>
<br>
&gt;1. It might be hard to distinguish remaining time from elapsed
time<br>
&gt;quickly, but if you wait a second, it becomes obvious.&nbsp; It
might be<br>
&gt;hard to flip through the choices and pick the right one.<br>
<br>
To distinguish between elapsed and remaining, I've added a - before
<br>
the remaining time, in imitation of my Sony CD player.</blockquote>
<div><br></div>
<div>Good solution.</div>
<div><br></div>
<blockquote type="cite" cite><br>
<br>
&gt;2. This is probably the limit of the number of views we can have
for<br>
&gt;this button.&nbsp; Otherwise it becomes tedious to find the one
you want.<br>
<br>
Yeah. My original motivation for not wanting to put these on the PIP
<br>
button was that I wanted four time modes (Track Elapsed, Track <br>
Remaining, Playlist Elapsed, Playlist Remaining), and that seemed too
<br>
many combinations to page through.</blockquote>
<div><br></div>
<div>I think we're ok now, but we'll have to find a different solution
if we need more combinations.</div>
<div><br></div>
<blockquote type="cite" cite><br>
<br>
&gt;If you want to take a crack at adding this to the PIP button
(check<br>
&gt;out lib/SliMP3/Buttons/Playlist.pm) and submit another patch,
that<br>
&gt;would be great.&nbsp; It would be particularly great if the
settings page<br>
&gt;for the client had a pop-up menu that allowed the user to
select<br>
&gt;between all six combinations.<br>
<br>
Done. Attached is a new patch is against the CVS sources, not against
<br>
the CVS sources + my previous patch.</blockquote> <div><br></div> <div>Thanks, I'll apply the patch.</div> <div><br></div> <blockquote type="cite" cite>&gt;The second problem is more systemic
then anything specific to your diff.&nbsp; I<br>
&gt;haven't brought this up before, but I think that we need to
establish some<br>
&gt;kind of naming convention for the strings in strings.txt.&nbsp;
Not because I<br>
&gt;disagree with what you put in there, though.<br>
&gt;<br>
&gt;Whenever a client or server setting is changed we display some
kind of<br>
&gt;message as a confirmation.&nbsp; We also display a message if the
value was<br>
&gt;rejected.&nbsp; So, there are three options for displaying this
message:<br>
&gt;<br>
&gt;1) if we have a naming convention like SETUP_parametername
and/or<br>
&gt;SETUP_REJECT_parametername, we can put the display in
setup_evaluation and<br>
&gt;do it automatically (provided the string gets added to
strings.txt)</blockquote> <blockquote type="cite" cite>&gt;</blockquote> <blockquote type="cite" cite>&gt;2) we can add to the setup hash the
string names to use and do it</blockquote> <blockquote type="cite" cite>&gt;automatically in
setup_evaluation</blockquote> <blockquote type="cite" cite>&gt;</blockquote> <blockquote type="cite" cite>&gt;3) for each parameter in the setup we
can add a if exists $changed and an<br>
&gt;if exists $rejected block and do the string display there<br>
&gt;<br>
&gt;My preference would be naming convention.<br>
<br>
I'll defer on this to people with more experience with this way of
</blockquote>
<blockquote type="cite" cite>handling web input.</blockquote>
<div><br></div>
<div>I nominate Robert!&nbsp; :-)</div>
<div><br></div>
<div>-dean</div>
</body>
</html>
dean blackketter
2003-02-22 12:55:12 UTC
Permalink
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] Time
Remaining</title></head><body>
<div>Robert,</div>
<div><br></div>
<div>I filed a couple of bugs against the ugliness in the web pages
during setup when we display a confirmation or rejection of a change
in settings.&nbsp; Can you attack this problem?</div>
<div><br></div>
<div>-dean</div>
<div><br></div>
<blockquote type="cite" cite>Excellent job in adding a new client
parameter BTW.&nbsp; It looks like you got <br>
everything covered as far as that goes.&nbsp; Two small problems,
though.&nbsp; The <br>
clientSet in the setup_player is unnecessary, that is taken care of in
the <br>
call to setup_evaluation.<br>
<br>
The second problem is more systemic then anything specific to your
diff.&nbsp; I <br>
haven't brought this up before, but I think that we need to establish
some <br>
kind of naming convention for the strings in strings.txt.&nbsp; Not
because I <br>
disagree with what you put in there, though.<br>
<br>
Whenever a client or server setting is changed we display some kind of
<br>
message as a confirmation.&nbsp; We also display a message if the
value was <br>
rejected.&nbsp; So, there are three options for displaying this
message:<br>
<br>
1) if we have a naming convention like SETUP_parametername and/or <br>
SETUP_REJECT_parametername, we can put the display in setup_evaluation
and <br>
do it automatically (provided the string gets added to
strings.txt)<br>
<br>
2) we can add to the setup hash the string names to use and do it <br>
automatically in setup_evaluation<br>
<br>
3) for each parameter in the setup we can add a if exists $changed and
an <br>
if exists $rejected block and do the string display there<br>
<br>
My preference would be naming convention.<br>
<br>
<br>
------------------------ Yahoo! Groups Sponsor
---------------------~--&gt;<br>
Sponsored by VeriSign - The Value of Trust<br>
When building an e-commerce site, you want to start with a<br>
secure foundation. Learn how with VeriSign's FREE Guide.<br>
http://us.click.yahoo.com/kWSNbC/XdiDAA/yigFAA/rIp0lB/TM<br>
---------------------------------------------------------------------<span </span>~-&gt;<br>
<br>
To unsubscribe from this group, send an email to:<br>
slimp3-dev-unsubscribe-***@public.gmane.org<br>
<br>
&nbsp;<br>
<br>
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ </blockquote>
<div><br></div>
</body>
</html>
All The Concrete Dreams In My Mind's Eye
2002-02-23 10:23:59 UTC
Permalink
For this particular feature, though, the PIP button might be
appropriate.
...
Now Playing (n of m) + Remaining time
Now Playing (n of m) + Progress bar + Remaining Time
I've added these.
1. It might be hard to distinguish remaining time from elapsed time
quickly, but if you wait a second, it becomes obvious. It might be
hard to flip through the choices and pick the right one.
To distinguish between elapsed and remaining, I've added a - before
the remaining time, in imitation of my Sony CD player.
2. This is probably the limit of the number of views we can have for
this button. Otherwise it becomes tedious to find the one you want.
Yeah. My original motivation for not wanting to put these on the PIP
button was that I wanted four time modes (Track Elapsed, Track
Remaining, Playlist Elapsed, Playlist Remaining), and that seemed too
many combinations to page through.
If you want to take a crack at adding this to the PIP button (check
out lib/SliMP3/Buttons/Playlist.pm) and submit another patch, that
would be great. It would be particularly great if the settings page
for the client had a pop-up menu that allowed the user to select
between all six combinations.
Done. Attached is a new patch is against the CVS sources, not against
the CVS sources + my previous patch.
The clientSet in the setup_player is unnecessary, that is taken care
of in the call to setup_evaluation.
Thanks. I've removed the extraneous call in the new patch.
The second problem is more systemic then anything specific to your diff. I
haven't brought this up before, but I think that we need to establish some
kind of naming convention for the strings in strings.txt. Not because I
disagree with what you put in there, though.
Whenever a client or server setting is changed we display some kind of
message as a confirmation. We also display a message if the value was
1) if we have a naming convention like SETUP_parametername and/or
SETUP_REJECT_parametername, we can put the display in setup_evaluation and
do it automatically (provided the string gets added to strings.txt)
2) we can add to the setup hash the string names to use and do it
automatically in setup_evaluation
3) for each parameter in the setup we can add a if exists $changed and an
if exists $rejected block and do the string display there
My preference would be naming convention.
I'll defer on this to people with more experience with this way of
handling web input.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Pinpoint the right security solution for your company - FREE
Guide from industry leader VeriSign gives you all the facts.
http://us.click.yahoo.com/lWSNbC/WdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Robert Moser II
2002-02-23 09:20:05 UTC
Permalink
Excellent job in adding a new client parameter BTW. It looks like you got
everything covered as far as that goes. Two small problems, though. The
clientSet in the setup_player is unnecessary, that is taken care of in the
call to setup_evaluation.

The second problem is more systemic then anything specific to your diff. I
haven't brought this up before, but I think that we need to establish some
kind of naming convention for the strings in strings.txt. Not because I
disagree with what you put in there, though.

Whenever a client or server setting is changed we display some kind of
message as a confirmation. We also display a message if the value was
rejected. So, there are three options for displaying this message:

1) if we have a naming convention like SETUP_parametername and/or
SETUP_REJECT_parametername, we can put the display in setup_evaluation and
do it automatically (provided the string gets added to strings.txt)

2) we can add to the setup hash the string names to use and do it
automatically in setup_evaluation

3) for each parameter in the setup we can add a if exists $changed and an
if exists $rejected block and do the string display there

My preference would be naming convention.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
When building an e-commerce site, you want to start with a
secure foundation. Learn how with VeriSign's FREE Guide.
http://us.click.yahoo.com/kWSNbC/XdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2002-02-23 08:05:29 UTC
Permalink
Hi Aneel,
While a song is playing, I prefer to see the time remaining rather
than the elapsed time. I've attached a patch against the current CVS
sources that adds this functionality. I added a client preference to
allow the user to choose which format to show.
Great I'll take a look.
I thought about binding this to a button, but that seems like a
finite resource. How are buttons allocated? Are there any plans for
an interface that would allow users to configure which buttons do
what?
Buttons are indeed scarce, in fact, we're almost out. I'm the
self-appointed "keeper of the buttons" and have been trying to
maintain the consistency of the user interface. We haven't worked on
any button customization interface yet. I've been spending my time
trying to come up with one really good interface. (Perl-saavy users
certainly have everything they need to customize their buttons. :-)

For this particular feature, though, the PIP button might be
appropriate. When you press PIP you get jumped to the current
playlist. Pressing it again rotates through four different "Now
Playing" versions on the top line:

Now Playing (n of m) + Elapsed time
Now Playing (n of m) + Progress bar
Now Playing (n of m) + Progress bar + Elapsed Time
Now Playing (n of m)

To use your change we could add two more displays:

Now Playing (n of m) + Remaining time
Now Playing (n of m) + Progress bar + Remaining Time

Two issues:

1. It might be hard to distinguish remaining time from elapsed time
quickly, but if you wait a second, it becomes obvious. It might be
hard to flip through the choices and pick the right one.

2. This is probably the limit of the number of views we can have for
this button. Otherwise it becomes tedious to find the one you want.

If you want to take a crack at adding this to the PIP button (check
out lib/SliMP3/Buttons/Playlist.pm) and submit another patch, that
would be great. It would be particularly great if the settings page
for the client had a pop-up menu that allowed the user to select
between all six combinations.
(PS. Hi. I'm new here. Just got a Slim Player last week, and I'm
still familiarizing myself with the server.)
Welcome!

-dean

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
All The Concrete Dreams In My Mind's Eye
2002-02-23 07:44:15 UTC
Permalink
While a song is playing, I prefer to see the time remaining rather
than the elapsed time. I've attached a patch against the current CVS
sources that adds this functionality. I added a client preference to
allow the user to choose which format to show.

I thought about binding this to a button, but that seems like a
finite resource. How are buttons allocated? Are there any plans for
an interface that would allow users to configure which buttons do
what?


(PS. Hi. I'm new here. Just got a Slim Player last week, and I'm
still familiarizing myself with the server.)
To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dean blackketter
2003-02-22 12:55:16 UTC
Permalink
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] Time
Remaining</title></head><body>
<div>Hi Aneel,</div>
<div><br></div>
<blockquote type="cite" cite>While a song is playing, I prefer to see
the time remaining rather <br>
than the elapsed time. I've attached a patch against the current CVS
<br>
sources that adds this functionality. I added a client preference to
<br>
allow the user to choose which format to show.</blockquote>
<div><br></div>
<div>Great I'll take a look.</div>
<div><br></div>
<blockquote type="cite" cite>I thought about binding this to a button,
but that seems like a <br>
finite resource. How are buttons allocated? Are there any plans for
<br>
an interface that would allow users to configure which buttons do <br>
what?</blockquote>
<div><br></div>
<div>Buttons are indeed scarce, in fact, we're almost out.&nbsp; I'm
the self-appointed &quot;keeper of the buttons&quot; and have been
trying to maintain the consistency of the user interface.&nbsp; We
haven't worked on any button customization interface yet.&nbsp; I've
been spending my time trying to come up with one really good
interface.&nbsp; (Perl-saavy users certainly have everything they need
to customize their buttons.&nbsp; :-)</div>
<div><br></div>
<div>For this particular feature, though, the PIP button might be
appropriate.&nbsp; When you press PIP you get jumped to the current
playlist.&nbsp; Pressing it again rotates through four different
&quot;Now Playing&quot; versions on the top line:</div>
<div><br></div>
<div>Now Playing (n of m) + Elapsed time</div>
<div>Now Playing (n of m) + Progress bar</div>
<div>Now Playing (n of m) + Progress bar + Elapsed Time</div>
<div>Now Playing (n of m)</div>
<div><br></div>
<div>To use your change we could add two more displays:</div>
<div><br></div>
<div>Now Playing (n of m) + Remaining time</div>
<div>Now Playing (n of m) + Progress bar + Remaining Time</div>
<div><br></div>
<div>Two issues:&nbsp; </div>
<div><br></div>
<div>1. It might be hard to distinguish remaining time from elapsed
time quickly, but if you wait a second, it becomes obvious.&nbsp; It
might be hard to flip through the choices and pick the right
one.</div>
<div><br></div>
<div>2. This is probably the limit of the number of views we can have
for this button.&nbsp; Otherwise it becomes tedious to find the one
you want.</div>
<div><br></div>
<div>If you want to take a crack at adding this to the PIP button
(check out lib/SliMP3/Buttons/Playlist.pm) and submit another patch,
that would be great.&nbsp; It would be particularly great if the
settings page for the client had a pop-up menu that allowed the user
to select between all six combinations.</div>
<div><br></div>
<blockquote type="cite" cite>(PS. Hi. I'm new here. Just got a Slim
Player last week, and I'm <br>
still familiarizing myself with the server.)</blockquote>
<div><br>
Welcome!</div>
<div><br></div>
<div>-dean</div>
</body>
</html>

Loading...