Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

OSD timeout settings

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


jyavenard at gmail

Jun 14, 2010, 8:32 PM

Post #1 of 23 (2981 views)
Permalink
OSD timeout settings

Hi

Following http://svn.mythtv.org/trac/changeset/25102

Is the plan to have something equivalent with the new OSD theme, that
is the user can easily change the timeout settings and how long one
has to read text displayed on the screen.

If it will require to fiddle with the theme XML to adjust how long you
have to read things , that's a big drawback usability-wise IMO.

I had it set on my machine as when I change channels, it's only
displayed for 3s. But when I press info, it shows for 10s... Nothing
worse than having to press info several times because the OSD timeout
on you...
Bit WAF factor too...

Jean-Yves
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Jun 15, 2010, 8:21 AM

Post #2 of 23 (2897 views)
Permalink
Re: OSD timeout settings [In reply to]

On Tue, Jun 15, 2010 at 01:32:41PM +1000, Jean-Yves Avenard wrote:
> Following http://svn.mythtv.org/trac/changeset/25102
>
> Is the plan to have something equivalent with the new OSD theme, that
> is the user can easily change the timeout settings and how long one
> has to read text displayed on the screen.
>
> If it will require to fiddle with the theme XML to adjust how long you
> have to read things , that's a big drawback usability-wise IMO.

I agree completely. I understand the desire, even need, for the
themes to control all visual aspects such as fonts so things look
right. OSD timeouts don't affect the visual appearance of the themes
and should be easily configurable without having to edit XML.

FWIW, I'm also not thrilled with the change (unless I've misunderstood
it) that removes the ability to independently choose the OSD theme. I
have no problem with a setting that defaults to using the OSD theme
provided by the main theme, but why not let the user choose a
different OSD theme if they want to?

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


gnassas at mac

Jun 15, 2010, 9:03 AM

Post #3 of 23 (2895 views)
Permalink
Re: OSD timeout settings [In reply to]

On 2010-06-15, at 11:21 AM, David Engel wrote:

>> If it will require to fiddle with the theme XML to adjust how long you
>> have to read things , that's a big drawback usability-wise IMO.
>
> I agree completely.

I'd like to join the parade and also include the settings for subtitle sizes. Display devices vary widely and people's eyes even more so I'd really like to have a way to ensure that I can read subtitles regardless of theme.

I'm not sure about this anti-settings bent. Sure there are a lot of them but the alternative is people maintaining private patch sets to get myth to be the way they want and where's the sense in that? I think the settings are a plus.

- George
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv-dev2 at dwilga-linux1

Jun 15, 2010, 9:09 AM

Post #4 of 23 (2889 views)
Permalink
Re: OSD timeout settings [In reply to]

On 6/15/10 12:03 PM, George Nassas wrote:
> I'm not sure about this anti-settings bent. Sure there are a lot of
> them but the alternative is people maintaining private patch sets to
> get myth to be the way they want and where's the sense in that? I
> think the settings are a plus.
IMHO, attention should be paid to organizing the settings into basic and
advanced, not removing them altogether. It's just as frustrating to a
user to be sure a setting should exist and not be able to find it, as it
is to be inundated with too many settings.

--
Dan Wilga "Ook."

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Jun 15, 2010, 10:13 AM

Post #5 of 23 (2894 views)
Permalink
Re: OSD timeout settings [In reply to]

On 06/15/2010 11:21 AM, David Engel wrote:
> On Tue, Jun 15, 2010 at 01:32:41PM +1000, Jean-Yves Avenard wrote:
>
>> Following http://svn.mythtv.org/trac/changeset/25102
>>
>> Is the plan to have something equivalent with the new OSD theme, that
>> is the user can easily change the timeout settings and how long one
>> has to read text displayed on the screen.
>>
>> If it will require to fiddle with the theme XML to adjust how long you
>> have to read things , that's a big drawback usability-wise IMO.
>>
> I agree completely. I understand the desire, even need, for the
> themes to control all visual aspects such as fonts so things look
> right. OSD timeouts don't affect the visual appearance of the themes
> and should be easily configurable without having to edit XML.
>
>

There is absolutely no code in MythTV that allows the OSD timeouts to
change. This was true before I removed the widgets. If someone wants
the ability to change them, they need to write some code.

If they write the code, it needs to be done right--unlike the code we
had in the pre-libmythui-osd branch. AIUI, Mark removed that code
because it was unusable--it was inconsistent and haphazard, it wasn't
applied in all locations (so a large number of OSD screens weren't
affected by the settings). Whatever new solution we use has to be a
complete solution designed for the new OSD UI. See
http://svn.mythtv.org/trac/ticket/724 and
http://svn.mythtv.org/trac/ticket/3023 (among others).

I really don't care where we put the controls, but the point is that
there were no controls before this commit. I only removed the widgets
that flipped switches that were completely unconnected. Leaving them in
place had 2 serious down sides: a) users who flip the switches are
likely to report bugs (that are actually feature requests) when they
don't work and b) leaving them in place means that whoever writes the
code will most likely constrain the solution to the (broken) one one we
had before (removing them completely gives the coder the ability to
completely rethink how they're done and make it better).

He who codes it gets an automatic majority vote.

> FWIW, I'm also not thrilled with the change (unless I've misunderstood
> it) that removes the ability to independently choose the OSD theme. I
> have no problem with a setting that defaults to using the OSD theme
> provided by the main theme, but why not let the user choose a
> different OSD theme if they want to?
>

