PDA

View Full Version : Graphics - question for plugin developers



Triode
2005-08-11, 14:21
Hi,

Quick question for plugin developers [plus Dean]

Does anyone use $client->param('font', ...) to fix the font for their mode display?

Its not used by the server or any shipped plugins and if I depreciate it (to be replaced by a more flexible which allows fonts to by
the lines function), I can do a bit of extra caching the default fonts during rendering.

Adrian

kdf
2005-08-11, 14:33
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> Hi,
>
> Quick question for plugin developers [plus Dean]
>
> Does anyone use $client->param('font', ...) to fix the font for their mode
> display?

I don't believe any of mine do, and if I'm wrong, I'm ready to make changes :)\
(might want to re-post to Plugins forum just in case not all the plugin authors
are subscribed here)
-k

dean
2005-08-11, 14:33
The only thing that might have used it was the firmware update screen
("Press and hold BRIGHTNESS..."), which was broken the last time I
noticed. (It should default to the small font so that the full text
fits on the screen.)


On Aug 11, 2005, at 2:21 PM, Triode wrote:

> Hi,
>
> Quick question for plugin developers [plus Dean]
>
> Does anyone use $client->param('font', ...) to fix the font for
> their mode display?
>
> Its not used by the server or any shipped plugins and if I
> depreciate it (to be replaced by a more flexible which allows fonts
> to by the lines function), I can do a bit of extra caching the
> default fonts during rendering.
>
> Adrian
>

mherger
2005-08-11, 14:34
> Does anyone use $client->param('font', ...) to fix the font for their
> mode display?

Never heard abou it :-)

--

Michael

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

kdf
2005-08-11, 15:09
Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> The only thing that might have used it was the firmware update screen
> ("Press and hold BRIGHTNESS..."), which was broken the last time I
> noticed. (It should default to the small font so that the full text
> fits on the screen.)

d'oh...thought I fixed that(?)

I believe it used $client->textSize() anyway.

-kdf

Triode
2005-08-11, 15:41
> d'oh...thought I fixed that(?)
>
> I believe it used $client->textSize() anyway.
>

Yes it uses $client->textSize so won't be impacted by this. What's actually wrong with it btw it does look like it sets the
textSize to 0 before displaying anything. [I've not tried it though]

I suspect it is only people who have looked at the server code in detail who know the 'fonts' param exists ...

kdf
2005-08-11, 16:03
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> > d'oh...thought I fixed that(?)
> >
> > I believe it used $client->textSize() anyway.
> >
>
> Yes it uses $client->textSize so won't be impacted by this. What's actually
> wrong with it btw it does look like it sets the
> textSize to 0 before displaying anything. [I've not tried it though]
>
> I suspect it is only people who have looked at the server code in detail who
> know the 'fonts' param exists ...

heh, from the comments at change 2149 when this was introduced, it looks like it
might have even been my code. I dont even remeber it was there :))

I guess that must have been part of the modified parts to the patch I sent in
there somewhere. Clearly not a critical bit, and I can't see it used in any of
the 40+ plugins I have stored here.
--kdf

fcm4711
2005-08-12, 02:46
Hi all

Fine with me. I thought I might have used it for TinyLittlePacMan but checking the code revealed I didn't. :)

Felix

Triode
2005-08-12, 13:30
OK here's a prototype of what I have been playing with.

The idea is for lines functions to return a hash of components and to allow this to also contain definitions which override the
default fonts on a per component basis rather than just the whole line as in the current server code.

The patch includes a demo using the new alarm bell sign in DataTime - this is displayed all the time as overlay1 with a fixed font
even though the rest of date time changes as you change the font size.

Plugin developers - I'd be interested in feedback on the format of the hash the lines function is returning:

return {
'center1' => Slim::Utils::Misc::longDateF(),
'center2' => Slim::Utils::Misc::timeF(),
'overlay1'=> ($alarmOn ? $client->symbols('bell') : undef),
'fonts' => {
'graphic-280x16' => { 'overlay1' => \ 'small.1' },
'graphic-320x32' => { 'overlay1' => \ 'standard.1' },
'text' => { 'displayoverlays' => 1 },
},
};

The fonts bit means:
for SBG (280x16) use "small.1" as the font for overlay1 [all other fonts are as defaults, you can specify all of them if you
want as extra elements in this hash]
for SB2 (320x32) use "standard.1" as the font for overlay1
for SB1/SLIMP3 (text) - display overlays even in doubled mode

