PDA

View Full Version : use of prevline1/2 by CLI and xPL code



Triode
2005-05-31, 14:10
Hi,

I've been looking at the server display code with a view to aligning the text and graphics code a bit more.

I am trying to understand what $client->prevline1 and prevline2 should be storing. At present they are used internally for the text
display code, but they are also used by the "display ? ?" cli commands and something in xPL.pm. However I don't think these will
return the same thing for text vs graphics players. So what is the desired operation?

I think text players will store the whole line (including overlay) in each of prevlineX, but this will include all the escape
sequences for special characters. It will also be full of special character sequences in double line mode.

Graphics players will currently only store line1 and line2 (no overlays) exactly as in the call to update.

So what should be stored? Just raw line1, line2 with no escape sequences as per the graphics code? (so in text double mode it is
readable?)
It would also be possible to separately store the overlay for each line.

Adrian

Fred
2005-05-31, 16:17
Adrian,

I really can't answer your question about what should prevline1 contain.

What I can tell you is that there are 2 commands to get the displayed
information on players in the CLI: display and displaynow.

displaynow uses prevline1.
display uses Slim::Display::Display::curLines($client).

Historically, before the invention of graphical players, the intention
of having two commands was to have one returning "readable" text, and
the other returning the actual text along with the "graphics".

Then came the SqueezeBoxG, display stuff was changed a lot, developpers
got exited, and the CLI commands were somehow kept working. Barely.

Today I don't think these commands are really appropriate, in particular
because the way they operate is really different for graphical or non
graphical players, and also because if you ask the box to show something
using the display command, what you just sent and that is shown on the
player is *NOT* returned by display ? ? (but by displaynow, unless you
are on a nonG box in double size mode in which case you have the
graphical chars). Go figure.

What we need (in the CLI and I guess that applies to xPL as well, the
intention is the same) are calls that allow us to have a CLI command
that returns:

- if there is graphics shown (that never happens for non G boxes, but
that would be true, say, if the analog VU meter screen saver is on)
- if there is text shown (G box support both text and graphics, so both
can be true)
-- the line 1 (and alignment?)
-- the line 2 (if any, depends on font/size, with alignment)
-- the font size

with a corresponding "display this" command (for text).
Right now I could probably manage to sort out part of this with prevline
and stuff, but not as cleanly as if proper support was in the server
display code (which may be, I just did not investigate it really until now).

I hope this helps move the thingy forward a tiny bit.

Fred




Triode wrote:

> Hi,
>
> I've been looking at the server display code with a view to aligning the
> text and graphics code a bit more.
>
> I am trying to understand what $client->prevline1 and prevline2 should
> be storing. At present they are used internally for the text display
> code, but they are also used by the "display ? ?" cli commands and
> something in xPL.pm. However I don't think these will return the same
> thing for text vs graphics players. So what is the desired operation?
>
> I think text players will store the whole line (including overlay) in
> each of prevlineX, but this will include all the escape sequences for
> special characters. It will also be full of special character sequences
> in double line mode.
>
> Graphics players will currently only store line1 and line2 (no overlays)
> exactly as in the call to update.
>
> So what should be stored? Just raw line1, line2 with no escape
> sequences as per the graphics code? (so in text double mode it is
> readable?)
> It would also be possible to separately store the overlay for each line.
>
> Adrian

gorstk
2005-05-31, 19:56
Triode wrote:
> Hi,
>
> I've been looking at the server display code with a view to aligning the
> text and graphics code a bit more.
>
> I am trying to understand what $client->prevline1 and prevline2 should
> be storing. At present they are used internally for the text display
> code, but they are also used by the "display ? ?" cli commands and
> something in xPL.pm. However I don't think these will return the same
> thing for text vs graphics players. So what is the desired operation?

I think that all the references to prevline1&2 have been edited out of
xPL.pm in the recent updates. There did not seem to be much point in
them as we already detail the playing status, album, artist and track
name in the new version.

CouchPotatoe
2005-06-01, 05:28
Triode wrote:

> Hi,
>
> I've been looking at the server display code with a view to aligning
> the text and graphics code a bit more.
>
Hi,