I'm sure that could be changed, too--after all, why make a
consistently-designed UI mandatory if the user wants things to look
different in different places. ;) Again, someone just needs to write
some code. Mark had plenty of other stuff to do when he completely did
the libmythui-osd changes all by himself, and, AIUI, allowing the user
to independently change OSD theme was just one of those things that
could be done later.

Besides, Mark is getting stuck with virtually any ticket that's even
remotely related to the OSD, so he hardly has time to start adding a
bunch of new features/enhancements to the new code. Now, if all of us
were to help him... :)

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mark.kendall at gmail

Jun 15, 2010, 11:04 AM

Post #6 of 23 (2902 views)
Permalink
Re: OSD timeout settings [In reply to]

On 15 June 2010 23:21, David Engel <david [at] istwok> wrote:
> On Tue, Jun 15, 2010 at 01:32:41PM +1000, Jean-Yves Avenard wrote:
>> Following http://svn.mythtv.org/trac/changeset/25102
>>
>> Is the plan to have something equivalent with the new OSD theme, that
>> is the user can easily change the timeout settings and how long one
>> has to read text displayed on the screen.
>>
>> If it will require to fiddle with the theme XML to adjust how long you
>> have to read things , that's a big drawback usability-wise IMO.
>
> I agree completely.  I understand the desire, even need, for the
> themes to control all visual aspects such as fonts so things look
> right.  OSD timeouts don't affect the visual appearance of the themes
> and should be easily configurable without having to edit XML.
>
> FWIW, I'm also not thrilled with the change (unless I've misunderstood
> it) that removes the ability to independently choose the OSD theme.  I
> have no problem with a setting that defaults to using the OSD theme
> provided by the main theme, but why not let the user choose a
> different OSD theme if they want to?

For the record, following r25031 (and as subsequently noted in r25094)
I raised the issue of OSD timeouts on the irc dev channel and asked
whether they should default to hard coded values, be configurable via
the OSD settings or configured within the theme. From memory, everyone
who responded suggested the theme route and Michael's removal of those
(and other) settings was a response to that discussion.

That said I should point out that I'm largely agnostic about the 2
issues already raised (timeouts and theme choice). But I do think
there are broader issues.

