Mailing List Archive

On Friday 24 Sep 2010 15:29:26 David Engel wrote:
> I see a number of theme templates like the following.
>
> %|"SUBTITLE|"% %STARS% %DESCRIPTION%
> %|"SUBTITLE|"%\n%YEARSTARS%%DESCRIPTION%
>
> Shouldn't they be like this instead?
>
> %|"SUBTITLE|" %%STARS| %%DESCRIPTION%
> %|"SUBTITLE|"\n%%YEARSTARS%%DESCRIPTION%

In current trunk, after changes made within the week they can and should be:

%"|SUBTITLE|" %%STARS| %%DESCRIPTION%
%"|SUBTITLE|"\n%%YEARSTARS%%DESCRIPTION%

Although your suggestion would work for backwards compatibility reasons.

With the new regexp any number of characters are permitted between
"%<prepend>|" preceding the inserted string and "|<append>%" following the
string.

e.g. %Episode: |SUBTITLE|\n%%"|DESCRIPTION|"% would produce

Episode: The Accident
"Jack and Jill went up the hill to fetch a pail of water"

> It's been a very long time since I added that leading/trailing feature
> to field replacement, so perhaps it no longer works the way I think it
> does.

IIRC the original regular expression in the old UI required the following
form:

%SUBTITLE|"|"%

and it only supported a single character to be prepended/appended.

The mythui conversion changed the regexp slightly so that the prepended
character appeared at the beginning because this seemed a little clearer.
However it still only permitted a single character because I was having
trouble with the regexp, but I'd always intended to come back to it and allow
multiple characters. About a week ago I remembered that I had yet to fix the
regexp and this was finally done in [26412] ([26418] & [26451])

The template stuff in MythUI actually supports two methods, the choice of
which probably depends on the usage.

Take the following example:
<textarea name="subtitle">
<value>Unknown Episode</value> <!-- A default string, shown when subtitle
is empty -->
<template>Episode: %1</template>
</textarea>

When you have a single value in the textarea or the value does not come from a
map you may choose the above form. Benefits include the ability to show
something in place of the subtitle if no subtitle is available.

When you want to join multiple strings together, then your only choice is the
%<prefix>|VALUE|<suffix>% format.

Also worth mentioning is the plural translation form for numeric values.

<textarea name="timeleft">
<template>There is %n second(s) remaining</template>
</textarea>

This will appear as a special 'plural' string to translators and once
translated it will be displayed as:
"There is 1 second remaining"
"There are 3 seconds remaining"
--
Stuart Morgan
_______________________________________________
mythtv-theming mailing list
mythtv-theming@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-theming

On Fri, Sep 24, 2010 at 05:05:38PM +0100, Stuart Morgan wrote:
> On Friday 24 Sep 2010 15:29:26 David Engel wrote:
> > I see a number of theme templates like the following.
> >
> > %|"SUBTITLE|"% %STARS% %DESCRIPTION%
> > %|"SUBTITLE|"%\n%YEARSTARS%%DESCRIPTION%
> >
> > Shouldn't they be like this instead?
> >
> > %|"SUBTITLE|" %%STARS| %%DESCRIPTION%
> > %|"SUBTITLE|"\n%%YEARSTARS%%DESCRIPTION%
>
> In current trunk, after changes made within the week they can and should be:
>
> %"|SUBTITLE|" %%STARS| %%DESCRIPTION%
> %"|SUBTITLE|"\n%%YEARSTARS%%DESCRIPTION%

FWIW, the examples I used are from current trunk. I noticed the issue
when I glanced at Mark's change in [26488].

> Although your suggestion would work for backwards compatibility reasons.
>
> With the new regexp any number of characters are permitted between
> "%<prepend>|" preceding the inserted string and "|<append>%" following the
> string.

> IIRC the original regular expression in the old UI required the following
> form:
>
> %SUBTITLE|"|"%
>
> and it only supported a single character to be prepended/appended.

I don't recall any single character limitation. I know I used '" '
and '"\n' in some things I did. Perhaps that limitation crept in in a
rewrite or there were multiple code paths for OSD and non-OSD
replacement.

> The mythui conversion changed the regexp slightly so that the prepended
> character appeared at the beginning because this seemed a little clearer.
> However it still only permitted a single character because I was having
> trouble with the regexp, but I'd always intended to come back to it and allow
> multiple characters. About a week ago I remembered that I had yet to fix the
> regexp and this was finally done in [26412] ([26418] & [26451])

I remember your commit, but nothing caught my eye, so I didn't pay too
close attention to it.

> The template stuff in MythUI actually supports two methods, the choice of
> which probably depends on the usage.
>
> Take the following example:
> <textarea name="subtitle">
> <value>Unknown Episode</value> <!-- A default string, shown when subtitle
> is empty -->
> <template>Episode: %1</template>
> </textarea>
>
> When you have a single value in the textarea or the value does not come from a
> map you may choose the above form. Benefits include the ability to show
> something in place of the subtitle if no subtitle is available.

Good. I was going to ask about the apparent missing empty string
case.

OK, now back to my original point -- getting rid of unwanted leading
spaces and newlines. It sounds like you agree a fix is needed in some
places. If so, it looks like there are quite a few places that could
be fixed. Would that mess up the translators?

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-theming mailing list
mythtv-theming@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-theming

Coming into the thread late, but wanted to comment because I love
the power of this feature.

* On Fri Sep 24, 2010 at 12:32:46PM -0500, David Engel wrote:
> On Fri, Sep 24, 2010 at 05:05:38PM +0100, Stuart Morgan wrote:
> > IIRC the original regular expression in the old UI required the following
> > form:
> >
> > %SUBTITLE|"|"%
> >
> > and it only supported a single character to be prepended/appended.
>
> I don't recall any single character limitation. I know I used '" '
> and '"\n' in some things I did. Perhaps that limitation crept in in a
> rewrite or there were multiple code paths for OSD and non-OSD
> replacement.

The original regex should not have had any limitations that I know of on
the number of characters in any section. I added that code and we still use
a slightly more complex version of that same regex in a home-built (well,
work-built) configuration management system at work. We use the prepend and
append sections for all kinds of things and also added a 4th optional section
for a default value if the variable is empty. We call them 'match variables'
and use double percent-signs to deliniate them instead of single
percent-signs, so I modified our regex slightly at work to account for that.
We even support and use a form of recursion, since we loop over the input
text multiple times. We have some matches that when their values are
substituted form other matches in the text which are then substituted.
It's served us rather well for the past ~7 years. Our software has builtin
match variables for things like the webserver IP, doc root, etc. and the
user can also define their own.

> > The mythui conversion changed the regexp slightly so that the prepended
> > character appeared at the beginning because this seemed a little clearer.

For MythTV purposes and our limited usage, it probably is clearer to put the
keyword in the middle. At work, we apply these match replacements on text
sizes ranging from 20-30 bytes to 100KB+, and which which include things as
simple as a single line text file to a full-blown httpd.conf or virtual host
config file to even more complex items, so we matched on exactly %%KEYWORD
in order to keep the complexity of the regex down while making sure we didn't
pickup something that wasn't intended.

--
Chris
_______________________________________________
mythtv-theming mailing list
mythtv-theming@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-theming