RE: Overlay idea

[Kevin Walsh]

> I'd prefer passing the overlay information as part of the string, like
> we do for cursor position, etc.
>
> Imagine a now playing screen expressed as this string:
>
> Now Playing__overlay_right__00:34\n
> 03. Mama's Got A Squeezebox__overlay_right____vfD_notesymbol_Vfd__
>
> Also note that rather than having an array of lines, we just include a
> line break character (\n) and send the whole screen as a single string.
>
> Or even better:
>
> <screen>Now Playing<rightalign>00:34</rightalign><br>
> 03. Mama's Got a Squeezebox<rightalign>&note;</rightalign></screen>
>
> Whatever system we come up with, I'd like to make sure that it can handle:
>
> - Non-fixed width characters
> - Displays with less or more than 2 lines
> - Displays with less or more than 40 characters
>
> Doing overlays that use character positions, probably won't cut it.
>
I like the XML-ish idea. It could have a <center> container too:

<screen>
<line>
<center>In the middle of the first line</center>
</line>
<line cursor="15">
<left>Some left-justified text</left>
<right>about to be overwritten</right>
<right>&note;</right>
</line>
</screen>

Shown expanded for readability only. The order of the contents of
the <line> container could determine the text overlay priority; first
block written, second block overlays, third overlays that etc.

Note that the a cursor position has been specified for the second
line.

The above would allow for your requirements list, but would not
allow for pixel-positioned objects or graphics on future displays.
If the definition was XML-ish then it would make it easier to expand
the list of available tags and facilities at a later date.

If the <left> is longer than the screen then it'll either be truncated
or scrolled, as appropriate for the individual line. I assume that if
the <center> or <right> is too long then there would be no scrolling
option, and the text would have to be truncated to fit.

I'm not sure about the &note; syntax, as people will probably expect
&lt;, &gt; and &quot; etc. to work, and it could get confusing. Perhaps
some sort of <symbol> tag would be better, such as:


<right><symbol>notesymbol</symbol></right>

or:

<right><symbol name="notesymbol" /></right>

Either would work, although it's all a bit verbose; You could get a
display specification that consists of 25% text and 75% layout code.

--
_/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/
_/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h
_/ _/ _/ _/ _/ _/ _/ _/_/ kevin (AT) cursor (DOT) biz
_/ _/ _/_/_/_/ _/ _/_/_/ _/ _/

[dean]

On Dec 5, 2003, at 3:23 PM, Kevin Walsh wrote:
> I like the XML-ish idea. It could have a <center> container too:
>
> <screen>
> <line>
> <center>In the middle of the first line</center>
> </line>
> <line cursor="15">
> <left>Some left-justified text</left>
> <right>about to be overwritten</right>
> <right>&note;</right>
> </line>
> </screen>
>
> Shown expanded for readability only. The order of the contents of
> the <line> container could determine the text overlay priority; first
> block written, second block overlays, third overlays that etc.
>
> Note that the a cursor position has been specified for the second
> line.
>
> The above would allow for your requirements list, but would not
> allow for pixel-positioned objects or graphics on future displays.
Sure it would, if you changed the cursor item to this:

<screen>
<line>
<center>In the middle of the first line</center>
</line>
<line>
<left>Some <cursor>l</cursor>eft-justified text</left>
<right>about to be overwritten</right>
<right>&note;</right>
</line>
</screen>

> If the definition was XML-ish then it would make it easier to expand
> the list of available tags and facilities at a later date.
Agreed.

> If the <left> is longer than the screen then it'll either be truncated
> or scrolled, as appropriate for the individual line. I assume that if
> the <center> or <right> is too long then there would be no scrolling
> option, and the text would have to be truncated to fit.
Sounds good.

> I'm not sure about the &note; syntax, as people will probably expect
> &lt;, &gt; and &quot; etc. to work, and it could get confusing.
> Perhaps
> some sort of <symbol> tag would be better, such as:
We can make up some new ones, after all. &note; is fine with me.

> <right><symbol>notesymbol</symbol></right>
>
> or:
>
> <right><symbol name="notesymbol" /></right>
>
> Either would work, although it's all a bit verbose; You could get a
> display specification that consists of 25% text and 75% layout code.
And a 1000% performance hit. :)


Let's keep it small and simple. Compatibility with XHTML is a bonus.

-dean