With respect to the timeout settings, how many people would actually
notice and/or care if the default/fallback theme settings were 5
seconds in general and, say, 10 seconds for more verbose windows?
Indeed, how many themers would actually bother to change the defaults?
Furthermore, given that the themer has complete control of the
graphical presentation, text size, text font and to a lesser extent
the text actually presented, the timeouts are just another element of
that presentation. Sensible defaults for the timeouts are, I would
suggest, less likely to generate debate than something like font sizes
(which can't actually be changed without breaking the theme anyway).

As far as the OSD theme is concerned, there is, I think, currently no
technical reason why the OSD theme cannot be different from the main
UI theme. That is, however, a consequence of the current code
limitations around inheritance and the image cache - both issues that
I hope will be addressed soon. Following that the OSD will, by and
large, explicitly inherit from the main UI theme and significantly
simplify themeing of the OSD. But why would you want a different look
and feel for the OSD and the main UI? If I'm at cross purposes to the
general view, then it's time for me to move on. That was, after all, a
significant objective of the 'project' I've spent the last 6 months
working on.

But if you look forward and anticipate a far richer UI experience from
MythTV, it is a natural consequence that both issues fall by the
wayside...

libmythui already offers the themer several choices to animate widgets
- changing the colour/alpha, moving, scrolling text, fading in/out
(etc?). Fading out the OSD windows is nothing more than a special case
(i.e. a largely hard coded effect) and, as it stands, all these
effects are themed and operate independently. But (again!) if we
develop a more generic approach to animation within the theme, as
suggested on irc, then the themer has the opportunity for a myriad of
effects. Are we going to legislate for every possible personal
preference with respect to how those animations will work? I very much
doubt it.

and when (not if) we get to the stage that the OSD and UI themes are
fully merged, then clearly the theme choice is moot. If you take the
first leap of faith that a new 'video/media' widget is forthcoming for
libmythui (i.e. a more generic video preview window), you will
appreciate that the UI library (libmythui) is poking at the bounds of
the TV library (libmythtv) and that the TV library is already more
than poking at the bounds of the UI library with the new OSD code. The
boundary is already blurred and it is a natural progression that at
some point the two will somehow integrate - the debate is then around
how and when that happens and, depending on the timescales involved,
which APIs to support for video acceleration and UI presentation.

Anyone who has followed my view on future development will know that
the last comment is loaded but, regardless, I would ask anyone
involved in MythTV development to try and look beyond what is
currently available and imagine something better. If the focus is on
whether 5 seconds is better than 6, I'll probably just cry myself to
sleep and get a more fulfilling job in the morning.

regards

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


manuel at mclure

Jun 15, 2010, 11:33 AM

Post #7 of 23 (2930 views)
Permalink
Re: OSD timeout settings [In reply to]

On Tue, Jun 15, 2010 at 11:04 AM, Mark Kendall <mark.kendall [at] gmail> wrote:
> But why would you want a different look
> and feel for the OSD and the main UI?

I'll throw my two cents in and mention my opinion. I would be somewhat
unhappy if I couldn't have Arclight as my main theme and an OSD
similar to BlackCurve - the transparency is a big feature to me since
it lets me see the show running behind the OSD. I believe that's why
people might want a different OSD theme from their main theme - the
OSD theme overlays/interrupts the video playback, so people might want
an OSD theme that's less intrusive and has less eye-candy than their
main theme.

> If I'm at cross purposes to the
> general view, then it's time for me to move on. That was, after all, a
> significant objective of the 'project' I've spent the last 6 months
> working on.

I think that moving the OSD to MythUI is a good thing. I'm a little
less sanguine about forcing the OSD theme to be the same as the main
Myth theme. If I'd been listening on the list when this was being
discussed I would have raised my opinion then, but unfortunately I was
not. Also, as far as MythUI is concerned I'm definitely in the user
rather than developer category, so I know my opinion doesn't have as
much weight as a developer's.


--
Manuel A. McLure WW1FA <manuel [at] mclure> <http://www.mclure.org>
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat. -- H.P. Lovecraft
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


lsorense at csclub

Jun 15, 2010, 11:49 AM

Post #8 of 23 (2893 views)
Permalink
Re: OSD timeout settings [In reply to]

On Tue, Jun 15, 2010 at 11:33:48AM -0700, Manuel McLure wrote:
> On Tue, Jun 15, 2010 at 11:04 AM, Mark Kendall <mark.kendall [at] gmail> wrote:
> > But why would you want a different look
> > and feel for the OSD and the main UI?
>
> I'll throw my two cents in and mention my opinion. I would be somewhat
> unhappy if I couldn't have Arclight as my main theme and an OSD
> similar to BlackCurve - the transparency is a big feature to me since
> it lets me see the show running behind the OSD. I believe that's why
> people might want a different OSD theme from their main theme - the
> OSD theme overlays/interrupts the video playback, so people might want
> an OSD theme that's less intrusive and has less eye-candy than their
> main theme.

I would agree. The OSD that matches some themes provides hardly any
useful info, while other OSD themes provide great info. So I pick the OSD
I find useful for the OSD, and I pick a theme for the menus that I like.

So I use mythcenter for my menus, and I can't even remember the name of
the one I use for the OSD. It certainly looks nothing like mythcenter
at all.

> I think that moving the OSD to MythUI is a good thing. I'm a little
> less sanguine about forcing the OSD theme to be the same as the main
> Myth theme. If I'd been listening on the list when this was being
> discussed I would have raised my opinion then, but unfortunately I was
> not. Also, as far as MythUI is concerned I'm definitely in the user
> rather than developer category, so I know my opinion doesn't have as
> much weight as a developer's.

Well any developer that ignores users is a lousy developer in general.
This doesn't mean the user is always right (they often are not), but
their opinion should at least be considered.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Jun 15, 2010, 11:52 AM

Post #9 of 23 (2895 views)
Permalink
Re: OSD timeout settings [In reply to]

On Tue, Jun 15, 2010 at 01:13:35PM -0400, Michael T. Dean wrote:
> On 06/15/2010 11:21 AM, David Engel wrote:
> >On Tue, Jun 15, 2010 at 01:32:41PM +1000, Jean-Yves Avenard wrote:
> >>Following http://svn.mythtv.org/trac/changeset/25102
> >>
> >>Is the plan to have something equivalent with the new OSD theme, that
> >>is the user can easily change the timeout settings and how long one
> >>has to read text displayed on the screen.
> >>
> >>If it will require to fiddle with the theme XML to adjust how long you
> >>have to read things , that's a big drawback usability-wise IMO.
> >I agree completely. I understand the desire, even need, for the
> >themes to control all visual aspects such as fonts so things look
> >right. OSD timeouts don't affect the visual appearance of the themes
> >and should be easily configurable without having to edit XML.
> >
>
> There is absolutely no code in MythTV that allows the OSD timeouts
> to change.

And that's the rub. The previous code might have had inconsistencies,
but it's a regression, IMHO, to remove all configurability and hard
code it. Correct me if I'm wrong, but it looks like the current code
doesn't even allow changing the timeouts via the xml.

> This was true before I removed the widgets. If someone
> wants the ability to change them, they need to write some code.

I will probably add a temporary hack to at least allow some basic
control of the OSD timeout.

> >FWIW, I'm also not thrilled with the change (unless I've misunderstood
> >it) that removes the ability to independently choose the OSD theme. I
> >have no problem with a setting that defaults to using the OSD theme
> >provided by the main theme, but why not let the user choose a
> >different OSD theme if they want to?
>
> I'm sure that could be changed, too--after all, why make a
> consistently-designed UI mandatory if the user wants things to look
> different in different places. ;)

Having the OSD theme resemble the main theme is not the most important
thing to me. Things like having fonts that are readable with my poor
vision and fields in the locations I prefer are much, much, much more
important to me. Consequently, I'd like to be free to independently
choose the main and OSD themes that best fit my needs.

> Again, someone just needs to
> write some code. Mark had plenty of other stuff to do when he
> completely did the libmythui-osd changes all by himself, and, AIUI,
> allowing the user to independently change OSD theme was just one of
> those things that could be done later.

