PDA

View Full Version : INPUT.List -> overlayRef



mherger
2005-09-02, 07:41
Still discovering INPUT.* modes... This time I'm struggling with the
..List's overlayRef parameter. I'm trying to set the playing note on the
_second_ line. According to the docs I have several options:

- scalar: the overlay will be displayed on the first line

- array: the array's values are considered corresponding to the list's
values and are displayed in the first line. If I pass an [undef,
notesymbol] (assuming the first ist for the first line, the second for the
second), INPUT.List would display the notesymbol for the second value in
the list in the top line, but nothing in the second, nor for the other
list entries

- sub returning a %lines hash: does work, but seems a bit overkill

Is this by design? Is there no easy way to set an overlay2 value?

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

Grotus
2005-09-02, 10:08
Michael Herger blurted out:
> Still discovering INPUT.* modes... This time I'm struggling with the
> .List's overlayRef parameter. I'm trying to set the playing note on the
> _second_ line. According to the docs I have several options:
>
> - scalar: the overlay will be displayed on the first line
>
> - array: the array's values are considered corresponding to the list's
> values and are displayed in the first line. If I pass an [undef,
> notesymbol] (assuming the first ist for the first line, the second for
> the second), INPUT.List would display the notesymbol for the second
> value in the list in the top line, but nothing in the second, nor for
> the other list entries
>
> - sub returning a %lines hash: does work, but seems a bit overkill
>
> Is this by design? Is there no easy way to set an overlay2 value?
>