Maybe related to any changes you might make here, a while back
there was a thread about the usefulness of a number of user (CLI)
accessible display screens , it would be really nice to see something
along these, or similar lines. I use the Slim devices extensively as
display devices showing callerID, emails, security status (at night) ,
TV reminders, IM online status etc. I haven't kept up with quite what
is now offered by 'overlay' so maybe it's not so appropriate now

http://lists.slimdevices.com/archives/developers/2005-January/011426.html

have a peruse further down the thread too.


Kevin

Triode
2005-06-01, 11:32
> displaynow uses prevline1.
> display uses Slim::Display::Display::curLines($client).
>
Right:
prevline - will give you the last thing that was displayed (text) or rendered(graphics)
Slim::Display::Display::curLines($client) - gives something slimilar to what would be displayed if update() was called now

Hence they could be completely different, but may not be.

> Today I don't think these commands are really appropriate, in particular because the way they operate is really different for
> graphical or non graphical players, and also because if you ask the box to show something using the display command, what you just
> sent and that is shown on the player is *NOT* returned by display ? ? (but by displaynow, unless you are on a nonG box in double
> size mode in which case you have the graphical chars). Go figure.

How about the cli code reaching into the new renderCache I've added to the 6.1 graphics code. You can see all the "parts" of the
last rendered screen for a player. [Under all normal circumstances this will be what is currently displayed. There are cases where
things are rendered, but not imediately displayed [e.g. for scrolling menus], but I would not expect the cli commands to execute at
this point in time.]

Hence you could read:
$client->renderCache()->{line1} - line 1 text excluding overlay
$client->renderCache()->{line2} - line 2 text excluding overlay
$client->renderCache()->{overlay1} - right justified overlay for line 1
$client->renderCache()->{overlay2}
$client->renderCache()->{center1} - centered text for line 1
$client->renderCache()->{center2}

[please don't write to the renderCache though!]

To display in each location, the write command should call $client->update($parts)
where $parts->{line1} = line1 etc

And the point to this - well I've been looking at making the text display align with the graphics one as far as text rendering is
concerned, so potentially the above would work for a text player too.... Would this remove the need for prevline1/prevline2?

Adrian

fcm4711
2005-06-02, 05:52
Hi there

I am currently using prevline1 and prevline2 in my ShadowPlay plugin to mirror a showBriefly() display content.
Where can I get this content from if you remove prevline1 and 2?

Thanks
Felix

Triode
2005-06-02, 11:05
> I am currently using prevline1 and prevline2 in my ShadowPlay plugin to
> mirror a showBriefly() display content.
> Where can I get this content from if you remove prevline1 and 2?

Definately not proposing to remove it if people depend on it - rather find what people expected it to return.

However at present I would say it shows different things for differernt players and does not return all displays - for instance on a
graphics player it misses centred text etc.

On a graphics player on 6.1 trunk you can get the same info with:
$client->renderCache()->{line1} - line 1 text excluding overlay
$client->renderCache()->{line2} - line 2 text excluding overlay

In fact prevline1 and 2 simply returns these. Perhaps this is the best solution to standardise all players to act the the graphical
ones?

Dean - any views?

Adrian

dean
2005-06-02, 14:44
The renderCache is the way to go if you need to access what was last
sent to the player.

I will submit, though, that there are relatively few things that you
will need it for.

-dean

On Jun 2, 2005, at 11:05 AM, Triode wrote:

>> I am currently using prevline1 and prevline2 in my ShadowPlay
>> plugin to
>> mirror a showBriefly() display content.
>> Where can I get this content from if you remove prevline1 and 2?
>>
>
> Definately not proposing to remove it if people depend on it -
> rather find what people expected it to return.
>
> However at present I would say it shows different things for
> differernt players and does not return all displays - for instance
> on a graphics player it misses centred text etc.
>
> On a graphics player on 6.1 trunk you can get the same info with:
> $client->renderCache()->{line1} - line 1 text excluding overlay
> $client->renderCache()->{line2} - line 2 text excluding overlay
>
> In fact prevline1 and 2 simply returns these. Perhaps this is the
> best solution to standardise all players to act the the graphical
> ones?
>
> Dean - any views?
>
> Adrian
>