But the code for choosing independently was already there. Maybe I'm
missing something. What about the new mythui-osd implementation
requires that the osd theme come from the main theme? If nothing, why
did this ability have to be removed. Adding a few lines of new code
to support "use the main theme as OSD theme too" shouldn't be that
hard.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Jun 15, 2010, 1:09 PM

Post #10 of 23 (2870 views)
Permalink
Re: OSD timeout settings [In reply to]

On Wed, Jun 16, 2010 at 02:04:08AM +0800, Mark Kendall wrote:
> On 15 June 2010 23:21, David Engel <david [at] istwok> wrote:
> > I agree completely. ?I understand the desire, even need, for the
> > themes to control all visual aspects such as fonts so things look
> > right. ?OSD timeouts don't affect the visual appearance of the themes
> > and should be easily configurable without having to edit XML.
> >
> > FWIW, I'm also not thrilled with the change (unless I've misunderstood
> > it) that removes the ability to independently choose the OSD theme. ?I
> > have no problem with a setting that defaults to using the OSD theme
> > provided by the main theme, but why not let the user choose a
> > different OSD theme if they want to?
>
> For the record, following r25031 (and as subsequently noted in r25094)
> I raised the issue of OSD timeouts on the irc dev channel and asked
> whether they should default to hard coded values, be configurable via
> the OSD settings or configured within the theme. From memory, everyone
> who responded suggested the theme route and Michael's removal of those
> (and other) settings was a response to that discussion.

Admittedly, I should have raised the issue then, but didn't have time
to get into a real-time debate and then forgot about. That's why I'd
still like to see decisions like this made on the -dev list.

> That said I should point out that I'm largely agnostic about the 2
> issues already raised (timeouts and theme choice). But I do think
> there are broader issues.
>
> With respect to the timeout settings, how many people would actually
> notice and/or care if the default/fallback theme settings were 5
> seconds in general and, say, 10 seconds for more verbose windows?

I think quite a few would notice. Heck, even the crappy STBs Time
Warner rents me have a setting to control the OSD timeout.

> Indeed, how many themers would actually bother to change the defaults?

I can't imagine why any themer would want to control the main timeout.
The fade time, maybe, but not the main timeout.

> simplify themeing of the OSD. But why would you want a different look
> and feel for the OSD and the main UI? If I'm at cross purposes to the

For the same reason we have different main UI themes -- differnet
strokes for differnet folks. Just because I like a particular main UI
theme, it doesn't mean I willd automatically like the corresponding
OSD theme.

> general view, then it's time for me to move on. That was, after all, a
> significant objective of the 'project' I've spent the last 6 months
> working on.
>
> But if you look forward and anticipate a far richer UI experience from
> MythTV, it is a natural consequence that both issues fall by the
> wayside...
>
> libmythui already offers the themer several choices to animate widgets
> - changing the colour/alpha, moving, scrolling text, fading in/out
> (etc?). Fading out the OSD windows is nothing more than a special case
> (i.e. a largely hard coded effect) and, as it stands, all these
> effects are themed and operate independently. But (again!) if we
> develop a more generic approach to animation within the theme, as
> suggested on irc, then the themer has the opportunity for a myriad of
> effects. Are we going to legislate for every possible personal
> preference with respect to how those animations will work? I very much
> doubt it.
>
> and when (not if) we get to the stage that the OSD and UI themes are
> fully merged, then clearly the theme choice is moot. If you take the
> first leap of faith that a new 'video/media' widget is forthcoming for
> libmythui (i.e. a more generic video preview window), you will
> appreciate that the UI library (libmythui) is poking at the bounds of
> the TV library (libmythtv) and that the TV library is already more
> than poking at the bounds of the UI library with the new OSD code. The
> boundary is already blurred and it is a natural progression that at
> some point the two will somehow integrate - the debate is then around
> how and when that happens and, depending on the timescales involved,
> which APIs to support for video acceleration and UI presentation.
>
> Anyone who has followed my view on future development will know that
> the last comment is loaded but, regardless, I would ask anyone
> involved in MythTV development to try and look beyond what is
> currently available and imagine something better. If the focus is on
> whether 5 seconds is better than 6, I'll probably just cry myself to
> sleep and get a more fulfilling job in the morning.

I think you're taking this way too personally, Mark. I'm certainly
not, nor do I think anyone else is, denigrating the work you've done
or the ability to use a single, unified theme if you want to.
However, don't be surprised when others don't share the same vision.

This is the first I've heard about the mythui/theme duo taking over
everything, and I must say it gives me pause. I think everyone agrees
Myth has had too many user configurable options, but I'm very afraid
of this going too far in the other direction where users will have to
desing their own themes to make any UI related changes.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Jun 15, 2010, 5:33 PM

Post #11 of 23 (2862 views)
Permalink
Re: OSD timeout settings [In reply to]

On Tue, Jun 15, 2010 at 01:52:47PM -0500, David Engel wrote:
> On Tue, Jun 15, 2010 at 01:13:35PM -0400, Michael T. Dean wrote:
> > This was true before I removed the widgets. If someone
> > wants the ability to change them, they need to write some code.
>
> I will probably add a temporary hack to at least allow some basic
> control of the OSD timeout.