Are the player names ('graphic-280x16' etc) appropriate or should I create some new ones? [these use $client->vdfmodel() for the
graphic player names]

Adrian

dean
2005-08-12, 14:17
I wonder if there's a way we can make it simpler for the caller for
the simple case:

> return {
> 'center1' => Slim::Utils::Misc::longDateF(),
> 'center2' => Slim::Utils::Misc::timeF(),
> 'overlay1'=> ($alarmOn ? $client->symbols('bell') : undef),
> 'fonts' => {
> 'graphic-280x16' => 'small',
> 'graphic-320x32' => 'standard',
> 'text' => 1,
> },
> };

Would this also work?


On Aug 12, 2005, at 1:30 PM, Triode wrote:

> OK here's a prototype of what I have been playing with.
>
> The idea is for lines functions to return a hash of components and
> to allow this to also contain definitions which override the
> default fonts on a per component basis rather than just the whole
> line as in the current server code.
>
> The patch includes a demo using the new alarm bell sign in DataTime
> - this is displayed all the time as overlay1 with a fixed font even
> though the rest of date time changes as you change the font size.
>
> Plugin developers - I'd be interested in feedback on the format of
> the hash the lines function is returning:
>
> return {
> 'center1' => Slim::Utils::Misc::longDateF(),
> 'center2' => Slim::Utils::Misc::timeF(),
> 'overlay1'=> ($alarmOn ? $client->symbols('bell') : undef),
> 'fonts' => {
> 'graphic-280x16' => { 'overlay1' => \ 'small.1' },
> 'graphic-320x32' => { 'overlay1' => \ 'standard.1' },
> 'text' => { 'displayoverlays' => 1 },
> },
> };
>
> The fonts bit means:
> for SBG (280x16) use "small.1" as the font for overlay1 [all
> other fonts are as defaults, you can specify all of them if you
> want as extra elements in this hash]
> for SB2 (320x32) use "standard.1" as the font for overlay1
> for SB1/SLIMP3 (text) - display overlays even in doubled mode
>
> Are the player names ('graphic-280x16' etc) appropriate or should I
> create some new ones? [these use $client->vdfmodel() for the
> graphic player names]
>
> Adrian
>
> <fontlines2.diff>
>

Triode
2005-08-12, 14:56
>I wonder if there's a way we can make it simpler for the caller for the simple case:
>
>> return {
>> 'center1' => Slim::Utils::Misc::longDateF(),
>> 'center2' => Slim::Utils::Misc::timeF(),
>> 'overlay1'=> ($alarmOn ? $client->symbols('bell') : undef),
>> 'fonts' => {
>> 'graphic-280x16' => 'small',
>> 'graphic-320x32' => 'standard',
>> 'text' => 1,
>> },
>> };
>
> Would this also work?

Yes we ought to be able to do something like this. Won't actually work for the DataTime example, but I can see the benefit for
other cases - I'll look at how to do whilst minimising the comparisons done by render.

By 'text' => 1 do you mean single line mode?

dean
2005-08-12, 20:10
On Aug 12, 2005, at 2:56 PM, Triode wrote:

>> I wonder if there's a way we can make it simpler for the caller
>> for the simple case:
>>
>>
>>> return {
>>> 'center1' => Slim::Utils::Misc::longDateF(),
>>> 'center2' => Slim::Utils::Misc::timeF(),
>>> 'overlay1'=> ($alarmOn ? $client->symbols('bell') : undef),
>>> 'fonts' => {
>>> 'graphic-280x16' => 'small',
>>> 'graphic-320x32' => 'standard',
>>> 'text' => 1,
>>> },
>>> };
>>>
>>
>> Would this also work?
>>
>
> Yes we ought to be able to do something like this. Won't actually
> work for the DataTime example, but I can see the benefit for other
> cases - I'll look at how to do whilst minimising the comparisons
> done by render.
Right. For, example on the "Press and hold BRIGHTNESS..." screen, I
just want to specify a global font...

> By 'text' => 1 do you mean single line mode?
Yes. That's the closest thing we have to fonts on the character
displays.

Triode
2005-08-13, 14:12
> Right. For, example on the "Press and hold BRIGHTNESS..." screen, I just want to specify a global font...