overlayRef => sub {[undef,notesymbol} is probably what you are looking for.

The array option is kind of weird. It assumes that you are providing an
overlay for each item in the list, where each entry in that array could
itself be a scalar/array/coderef. I just haven't thought of a good way
to support the simple one array for all items in the list (other than by
using a code ref).

Grotus
2005-09-02, 10:13
Robert Moser blurted out:
> overlayRef => sub {[undef,notesymbol} is probably what you are looking for.

Whoops, this should be returning an array, not an array ref. But then
again you already got it right in the RadioIO plugin.

Grotus
2005-09-02, 10:25
Robert Moser blurted out:
> The array option is kind of weird. It assumes that you are providing an
> overlay for each item in the list, where each entry in that array could
> itself be a scalar/array/coderef. I just haven't thought of a good way
> to support the simple one array for all items in the list (other than by
> using a code ref).

Sorry to keep responding to myself.

How does this sound:

Have a value for *RefArgs which lets getExtVal know that the array ref
in *Ref is to be used as the value as opposed to the value at $listindex
in that array. Maybe having an "a" in *RefArgs would be the signal.

Then the code change to INPUT.List would be this:
sub getExtVal {
my ($client, $value, $listIndex, $source) = @_;
my $extref = $client->param($source);
my $extval;
+ my $argtype = $client->param($source . 'Args');

- if (ref($extref) eq 'ARRAY') {
+ if (ref($extref) eq 'ARRAY' &&
+ !(defined $argtype && $argtype =~ /a/i)) {
$extref = $extref->[$listIndex];
}

if (!ref($extref)) {
return $extref;
} elsif (ref($extref) eq 'CODE') {
my @args;
- my $argtype = $client->param($source . 'Args');
push @args, $client if $argtype =~ /c/i;
push @args, $value if $argtype =~ /v/i;
push @args, $listIndex if $argtype =~ /i/i;
return $extref->(@args);
} elsif (ref($extref) eq 'HASH') {
return $extref->{$value};
} elsif (ref($extref) eq 'ARRAY') {
return @$extref;
} else {
return undef;
}
}

mherger
2005-09-03, 03:24
>> The array option is kind of weird. It assumes that you are providing an
>> overlay for each item in the list, where each entry in that array could
>> itself be a scalar/array/coderef. I just haven't thought of a good way
>> to support the simple one array for all items in the list (other than
>> by using a code ref).

I don't know where it is used. But imho there's much more use of overlays
for the second line. When I browse through a list (as this is typically
done with INPUT.List), the first line is rather static, while the second
changes. Indication to access a sub-level usually show up in the second
line. I therefore expected the simple case of a scalar value to be shown
in the second line. Is there any use of this for the first line?

> Have a value for *RefArgs which lets getExtVal know that the array ref
> in *Ref is to be used as the value as opposed to the value at $listindex
> in that array.

I had to read that paragraph at least three times... And then read the
documentation. Than again that paragraph. I think now I know what you mean
(I never made use of the *RefArgs). This might be a good option.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

Triode
2005-09-03, 05:22
Given I'm trying to move from arrays to hashes for displays, I was looking to see how something similar could be done with a hash.

As per my previous post I think the CODE version works, but I am not sure that a hash would.

Robert - did you have any views on my previous post. Do you think baseDisplayRef defining the overlay is appropriate in place of or
as well as overlayRef?

Adrian

----- Original Message -----
From: "Michael Herger" <slim (AT) herger (DOT) net>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Saturday, September 03, 2005 11:24 AM
Subject: Re: [Developers] INPUT.List -> overlayRef


>>> The array option is kind of weird. It assumes that you are providing an overlay for each item in the list, where each entry in
>>> that array could itself be a scalar/array/coderef. I just haven't thought of a good way to support the simple one array for
>>> all items in the list (other than by using a code ref).
>
> I don't know where it is used. But imho there's much more use of overlays for the second line. When I browse through a list (as
> this is typically done with INPUT.List), the first line is rather static, while the second changes. Indication to access a
> sub-level usually show up in the second line. I therefore expected the simple case of a scalar value to be shown in the second
> line. Is there any use of this for the first line?
>
>> Have a value for *RefArgs which lets getExtVal know that the array ref in *Ref is to be used as the value as opposed to the
>> value at $listindex in that array.
>
> I had to read that paragraph at least three times... And then read the documentation. Than again that paragraph. I think now I
> know what you mean (I never made use of the *RefArgs). This might be a good option.
>
> --
>
> Michael
>
> -----------------------------------------------------------
> Help translate SlimServer by using the
> StringEditor Plugin (http://www.herger.net/slim/)
>

Grotus
2005-09-03, 11:22
Triode blurted out:
> Given I'm trying to move from arrays to hashes for displays, I was
> looking to see how something similar could be done with a hash.
>
> As per my previous post I think the CODE version works, but I am not
> sure that a hash would.

Nope, a hash wouldn't because the way it is set up for a hash is to use
the current value as a key to look up an external value.

> Robert - did you have any views on my previous post. Do you think
> baseDisplayRef defining the overlay is appropriate in place of or as
> well as overlayRef?

I think it would be fine, the code you posted previously seemed to be
backward compatible, which is all I really care about.

Grotus
2005-09-03, 11:32
Michael Herger blurted out:
>>> The array option is kind of weird. It assumes that you are providing
>>> an overlay for each item in the list, where each entry in that array
>>> could itself be a scalar/array/coderef. I just haven't thought of a
>>> good way to support the simple one array for all items in the list
>>> (other than by using a code ref).
>
>
> I don't know where it is used. But imho there's much more use of
> overlays for the second line. When I browse through a list (as this is
> typically done with INPUT.List), the first line is rather static, while
> the second changes. Indication to access a sub-level usually show up in
> the second line. I therefore expected the simple case of a scalar value
> to be shown in the second line. Is there any use of this for the first
> line?

The problem I guess is that I attempted to reuse code with getExtVal for
things which are somewhat different.

When you are using getExtVal to get the external value for an internal
list item, everything makes sense. For instance, you have an array of
internal values (listRef) and for display another array of external
values. Alternatively, you could have a hash to lookup the external
value based on the actual value instead of the index. Or for more
complicated things, you could provide a code reference to figure out
what to show the user. The end result is always scalar in these cases,
as we are just translating our internal value into an external one.

When we then try to use this same mechanism for doing the overlay array,
things start to make less sense. We are now taking a scalar and trying
to get an array back. For the complicated case things still work well,
a code reference which returns possibly different arrays based on the
item in the list (for example an arrow for a descendable item or a note
for a single playable item). The hash and array ref options make a bit
less sense in this case.