As promised, here is a hack to restore a general OSD timeout. Suggest
a way to re implement the others and I'll take a look at them too.

One thing of note is that OSD::SetExpiry() already appears to use 0 and
<0 as special values so I used 1 to mean "use the configured default"
since a timeout of 1ms doesn't make much sense. Feel free to make a
better suggestion of clarify that 0 isn't special and could be used
instead.

Another thing of note is OSD::SetExpiry() accepts time in ms while the
DB setting uses 1s granularity. It might be worth changing the DB and
settings widget to use ms with say a 100ms granularity.

David
--
David Engel
david [at] istwok
Attachments: osdtimeout1.patch (2.21 KB)


jyavenard at gmail

Jun 15, 2010, 5:47 PM

Post #12 of 23 (2863 views)
Permalink
Re: OSD timeout settings [In reply to]

Hi

On 16 June 2010 10:33, David Engel <david [at] istwok> wrote:
> As promised, here is a hack to restore a general OSD timeout.  Suggest
> a way to re implement the others and I'll take a look at them too.

:)

While you're at it, if you could have the 2 previous settings instead
, like one when you just changed channels (3s default), and one wen
you press info (10s default)

Back on my vuvuzela filter...
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Jun 15, 2010, 7:20 PM

Post #13 of 23 (2858 views)
Permalink
Re: OSD timeout settings [In reply to]

On 06/15/2010 08:47 PM, Jean-Yves Avenard wrote:
> On 16 June 2010 10:33, David Engel wrote:
>
>> As promised, here is a hack to restore a general OSD timeout. Suggest
>> a way to re implement the others and I'll take a look at them too.
>>
> :)
>
> While you're at it, if you could have the 2 previous settings instead
> , like one when you just changed channels (3s default), and one wen
> you press info (10s default)
>
> Back on my vuvuzela filter...
>

That's exactly what I was talking about. There were 2 settings***,
"Program info OSD time-out", default 3 seconds, and "General OSD
time-out (sec)", default 2 seconds. I /still/ think the only reason
that people think these settings are necessary is because we had such
stupid default values for them. If, instead, we did what you're
suggesting--set appropriate values for each OSD displayed--we wouldn't
need a bunch of settings.

Also, I would /very/ much prefer if someone is going to put these in
that they come up with a better design for them than what we had
previously. I spend enough of my time redoing the "I'll just throw in a
quick setting" that we've accumulated over the years, and don't really
want to have to do it for these, too. Why just do the same broken
design we had before? (A broken design with a couple of settings
loosely applied to some, but not all OSD screens--OK, at least with
David's approach, the value is applied to all OSD screens, so there's no
confusion.)

Note that we have OSD screens that need long timeouts (program_info, the
program information window; and browse_info, the OSD window displayed
during channel browsing). We have others that might not need as much
time (osd_status, the "overall status" window, which usually displays
playback progress). And we have another that may need to be displayed
for different amounts of time (osd_message, the OSD text
message/notification popup).

Looking at it more from the "What do we display?" standpoint, some
should be displayed for a short time (such as the Jump Forward/Back and
Skip Ahead/Back and Caption On/Off messages), others for a medium
duration (Volume and Adjust Time Stretch and Adjust Audio Sync),
probably others for a long time, and others for an "appropriate"
time--i.e. the commercial notification window for those who specify
"Notify, but do not skip" for the "Automatically skip commercials"
setting should be displayed for "Commercial skip notify amount" + some
value (maybe 1 or 2 seconds longer). I'm sure there are a lot more in
there, too.

As long as we have the opportunity to do it over, why not do it better
this time?

Just my $0.02.

Mike

***I'm ignoring the "UDP notify OSD time-out", default 5 seconds, which
was used for UDP messages with MythNotify since that's one that few
people used and didn't affect normal TV viewing. This would also need
to be handled appropriately--likely with a "long" duration.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Jun 16, 2010, 8:07 AM

Post #14 of 23 (2821 views)
Permalink
Re: OSD timeout settings [In reply to]