OK - how about this:

$client->showBlocked( {
'line1' => string('PLAYER_NEEDS_UPGRADE_1'),
'line2' => string('PLAYER_NEEDS_UPGRADE_2'),
'fonts' => {
'graphic-320x32' => 'standard',
'graphic-280x16' => 'small',
'text' => 2,
}
});

I have a patch working with this:
- changes to block/unblock to support a hash
- new methods $client->showBlocked and $client->unblock to wrap round them so all display functions become methods

Assuming you like the api, I'll post the patch for comment [and then I might get round to writing some instructions on what the
different elements do!]

dean
2005-08-13, 14:48
The syntax looks good.

I'm not following on the showBlocked and unblock bit, though...

On Aug 13, 2005, at 2:12 PM, Triode wrote:

>> Right. For, example on the "Press and hold BRIGHTNESS..." screen,
>> I just want to specify a global font...
>>
>
> OK - how about this:
>
> $client->showBlocked( {
> 'line1' => string('PLAYER_NEEDS_UPGRADE_1'),
> 'line2' => string('PLAYER_NEEDS_UPGRADE_2'),
> 'fonts' => {
> 'graphic-320x32' => 'standard',
> 'graphic-280x16' => 'small',
> 'text' => 2,
> }
> });
>
> I have a patch working with this:
> - changes to block/unblock to support a hash
> - new methods $client->showBlocked and $client->unblock to wrap
> round them so all display functions become methods
>
> Assuming you like the api, I'll post the patch for comment [and
> then I might get round to writing some instructions on what the
> different elements do!]
>

Triode
2005-08-13, 15:53
> I'm not following on the showBlocked and unblock bit, though...

I can get rid of this if it doesn't make sence, I just wanted to unify the display functions so you have:

$client->update
$client->showBriefly
$client->showBlocked

As the calls which put something on the screen.

showBlocked doing something similar to showBriefly, but puts the player into blocked mode until unblock is called.

showBlocked is just a wrapper to call Slim::Buttons::Blocked::block().

Get rid of it?

dean
2005-08-13, 23:57
I see.

How about $client->block() and $client->unblock() as simple mappings
to Slim::Buttons::Block::block() & unblock()

On Aug 13, 2005, at 3:53 PM, Triode wrote:

>> I'm not following on the showBlocked and unblock bit, though...
>>
>
> I can get rid of this if it doesn't make sence, I just wanted to
> unify the display functions so you have:
>
> $client->update
> $client->showBriefly
> $client->showBlocked
>
> As the calls which put something on the screen.
>
> showBlocked doing something similar to showBriefly, but puts the
> player into blocked mode until unblock is called.
>
> showBlocked is just a wrapper to call Slim::Buttons::Blocked::block().
>
> Get rid of it?
>
>
>
>
>

Triode
2005-08-14, 12:33
OK here's a patch with the ability to set fonts using the display hash as discussed in this thread, plus $client->block/unblock.
I've included DateTime as an example of this.

I've also written a description of the display hash and how to use it within display fcuntions - please read and comment on whether
you understand it! If you do please consider for furture updates for your plugins.