On Tue, Jun 15, 2010 at 10:20:46PM -0400, Michael T. Dean wrote:
> On 06/15/2010 08:47 PM, Jean-Yves Avenard wrote:
> >On 16 June 2010 10:33, David Engel wrote:
> >>As promised, here is a hack to restore a general OSD timeout. Suggest
> >>a way to re implement the others and I'll take a look at them too.
> >:)
> >
> >While you're at it, if you could have the 2 previous settings instead
> >, like one when you just changed channels (3s default), and one wen
> >you press info (10s default)
> >
> >Back on my vuvuzela filter...
>
> That's exactly what I was talking about. There were 2 settings***,
> "Program info OSD time-out", default 3 seconds, and "General OSD
> time-out (sec)", default 2 seconds. I /still/ think the only reason
> that people think these settings are necessary is because we had
> such stupid default values for them. If, instead, we did what
> you're suggesting--set appropriate values for each OSD displayed--we
> wouldn't need a bunch of settings.
>
> Also, I would /very/ much prefer if someone is going to put these in
> that they come up with a better design for them than what we had
> previously. I spend enough of my time redoing the "I'll just throw
> in a quick setting" that we've accumulated over the years, and don't
> really want to have to do it for these, too. Why just do the same
> broken design we had before? (A broken design with a couple of
> settings loosely applied to some, but not all OSD screens--OK, at
> least with David's approach, the value is applied to all OSD
> screens, so there's no confusion.)

That's why I only did one setting and didn't commit anything. I'm
awaiting suggestions on how to proceed next.

The most important thing for me is being able to set a short timeout
for the osd_status display. I have my skip forward amount tuned via
playgroups for the sports I watch and I want the osd_status to get out
of the way quickly.

> Note that we have OSD screens that need long timeouts (program_info,
> the program information window; and browse_info, the OSD window
> displayed during channel browsing). We have others that might not
> need as much time (osd_status, the "overall status" window, which
> usually displays playback progress). And we have another that may
> need to be displayed for different amounts of time (osd_message, the
> OSD text message/notification popup).
>
> Looking at it more from the "What do we display?" standpoint, some
> should be displayed for a short time (such as the Jump Forward/Back
> and Skip Ahead/Back and Caption On/Off messages), others for a
> medium duration (Volume and Adjust Time Stretch and Adjust Audio
> Sync), probably others for a long time, and others for an
> "appropriate" time--i.e. the commercial notification window for
> those who specify "Notify, but do not skip" for the "Automatically
> skip commercials" setting should be displayed for "Commercial skip
> notify amount" + some value (maybe 1 or 2 seconds longer). I'm sure
> there are a lot more in there, too.
>
> As long as we have the opportunity to do it over, why not do it
> better this time?
>
> Just my $0.02.

It sounds like you're advocating for "short", "medium" and "long"
settings for those OSD displays that could/should be configurable. Is
that right? If not please clarify.

BTW, no on the "notify amount" + some value bit. I added the notify
amount feature to give a heads up that a break might be immanent. If
I believe it's correct, I can then skip the fade out or "we'll be
right back" bits. If I don't think it's correct or I want to watch
all the way up to the break, I don't want the OSD display being up for
some 15 seconds or so.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Jun 16, 2010, 1:37 PM

Post #15 of 23 (2809 views)
Permalink
Re: OSD timeout settings [In reply to]

On 06/16/2010 11:07 AM, David Engel wrote:
> On Tue, Jun 15, 2010 at 10:20:46PM -0400, Michael T. Dean wrote:
>
>> As long as we have the opportunity to do it over, why not do it
>> better this time?
>>
> It sounds like you're advocating for "short", "medium" and "long"
> settings for those OSD displays that could/should be configurable. Is
> that right? If not please clarify.
>

My real preference is appropriate defaults so that no settings are
necessary. With settings, users won't know which displays are affected
by which settings (and, for that matter, it's possible that the same
display in different contexts will be affected by different
settings/timeouts), so it's just confusing. Or, users will have
different opinions about which displays should use which timeouts. (Not
to mention that I have sent way too many posts to the lists telling
users what settings their looking for and where to find them--i.e. setup
is /way/ too confusing because long-time users can't even find the
settings they want.)

Or, perhaps, something completely different... For example, maybe any
user-initiated OSD is displayed for a long time, but
automatically-displayed OSDs are displayed for a short time. On short
OSDs, users can extend the display (with the INFO button or whatever),
on long OSDs, users can dismiss (with ESCAPE, as always).

IANAUIDE (I Am Not A User Interface Design Expert), so really, I'm
really not the right person to come up with a better approach. Getting
a UI design expert to help would be ideal, but it seems most of them
gave up on MythTV years ago. ;)

That said, if we go back to the old approach, I can live with it--as
long as it's applied consistently and universally.

Basically, I'd like to take the opportunity to rethink old behaviors and
improve. Unfortunately, it seems that inertia may make major
improvements impossible. I fully admit that I don't have a plan. I
don't really care that much about this particular issue (other than
insisting that it's at least a complete implementation unlike what we
had before). So, I'll leave it up to others.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


robert.mcnamara at gmail

Jun 16, 2010, 1:42 PM

Post #16 of 23 (2806 views)
Permalink
Re: OSD timeout settings [In reply to]

On Wed, Jun 16, 2010 at 1:37 PM, Michael T. Dean
<mtdean [at] thirdcontact> wrote:
> Basically, I'd like to take the opportunity to rethink old behaviors and
> improve.  Unfortunately, it seems that inertia may make major improvements
> impossible.  I fully admit that I don't have a plan.  I don't really care
> that much about this particular issue (other than insisting that it's at
> least a complete implementation unlike what we had before).  So, I'll leave
> it up to others.

Exactly right, and exactly my take on this issue. The only way to
create a truly dynamic UI engine is to tear down the presumptions that
it makes. Having bunches of different timeouts presumes that the
fixed pieces of information always occur within a fixed number of
named, rigid windows and popups. Contrast this with something like
XBMC which can, with scripting and theming, be turned into another
application altogether, Boxee. Both behave profoundly differently,
because the themer is given ultimate control to the finest detail. We
are a long, long way from being able to do this, and with this kind of
insistence on maintaining legacy behavior, we never will be.

This thread, and the fallout that has associated from it (which none
of you yet realize) has really destroyed my faith that we will ever
get where people like Mark, Stuart Morgan, Me, and Mike dream/dreamed
that we would get. I think we are really in trouble.

Robert
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


lsorense at csclub

Jun 16, 2010, 1:59 PM

Post #17 of 23 (2808 views)
Permalink
Re: OSD timeout settings [In reply to]

On Wed, Jun 16, 2010 at 04:37:03PM -0400, Michael T. Dean wrote:
> My real preference is appropriate defaults so that no settings are
> necessary. With settings, users won't know which displays are affected
> by which settings (and, for that matter, it's possible that the same
> display in different contexts will be affected by different
> settings/timeouts), so it's just confusing. Or, users will have
> different opinions about which displays should use which timeouts. (Not
> to mention that I have sent way too many posts to the lists telling
> users what settings their looking for and where to find them--i.e. setup
> is /way/ too confusing because long-time users can't even find the
> settings they want.)
>
> Or, perhaps, something completely different... For example, maybe any
> user-initiated OSD is displayed for a long time, but
> automatically-displayed OSDs are displayed for a short time. On short
> OSDs, users can extend the display (with the INFO button or whatever),
> on long OSDs, users can dismiss (with ESCAPE, as always).

I would like info to dismiss it too. So info toggles it on and off,
with the timeout being the automatic off. Well at least info dismiss
anything info put up. The OSD for channel changes and such I am not
sure why I would ever want to extend for any reason.

> IANAUIDE (I Am Not A User Interface Design Expert), so really, I'm
> really not the right person to come up with a better approach. Getting
> a UI design expert to help would be ideal, but it seems most of them
> gave up on MythTV years ago. ;)
>
> That said, if we go back to the old approach, I can live with it--as
> long as it's applied consistently and universally.
>
> Basically, I'd like to take the opportunity to rethink old behaviors and
> improve. Unfortunately, it seems that inertia may make major
> improvements impossible. I fully admit that I don't have a plan. I
> don't really care that much about this particular issue (other than
> insisting that it's at least a complete implementation unlike what we
> had before). So, I'll leave it up to others.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jyavenard at gmail

Jun 16, 2010, 2:00 PM

Post #18 of 23 (2806 views)
Permalink
Re: OSD timeout settings [In reply to]

On 17 June 2010 06:42, Robert McNamara <robert.mcnamara [at] gmail> wrote:
> On Wed, Jun 16, 2010 at 1:37 PM, Michael T. Dean
> <mtdean [at] thirdcontact> wrote:
>> Basically, I'd like to take the opportunity to rethink old behaviors and
>> improve.  Unfortunately, it seems that inertia may make major improvements
>> impossible.  I fully admit that I don't have a plan.  I don't really care
>> that much about this particular issue (other than insisting that it's at
>> least a complete implementation unlike what we had before).  So, I'll leave
>> it up to others.
>
> Exactly right, and exactly my take on this issue.  The only way to
> create a truly dynamic UI engine is to tear down the presumptions that
> it makes.  Having bunches of different timeouts presumes that the
> fixed pieces of information always occur within a fixed number of
> named, rigid windows and popups.  Contrast this with something like
> XBMC which can, with scripting and theming, be turned into another
> application altogether, Boxee.  Both behave profoundly differently,
> because the themer is given ultimate control to the finest detail.  We
> are a long, long way from being able to do this, and with this kind of
> insistence on maintaining legacy behavior, we never will be.

giving the user the time to read a message in a way he/she feels
comfortable with isn't "maintaining legacy behavior"... That a
behaviour, implemented almost universally (all my STB here allows such
configuration, including my sony tv) doesn't mean it has to be removed
on the basis that it is old.

How long it takes you to read something, that is displayed only for a
given time, isn't going to be the same for someone else and even more
different depending on the source of the content, the language being
used, how good your eyesight is etc..
It has to be configurable in an easy manner by anyone. The earlier
suggestion of having delays like long, medium, short. With the themes
using those will probably satisfy everyone

Mike is probably right, that with the proper default it wouldn't have
been such an issue to start with, but as it is today, it is an
issue...


>
> This thread, and the fallout that has associated from it (which none
> of you yet realize) has really destroyed my faith that we will ever
> get where people like Mark, Stuart Morgan, Me, and Mike dream/dreamed
> that we would get.  I think we are really in trouble.

you're such a drama queen ...
here is a tissue
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Jun 16, 2010, 2:05 PM

Post #19 of 23 (2811 views)
Permalink
Re: OSD timeout settings [In reply to]

On 06/16/2010 04:59 PM, Lennart Sorensen wrote:
> On Wed, Jun 16, 2010 at 04:37:03PM -0400, Michael T. Dean wrote:
>
>> Or, perhaps, something completely different... For example, maybe any
>> user-initiated OSD is displayed for a long time, but
>> automatically-displayed OSDs are displayed for a short time. On short
>> OSDs, users can extend the display (with the INFO button or whatever),
>> on long OSDs, users can dismiss (with ESCAPE, as always).
>>
> I would like info to dismiss it too. So info toggles it on and off,
> with the timeout being the automatic off. Well at least info dismiss
> anything info put up.

Yeah, that works now, and has in the past (but, as you said, only for
those displays that result from INFO itself).

> The OSD for channel changes and such I am not
> sure why I would ever want to extend for any reason.
>

Agreed.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jyavenard at gmail