[Dean - let me know if you are happy with the patch and I'll commit.]

Adrian

Fred
2005-08-14, 13:16
Adrian,

Doc looks very clear to me... I am just missing a function to get the
current hash from a client (for the CLI display function, that I plan
to update once your path is in).

Thanks

Fred


On 14 août 05, at 21:33, developers-request (AT) lists (DOT) slimdevices.com wrote:

> From: "Triode" <triode1 (AT) btinternet (DOT) com>
> Date: 14 août 2005 21:33:11 GMT+02:00
> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> Subject: Re: [Developers] Graphics - question for plugin developers
> Reply-To: Slim Devices Developers <developers (AT) lists (DOT) slimdevices.com>
>
>
> OK here's a patch with the ability to set fonts using the display
> hash as discussed in this thread, plus $client->block/unblock.
> I've included DateTime as an example of this.
>
> I've also written a description of the display hash and how to use
> it within display fcuntions - please read and comment on whether
> you understand it! If you do please consider for furture updates
> for your plugins.
>
> [Dean - let me know if you are happy with the patch and I'll commit.]
>
> Adrian
>
>
> <fontlines3.diff>
> <display.txt>
>
>

Triode
2005-08-14, 13:35
Fred,

If you want to know the last thing rendered (almost certainly the last thing displayed on a client), then you can read this out of
the renderCache:

$client->renderCache() returns the hash that represents the render cache

This contains all of the following:
'line1', 'line2', 'overlay1', 'overlay2', 'center1', 'center2' and many internal render variables.

If you stick to the componets above and don't set any of them you should be fine.

Adrian

----- Original Message -----
From: "Frédéric Thomas" <fred (AT) thomascorner (DOT) com>
To: <developers (AT) lists (DOT) slimdevices.com>
Sent: Sunday, August 14, 2005 9:16 PM
Subject: Re: [Developers] Graphics - question for plugin developers


Adrian,

Doc looks very clear to me... I am just missing a function to get the
current hash from a client (for the CLI display function, that I plan
to update once your path is in).

Thanks

Fred


On 14 août 05, at 21:33, developers-request (AT) lists (DOT) slimdevices.com wrote:

> From: "Triode" <triode1 (AT) btinternet (DOT) com>
> Date: 14 août 2005 21:33:11 GMT+02:00
> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> Subject: Re: [Developers] Graphics - question for plugin developers
> Reply-To: Slim Devices Developers <developers (AT) lists (DOT) slimdevices.com>
>
>
> OK here's a patch with the ability to set fonts using the display hash as discussed in this thread, plus $client->block/unblock.
> I've included DateTime as an example of this.
>
> I've also written a description of the display hash and how to use it within display fcuntions - please read and comment on
> whether you understand it! If you do please consider for furture updates for your plugins.
>
> [Dean - let me know if you are happy with the patch and I'll commit.]
>
> Adrian
>
>
> <fontlines3.diff>
> <display.txt>
>
>

dean
2005-08-15, 13:32
Looks really good. Go for it.

On Aug 14, 2005, at 12:33 PM, Triode wrote:

> OK here's a patch with the ability to set fonts using the display
> hash as discussed in this thread, plus $client->block/unblock.
> I've included DateTime as an example of this.
>
> I've also written a description of the display hash and how to use
> it within display fcuntions - please read and comment on whether
> you understand it! If you do please consider for furture updates
> for your plugins.
>
> [Dean - let me know if you are happy with the patch and I'll commit.]
>
> Adrian
>
>
> <fontlines3.diff>
> <display.txt>
>

Fred
2005-08-15, 15:20
Adrian,

Thanks. Now what if a screen saver is active, say the cute analog VU
Meters? Do you keep track somewhere of "what" did render last (the
renderCache or some other graphical thingy, and if so could we have
the name of it?)

From a CLI perspective, there could be a lot of added value to be
able to know WHAT is on the screen. I don't think we care about
animation and stuff, but I would like a query like:

<playerid> displayed ?
<playerid> displayed graphics:1 source:screensaver source_name:Analog
VU Meter

<playerid> displayer ?
<playerid> displayed text:1 line1:"Bla bla bla" ...

I guess that would require an additional "source_name" field in the
hash you get (for graphics or whatever). I guess I could just patch
the code to add that to callers and you would ignore it, it's just
the CLI could get it back from it's call to renderCache()...

Fred







On 15 août 05, at 21:00, developers-request (AT) lists (DOT) slimdevices.com wrote:

> Fred,
>
> If you want to know the last thing rendered (almost certainly the
> last thing displayed on a client), then you can read this out of
> the renderCache:
>
> $client->renderCache() returns the hash that represents the render
> cache
>
> This contains all of the following:
> 'line1', 'line2', 'overlay1', 'overlay2', 'center1', 'center2' and
> many internal render variables.
>
> If you stick to the componets above and don't set any of them you
> should be fine.
>
> Adrian
>

Triode
2005-08-16, 13:35
Fred,

The SB2 visualizers produced by the player firmware and hence the server does not know the specifics of what is displayed

However for all text placed on the screen, including the scrolling text in the Spectrum Analyser screensaver, the server knows what
is showing as it has to convert the text to the bitmap sent to the player. The renderCache stores the last thing rendered [rather
than last screen sent to the player], but unless anyone writes code which calls $client->render() directly then these should be the
same thing - so I think the best option is just to read 'line1' 'line2' etc out of the renderCache for this.

The render cache stores lots of other things critical to scrolling text etc and so I wouldn't want anyone altering its contents! If
you think it would be a common requirement to extract the currently displayed text I could add a new client method for this.

So back to visualizers. The server knows which one is being displayed as it tells the client to display it and caches the last one
in $client->lastVisMode. However this is a reference to an array for which the first element defines the type of visulalizer, but
you need to read the rest to understand if it is the full screen or just the small version. [See Slim/Player/Squeezebox2.pm] I
think reading @{$client->lastVisMode}[0] would tell you whether a visualizer is active and which one it is (not sure that is the
correct syntax).

Adrian

----- Original Message -----
From: "Frédéric Thomas" <fred (AT) thomascorner (DOT) com>
To: <developers (AT) lists (DOT) slimdevices.com>
Sent: Monday, August 15, 2005 11:20 PM
Subject: Re: [Developers] Graphics - question for plugin developers


Adrian,

Thanks. Now what if a screen saver is active, say the cute analog VU
Meters? Do you keep track somewhere of "what" did render last (the
renderCache or some other graphical thingy, and if so could we have
the name of it?)

From a CLI perspective, there could be a lot of added value to be
able to know WHAT is on the screen. I don't think we care about
animation and stuff, but I would like a query like:

<playerid> displayed ?
<playerid> displayed graphics:1 source:screensaver source_name:Analog
VU Meter

<playerid> displayer ?
<playerid> displayed text:1 line1:"Bla bla bla" ...

I guess that would require an additional "source_name" field in the
hash you get (for graphics or whatever). I guess I could just patch
the code to add that to callers and you would ignore it, it's just
the CLI could get it back from it's call to renderCache()...

Fred







On 15 août 05, at 21:00, developers-request (AT) lists (DOT) slimdevices.com wrote:

> Fred,
>
> If you want to know the last thing rendered (almost certainly the last thing displayed on a client), then you can read this out
> of the renderCache:
>
> $client->renderCache() returns the hash that represents the render cache
>
> This contains all of the following:
> 'line1', 'line2', 'overlay1', 'overlay2', 'center1', 'center2' and many internal render variables.
>
> If you stick to the componets above and don't set any of them you should be fine.
>
> Adrian
>

Triode
2005-08-16, 13:41
Dean,

Is anywhere we can store the display.txt file so that plugin authors get a chance to read it, rather than loosing it on this list.
I was originally thinking of a small addition to the plugins html page, but I got carried away and wrote too much for this.. I'm
also not into html writing so a text file was easier...]

I am proposing to update at least the plugins in trunk to use the display hash if that is OK?

Adrian
----- Original Message -----
From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Monday, August 15, 2005 9:32 PM
Subject: Re: [Developers] Graphics - question for plugin developers


> Looks really good. Go for it.
>
> On Aug 14, 2005, at 12:33 PM, Triode wrote:
>
>> OK here's a patch with the ability to set fonts using the display hash as discussed in this thread, plus $client->block/unblock.
>> I've included DateTime as an example of this.
>>
>> I've also written a description of the display hash and how to use it within display fcuntions - please read and comment on
>> whether you understand it! If you do please consider for furture updates for your plugins.
>>
>> [Dean - let me know if you are happy with the patch and I'll commit.]
>>
>> Adrian
>>
>>
>> <fontlines3.diff>
>> <display.txt>
>>

dean
2005-08-16, 13:48
I think that it wouldn't be out of place to put it under Technical
Information in the Help area.


On Aug 16, 2005, at 1:41 PM, Triode wrote:

> Dean,
>
> Is anywhere we can store the display.txt file so that plugin
> authors get a chance to read it, rather than loosing it on this
> list. I was originally thinking of a small addition to the plugins
> html page, but I got carried away and wrote too much for this..
> I'm also not into html writing so a text file was easier...]
>
> I am proposing to update at least the plugins in trunk to use the
> display hash if that is OK?
>
> Adrian
> ----- Original Message ----- From: "dean blackketter"
> <dean (AT) slimdevices (DOT) com>
> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> Sent: Monday, August 15, 2005 9:32 PM
> Subject: Re: [Developers] Graphics - question for plugin developers
>
>
>
>> Looks really good. Go for it.
>>
>> On Aug 14, 2005, at 12:33 PM, Triode wrote:
>>
>>
>>> OK here's a patch with the ability to set fonts using the
>>> display hash as discussed in this thread, plus $client->block/
>>> unblock.
>>> I've included DateTime as an example of this.
>>>
>>> I've also written a description of the display hash and how to
>>> use it within display fcuntions - please read and comment on
>>> whether you understand it! If you do please consider for
>>> furture updates for your plugins.
>>>
>>> [Dean - let me know if you are happy with the patch and I'll
>>> commit.]
>>>
>>> Adrian
>>>
>>>
>>> <fontlines3.diff>
>>> <display.txt>
>>>

Triode
2005-08-17, 05:34
Fred, Dean,

Having thought about this a bit more I would like to propose two new methods:

$client->curLines()

To return a display hash for the current lines function - i.e a hash based version of Slim::Display::Display:curLines
[for lines functions which don't return hashes, it will call parseLines internally to so it always returns a display hash.]

$client->curDisplay()

To return the display hash currently on the screen. I propose to do this by returning a copy of relavent elements in the
renderCache, but this way the user of this function is not exposed to all the other elements in the renderCache and also can't
change them!

Would this suit your requirements and seem sensible?

Adrian
----- Original Message -----
From: "Frédéric Thomas" <fred (AT) thomascorner (DOT) com>
To: <developers (AT) lists (DOT) slimdevices.com>
Sent: Sunday, August 14, 2005 9:16 PM
Subject: Re: [Developers] Graphics - question for plugin developers


Adrian,

Doc looks very clear to me... I am just missing a function to get the
current hash from a client (for the CLI display function, that I plan
to update once your path is in).

Thanks

Fred

dean
2005-08-17, 10:46
Good by me!

On Aug 17, 2005, at 5:34 AM, Triode wrote:

> Fred, Dean,
>
> Having thought about this a bit more I would like to propose two
> new methods:
>
> $client->curLines()
>
> To return a display hash for the current lines function - i.e a
> hash based version of Slim::Display::Display:curLines
> [for lines functions which don't return hashes, it will call
> parseLines internally to so it always returns a display hash.]
>
> $client->curDisplay()
>
> To return the display hash currently on the screen. I propose to
> do this by returning a copy of relavent elements in the
> renderCache, but this way the user of this function is not exposed
> to all the other elements in the renderCache and also can't change
> them!
>
> Would this suit your requirements and seem sensible?
>
> Adrian
> ----- Original Message ----- From: "Frédéric Thomas"
> <fred (AT) thomascorner (DOT) com>
> To: <developers (AT) lists (DOT) slimdevices.com>
> Sent: Sunday, August 14, 2005 9:16 PM
> Subject: Re: [Developers] Graphics - question for plugin developers
>
>
> Adrian,
>
> Doc looks very clear to me... I am just missing a function to get the
> current hash from a client (for the CLI display function, that I plan
> to update once your path is in).
>
> Thanks
>
> Fred
>
>

Fred
2005-08-17, 15:54
That would be great!

I am probably a bit slow, but what is the difference between the two?

Fred


On 17 août 05, at 21:00, developers-request (AT) lists (DOT) slimdevices.com wrote:

> Fred, Dean,
>
> Having thought about this a bit more I would like to propose two
> new methods:
>
> $client->curLines()
>
> To return a display hash for the current lines function - i.e a
> hash based version of Slim::Display::Display:curLines
> [for lines functions which don't return hashes, it will call
> parseLines internally to so it always returns a display hash.]
>
> $client->curDisplay()
>
> To return the display hash currently on the screen. I propose to
> do this by returning a copy of relavent elements in the
> renderCache, but this way the user of this function is not exposed
> to all the other elements in the renderCache and also can't change
> them!
>
> Would this suit your requirements and seem sensible?
>
> Adrian
>

Triode
2005-08-18, 03:41
>I am probably a bit slow, but what is the difference between the two?

$client->curLines() would return the display hash that results from calling the current lines function - i.e. if a new display were
being produced now.

$client->curDisplay() would return the display hash that was last rendered and hence on the screen now. [It won't contain all the
font info, but will contain all text components - assume this is OK?]

So the differernce is that curDisplay is what is on the display, but curLines is what would go on the display now if you called
update. I would expect you to use curDisplay to show what is currently showing. curLines would be more of a replacement to
Slim::Display::Display::curLines and would be most useful in calls to pushLeft/Right etc

I'll add them to trunk and you can play with them!

Adrian