Jun 16, 2010, 2:06 PM

Post #20 of 23 (2805 views)
Permalink
Re: OSD timeout settings [In reply to]

Hi

On 17 June 2010 06:59, Lennart Sorensen <lsorense [at] csclub> wrote:
> I would like info to dismiss it too.  So info toggles it on and off,
> with the timeout being the automatic off.  Well at least info dismiss
> anything info put up.  The OSD for channel changes and such I am not
> sure why I would ever want to extend for any reason.

I give you an example on when/where it can be an issue...

It happened just today..

Wife is watching LiveTV, she's about to change channels, when she
realises that something of interest is being displayed. She want to
write it down.
By the time she realised, she presses exit (she press info , and press
exit to make it disappear). Unfortunately, this coincides with the
timeout, she ends up on the main menu instead. Used to display for
10s, now it's 5s she isn't used to that


Sure, I showed her how she can go into recordings, change the filters
to see the live TV recordings... Long and annoying. And she was even
more annoyed when she realised that when she wanted to watch a
recording, all she could see were live tv stuff, cause you had to
change the filters once again...

Result -> Low WAF..
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


lsorense at csclub

Jun 16, 2010, 2:30 PM

Post #21 of 23 (2800 views)
Permalink
Re: OSD timeout settings [In reply to]

On Thu, Jun 17, 2010 at 07:06:49AM +1000, Jean-Yves Avenard wrote:
> I give you an example on when/where it can be an issue...
>
> It happened just today..
>
> Wife is watching LiveTV, she's about to change channels, when she
> realises that something of interest is being displayed. She want to
> write it down.
> By the time she realised, she presses exit (she press info , and press
> exit to make it disappear). Unfortunately, this coincides with the
> timeout, she ends up on the main menu instead. Used to display for
> 10s, now it's 5s she isn't used to that

No matter what the timeout, that could happen.

So either you need a different dedicated key to exit viewing rather
than cancel menus, or you use the same button (info in this case) to both
display and undisplay the OSD (which is apparently already the case).

Certainly having a seperate 'exit to menu' other than escape might
be desirable, or having confirmation before doing so. I haven't looked
if that is currently possible or not.

> Sure, I showed her how she can go into recordings, change the filters
> to see the live TV recordings... Long and annoying. And she was even
> more annoyed when she realised that when she wanted to watch a
> recording, all she could see were live tv stuff, cause you had to
> change the filters once again...
>
> Result -> Low WAF..

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


simon at koala

Jun 16, 2010, 4:16 PM

Post #22 of 23 (2800 views)
Permalink
Re: OSD timeout settings [In reply to]

Mark Kendall wrote:
> With respect to the timeout settings, how many people would actually
> notice and/or care if the default/fallback theme settings were 5
> seconds in general and, say, 10 seconds for more verbose windows?
> Indeed, how many themers would actually bother to change the defaults?
> Furthermore, given that the themer has complete control of the
> graphical presentation, text size, text font and to a lesser extent
> the text actually presented, the timeouts are just another element of
> that presentation. Sensible defaults for the timeouts are, I would
> suggest, less likely to generate debate than something like font sizes
> (which can't actually be changed without breaking the theme anyway).

i had changed the defaults and i did care
at this stage i've all but given up

i'm afraid themes have become a "it's my way or the highway"
and as for not being able to change fonts...
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


james.dutton at gmail

Jun 16, 2010, 11:55 PM

Post #23 of 23 (2781 views)
Permalink
Re: OSD timeout settings [In reply to]

On 17 June 2010 00:16, Simon Kenyon <simon [at] koala> wrote:
> Mark Kendall wrote:
>> With respect to the timeout settings, how many people would actually
>> notice and/or care if the default/fallback theme settings were 5
>> seconds in general and, say, 10 seconds for more verbose windows?
>> Indeed, how many themers would actually bother to change the defaults?
>> Furthermore, given that the themer has complete control of the
>> graphical presentation, text size, text font and to a lesser extent
>> the text actually presented, the timeouts are just another element of
>> that presentation. Sensible defaults for the timeouts are, I would
>> suggest, less likely to generate debate than something like font sizes
>> (which can't actually be changed without breaking the theme anyway).
>
> i had changed the defaults and i did care
> at this stage i've all but given up
>
> i'm afraid themes have become a "it's my way or the highway"
> and as for not being able to change fonts...

People can be very creative with themed GUI interfaces.
We should not restrict their creativity.
So, I think we should have user visible timeouts in units of
milliseconds. Use the same units for all timeouts.
Leave it up to the person doing the theme design to convert those
timeouts to "Slow, Medium, Fast" settings that the user can change.
The presentation of the OSD as well as the setup screens should both
be controlled by themes.
Also, what keys are used for what operation should also be controlled
by the theme.
Sensible defaults should be chosen for all values, so if a theme does
not set a particular value, the default will be acceptable until the
theme implements support for it.
For example, it should be possible, buy using a theme to make mythtv
user experience identical to a commercial set top box if a developer
wished to implement it. In this case, the navigation between screens
might be in a totally different order than the current myth menu
layout.

So, in summary, I think the mythfrontend theme support should be as
flexible as possible and not limited by one developer guessing at what
other developers might want.

Kind Regards

James
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.