Mailing List Archive: MythTV: Dev

Next release // website stuff?

Index | Next | Previous | View Threaded

ijr at po

Dec 3, 2003, 7:51 PM

Post #1 of 23 (2635 views)
Permalink

Next release // website stuff?

Are there any big patches pending that I either haven't seen or commented on
yet? I'm thinking that it's past time for the 0.13 release.. So, maybe next
week sometime, to give people more time to test stuff.

Also, would anyone be interested in improving the themes section on the
website? It'd be nice to be able to be able to show more than a single
screenshot, handle different versions, etc, which the current stuff just
doesn't do at all..

Isaac

jcaputo1 at comcast

Dec 3, 2003, 9:08 PM

Post #2 of 23 (2599 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Wednesday 03 December 2003 21:51, Isaac Richards wrote:
> Are there any big patches pending that I either haven't seen or commented on
> yet? I'm thinking that it's past time for the 0.13 release.. So, maybe
next
> week sometime, to give people more time to test stuff.
>
> Also, would anyone be interested in improving the themes section on the
> website? It'd be nice to be able to be able to show more than a single
> screenshot, handle different versions, etc, which the current stuff just
> doesn't do at all..
>
> Isaac

This is just a small patch to add a couple of bindings to the MythSpinBox
widget. I've sent it before, but I think it got lost in the shuffle; at
least I didn't notice it in the -commits list.

-JAC

Attachments:

spinbox.diff (0.76 KB)

bjm at lvcm

Dec 4, 2003, 12:30 AM

Post #3 of 23 (2642 views)
Permalink

Re: Next release // website stuff? [In reply to]

Joseph A. Caputo wrote:
...
> This is just a small patch to add a couple of bindings to the MythSpinBox
> widget. I've sent it before, but I think it got lost in the shuffle; at
> least I didn't notice it in the -commits list.

I remember this and it would be a good thing in several places.
You had mentioned the Manual Recording page and this would be
really nice for setting a long post-roll time. However, it may
not be a good thing in a couple of places in Recording Profiles.

If a user has a remote control and she doesn't have Key_Next
and Key_Prior mapped, changing the bitrate by 1000 or 2000
would be painful. More importantly, allowing the users to
change the recording width and height by one is a Bad Thing.
These need to be multiples of at least 8 for recordings to
work properly. This was one of the nice things about the GUI
settings rather than editing a file, lots of user complaints
went away once the GUI only allowed valid sizes.

Any ideas on how to handle these cases?

-- bjm

doug at ties

Dec 4, 2003, 5:43 AM

Post #4 of 23 (2628 views)
Permalink

Re: Next release // website stuff? [In reply to]

On 12/03/03 21:51:59, Isaac Richards wrote:
> Are there any big patches pending that I either haven't seen or
> commented on yet? I'm thinking that it's past time for the 0.13
> release.. So, maybe next week sometime, to give people more time to
> test stuff.

From an HDTV perspective:

I am working on a third draft of the positionmap-by-framenumber patch
(the one you rejected, one that didn't work at all, and now one that
shows promise). Without something like this, rewind/fastforward is
basically broken for DVB and HDTV streams, though I'd understand if you
want to hold off -- I imagine anybody really interested in HDTV at this
point is following CVS anyway.

Steve Brown's patch from yesterday, once he makes that one change,
enables reception for some stations that don't work now.

-Doug

jcaputo1 at comcast

Dec 4, 2003, 7:40 AM

Post #5 of 23 (2625 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thursday 04 December 2003 02:30, Bruce Markey wrote:
> Joseph A. Caputo wrote:
> ...
>
> > This is just a small patch to add a couple of bindings to the
> > MythSpinBox widget. I've sent it before, but I think it got lost
> > in the shuffle; at least I didn't notice it in the -commits list.
>
> I remember this and it would be a good thing in several places.
> You had mentioned the Manual Recording page and this would be
> really nice for setting a long post-roll time. However, it may
> not be a good thing in a couple of places in Recording Profiles.
>
> If a user has a remote control and she doesn't have Key_Next
> and Key_Prior mapped, changing the bitrate by 1000 or 2000
> would be painful. More importantly, allowing the users to
> change the recording width and height by one is a Bad Thing.
> These need to be multiples of at least 8 for recordings to
> work properly. This was one of the nice things about the GUI
> settings rather than editing a file, lots of user complaints
> went away once the GUI only allowed valid sizes.
>
> Any ideas on how to handle these cases?
>
> -- bjm

How 'bout I add a boolean flag to the MythSpinBox class that controls
whether or not this behavior is enabled. Default would be the current
behavior, like so:

Default (flag false)
Left/Right = dec/inc by stepsize
Prior/Next = no-op

modified behavior (flag true):
Left/Right = dec/inc by 1
Prior/Next = dec/inc by stepsize

if no stepsize set, default to 10

What say ye?

-JAC

dlengel at attbi

Dec 4, 2003, 11:09 AM

Post #6 of 23 (2597 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Wed, Dec 03, 2003 at 09:51:59PM -0500, Isaac Richards wrote:
> Are there any big patches pending that I either haven't seen or commented on
> yet? I'm thinking that it's past time for the 0.13 release.. So, maybe next
> week sometime, to give people more time to test stuff.

Isaac, I believe there are a couple of problems with the new
keybinding changes.

First, in MythMainWindow::TranslateKeyPress(), you add the global
actions to the returned action list before the context specific
actions. Won't this make it impossible to override a global mapping
in a specific context?

Second, after you translate a key to a list of actions, you loop
through all of the actions. Shouldn't you stop looping if an action
is handled? Not doing so can result in multiple actions being handled
for a single key.

David
--
David Engel
dlengel [at] attbi

dlengel at attbi

Dec 4, 2003, 11:21 AM

Post #7 of 23 (2598 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thu, Dec 04, 2003 at 12:09:29PM -0600, David Engel wrote:
> Isaac, I believe there are a couple of problems with the new
> keybinding changes.

Also, do you think it would be wise to have a "TV Guide" context for
the GuideGrid instead of overloading those mappings in the "TV
Frontend" context? I can see the possibility of mapping keys
differently in those contexts?

David
--
David Engel
dlengel [at] attbi

ijr at po

Dec 4, 2003, 11:42 AM

Post #8 of 23 (2627 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thursday 04 December 2003 01:09 pm, David Engel wrote:
> Isaac, I believe there are a couple of problems with the new
> keybinding changes.
>
> First, in MythMainWindow::TranslateKeyPress(), you add the global
> actions to the returned action list before the context specific
> actions. Won't this make it impossible to override a global mapping
> in a specific context?

I can't think of a case where you'd want to completely override a global
mapping that's not handled already.

> Second, after you translate a key to a list of actions, you loop
> through all of the actions. Shouldn't you stop looping if an action
> is handled? Not doing so can result in multiple actions being handled
> for a single key.

Need to loop -- for instance, video playing uses the arrows as arrows and as
channel change / seek keys. Probably should stop (and it does some places),
but I don't think it'll be much of an issue aside from some corner cases,
really, which I can fix as they come up.

Isaac

ijr at po

Dec 4, 2003, 1:41 PM

Post #9 of 23 (2585 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thursday 04 December 2003 01:21 pm, David Engel wrote:
> On Thu, Dec 04, 2003 at 12:09:29PM -0600, David Engel wrote:
> > Isaac, I believe there are a couple of problems with the new
> > keybinding changes.
>
> Also, do you think it would be wise to have a "TV Guide" context for
> the GuideGrid instead of overloading those mappings in the "TV
> Frontend" context? I can see the possibility of mapping keys
> differently in those contexts?

It doesn't really matter all that much to me -- I was just trying to keep the
number of keybinding contexts low.

Isaac

ijr at po

Dec 4, 2003, 2:55 PM

Post #10 of 23 (2583 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thursday 04 December 2003 07:43 am, Doug Larrick wrote:
> From an HDTV perspective:
>
> I am working on a third draft of the positionmap-by-framenumber patch
> (the one you rejected, one that didn't work at all, and now one that
> shows promise). Without something like this, rewind/fastforward is
> basically broken for DVB and HDTV streams, though I'd understand if you
> want to hold off -- I imagine anybody really interested in HDTV at this
> point is following CVS anyway.

Yeah, I'd like to merge that in after the 0.13 release. Just In Case. =)

> Steve Brown's patch from yesterday, once he makes that one change,
> enables reception for some stations that don't work now.

Ok. Sounds good.

Isaac

ijr at po

Dec 4, 2003, 2:56 PM

Post #11 of 23 (2587 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thursday 04 December 2003 09:40 am, Joseph A. Caputo wrote:
> How 'bout I add a boolean flag to the MythSpinBox class that controls
> whether or not this behavior is enabled. Default would be the current
> behavior, like so:
>
> Default (flag false)
> Left/Right = dec/inc by stepsize
> Prior/Next = no-op
>
> modified behavior (flag true):
> Left/Right = dec/inc by 1
> Prior/Next = dec/inc by stepsize
>
> if no stepsize set, default to 10
>
> What say ye?

Sounds reasonable to me.

Isaac

bjm at lvcm

Dec 4, 2003, 3:38 PM

Post #12 of 23 (2634 views)
Permalink

Re: Next release // website stuff? [In reply to]

Isaac Richards wrote:
> On Thursday 04 December 2003 09:40 am, Joseph A. Caputo wrote:
>
>>How 'bout I add a boolean flag to the MythSpinBox class that controls
>>whether or not this behavior is enabled. Default would be the current
>>behavior, like so:
>>
>>Default (flag false)
>> Left/Right = dec/inc by stepsize
>> Prior/Next = no-op
>>
>>modified behavior (flag true):
>> Left/Right = dec/inc by 1
>> Prior/Next = dec/inc by stepsize
>>
>>if no stepsize set, default to 10
>>
>>What say ye?
>
>
> Sounds reasonable to me.

Second that =). I'd like to test this on every spinbox to
make sure some other odd case isn't overlooked just before
a release.

One suggestion. On the Default behavior, maybe Prior/Next
should be stepsize also. That way, if the user uses them out
of habit, they still work even though they do the same thing
as the Left/Right keys.

-- bjm

dlengel at attbi

Dec 4, 2003, 4:30 PM

Post #13 of 23 (2581 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thu, Dec 04, 2003 at 03:41:22PM -0500, Isaac Richards wrote:
> On Thursday 04 December 2003 01:21 pm, David Engel wrote:
> > On Thu, Dec 04, 2003 at 12:09:29PM -0600, David Engel wrote:
> > > Isaac, I believe there are a couple of problems with the new
> > > keybinding changes.
> >
> > Also, do you think it would be wise to have a "TV Guide" context for
> > the GuideGrid instead of overloading those mappings in the "TV
> > Frontend" context? I can see the possibility of mapping keys
> > differently in those contexts?
>
> It doesn't really matter all that much to me -- I was just trying to
> keep the number of keybinding contexts low.

It was just a thought. I didn't have any binding conflicts, but
thought others might.

Any comment on the two problems I described? I can give specific
examples if you like.

David
--
David Engel
dlengel [at] attbi

dlengel at attbi

Dec 4, 2003, 8:28 PM

Post #14 of 23 (2598 views)
Permalink

Re: Next release // website stuff? [In reply to]

I think you're too used to the default key bindings. I'll give as
exaples the two cases I've run into so far.

On Thu, Dec 04, 2003 at 01:42:41PM -0500, Isaac Richards wrote:
> > First, in MythMainWindow::TranslateKeyPress(), you add the global
> > actions to the returned action list before the context specific
> > actions. Won't this make it impossible to override a global mapping
> > in a specific context?
>
> I can't think of a case where you'd want to completely override a global
> mapping that's not handled already.

I have my remote's Play key mapped to generate 'Y'. I want to use
this key as the INFO action in most places, so I added 'Y' to the
global INFO action. However, I want the Play key to start playback in
PlaybackBox, so I added 'Y' to the TV Frontend PLAYBACK action. Now,
because the global actions are returned first, pressing the Play key
causes the INFO action to be used first and pops up the
showActionsSelected menu instead of starting playback.

> > Second, after you translate a key to a list of actions, you loop
> > through all of the actions. Shouldn't you stop looping if an action
> > is handled? Not doing so can result in multiple actions being handled
> > for a single key.
>
> Need to loop -- for instance, video playing uses the arrows as arrows and as
> channel change / seek keys. Probably should stop (and it does some places),
> but I don't think it'll be much of an issue aside from some corner cases,
> really, which I can fix as they come up.

I have my remote's channel up/down keys mapped to generate PgUp/PgDown
since those are the keys I want for the PAGE UP/DOWN actions in most
contexts. However, I want them to change the channel when
appropriate, so I added PgUp/PgDown to the TV Playing CHANNELUP/DOWN
actions. Unfortunately, when I go into browse mode, those keys don't
work anymore because the code is only for checking for UP/DOWN actions
at that point. The fix was easy enough, just change the code to also
check for CHANNELUP/DOWN actions. Works fine for me, but anyone who
uses the default key mappings will jump two channels every time they
press Up/Down, one for the UP/DOWN action and again for the
CHANNELUP/DOWN action.

David
--
David Engel
dlengel [at] attbi

ijr at po

Dec 4, 2003, 11:33 PM

Post #15 of 23 (2605 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thursday 04 December 2003 10:28 pm, David Engel wrote:
> I think you're too used to the default key bindings. I'll give as
> exaples the two cases I've run into so far.
<snip>

How's what I just committed to CVS look? I didn't test it much beyond
compilation, but it should address both of your issues, I think..

Isaac

dlengel at attbi

Dec 5, 2003, 12:24 AM

Post #16 of 23 (2600 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Fri, Dec 05, 2003 at 01:33:47AM -0500, Isaac Richards wrote:
> On Thursday 04 December 2003 10:28 pm, David Engel wrote:
> > I think you're too used to the default key bindings. I'll give as
> > exaples the two cases I've run into so far.
> <snip>
>
> How's what I just committed to CVS look? I didn't test it much beyond
> compilation, but it should address both of your issues, I think..

I just glanced at it. Have you been reading my mind? You changed the
handled handling to what I was eventually going to suggest. :) I'll
test it tomorrow.

BTW, you didn't have to make the changes yourself. Since I brought
the issue up, I was willing to make them. Without knowing your master
plan for the key bindings, I just didn't want to make such a change
without getting clarification first.

David
--
David Engel
dlengel [at] attbi

ijr at po

Dec 5, 2003, 12:47 AM

Post #17 of 23 (2616 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Friday 05 December 2003 02:24 am, David Engel wrote:
> I just glanced at it. Have you been reading my mind? You changed the
> handled handling to what I was eventually going to suggest. :) I'll
> test it tomorrow.

Heh, cool.

> BTW, you didn't have to make the changes yourself. Since I brought
> the issue up, I was willing to make them. Without knowing your master
> plan for the key bindings, I just didn't want to make such a change
> without getting clarification first.

I was going to ask, but then I was trying to decide how I thought it should be
done, and then I got to writing code.. So, it was just easier to go do it.
There _are_ all the other TranslateKeyPress places to change, though =)

Hmm.. Probably don't need to do a good chunk of them (all the Qt widgets in
mythwidgets.cpp are most likely fine as is, since they only use the Global
context). Heh, I see I have mythvideo using the Gallery context. Oops. Not
that that's a problem, as there aren't any non-global keybindings in there,
but..

Isaac

jcaputo1 at comcast

Dec 5, 2003, 9:27 AM

Post #18 of 23 (2622 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Thursday 04 December 2003 17:38, Bruce Markey wrote:
> Isaac Richards wrote:
> > On Thursday 04 December 2003 09:40 am, Joseph A. Caputo wrote:
> >>How 'bout I add a boolean flag to the MythSpinBox class that
> >> controls whether or not this behavior is enabled. Default would
> >> be the current behavior, like so:
> >>
> >>Default (flag false)
> >> Left/Right = dec/inc by stepsize
> >> Prior/Next = no-op
> >>
> >>modified behavior (flag true):
> >> Left/Right = dec/inc by 1
> >> Prior/Next = dec/inc by stepsize
> >>
> >>if no stepsize set, default to 10
> >>
> >>What say ye?
> >
> > Sounds reasonable to me.
>
> Second that =). I'd like to test this on every spinbox to
> make sure some other odd case isn't overlooked just before
> a release.
>
> One suggestion. On the Default behavior, maybe Prior/Next
> should be stepsize also. That way, if the user uses them out
> of habit, they still work even though they do the same thing
> as the Left/Right keys.

Good idea... I'm compiling it now. If the new flag (sstep) is true, I'm
also setting the lineStep size to 10 in the constructor... no sense in
having PgUp/Down and Left/Right both only go by one. Any existing code
that sets the lineStep to an explicit value (including 1) should still
work properly.

-JAC

dlengel at attbi

Dec 5, 2003, 8:18 PM

Post #19 of 23 (2607 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Fri, Dec 05, 2003 at 02:47:53AM -0500, Isaac Richards wrote:
> On Friday 05 December 2003 02:24 am, David Engel wrote:
> > I'll test it tomorrow.

Aside from the small browse fix I made, everything looks good.

> There _are_ all the other TranslateKeyPress places to change, though =)

I think I'll just stand back out of the way. From the cvs logs, it
looks like you can't keep your fingers off the keyboard! :)

David
--
David Engel
dlengel [at] attbi

alden at math

Dec 6, 2003, 1:42 PM

Post #20 of 23 (2612 views)
Permalink

Re: Next release // website stuff? [In reply to]

Hi,
Is there any way the position can be saved if you're watching a
previously recorded show and you use a jumppoint? I love the new
jumppoints, I just find it annoying that if I'm watching a recording,
I can't really use them directly or else I lose where I'm at in the
show.
...dave

jcaputo1 at comcast

Dec 8, 2003, 8:50 AM

Post #21 of 23 (2635 views)
Permalink

Re: Next release // website stuff? [In reply to]

On Friday 05 December 2003 11:27, Joseph A. Caputo wrote:
> On Thursday 04 December 2003 17:38, Bruce Markey wrote:
> > Isaac Richards wrote:
> > > On Thursday 04 December 2003 09:40 am, Joseph A. Caputo wrote:
> > >>How 'bout I add a boolean flag to the MythSpinBox class that
> > >> controls whether or not this behavior is enabled. Default would
> > >> be the current behavior, like so:
> > >>
> > >>Default (flag false)
> > >> Left/Right = dec/inc by stepsize
> > >> Prior/Next = no-op
> > >>
> > >>modified behavior (flag true):
> > >> Left/Right = dec/inc by 1
> > >> Prior/Next = dec/inc by stepsize
> > >>
> > >>if no stepsize set, default to 10
> > >>
> > >>What say ye?
> > >
> > > Sounds reasonable to me.
> >
> > Second that =). I'd like to test this on every spinbox to
> > make sure some other odd case isn't overlooked just before
> > a release.
> >
> > One suggestion. On the Default behavior, maybe Prior/Next
> > should be stepsize also. That way, if the user uses them out
> > of habit, they still work even though they do the same thing
> > as the Left/Right keys.
>
> Good idea... I'm compiling it now. If the new flag (sstep) is true,
> I'm also setting the lineStep size to 10 in the constructor... no
> sense in having PgUp/Down and Left/Right both only go by one. Any
> existing code that sets the lineStep to an explicit value (including
> 1) should still work properly.
>
> -JAC

Okay, here's a new version of the patch... sorry I left it over the
weekend. The new constructor, with no extra arguments, keeps the
current default behavior, though the PgUp/PgDn keys are added &
duplicate the Left/Right functionality. If the constructor is called
with an extra flag = true, then the new behavior is enabled, where
Left/Right = step by one and PgUp/Dn = set by <stepsize>. If stepsize
is not specified (i.e., stepSize() == 1, which is the default), then
PgUp/Dn will jump by 10.

This patch has the new behavior enabled on the 'start minute' and
'duration' spinboxes in the Manual Schedule screen.

Assuming there are no problems with this, it can be committed. The only
enhancement I have planned is to extend this behavior to work with the
SpinBoxSetting class (SpinBoxSetting needs to expose the flag in its
constructor). Maybe I'll get to this today...

-JAC

Attachments:

spinbox.diff (3.23 KB)

bjm at lvcm

Dec 9, 2003, 6:05 PM

Post #22 of 23 (2581 views)
Permalink

Re: Next release // website stuff? [In reply to]

Joseph A. Caputo wrote:
...
> This patch has the new behavior enabled on the 'start minute' and
> 'duration' spinboxes in the Manual Schedule screen.

It seems to work for these spinboxes. There is some funky
behavior when crossing hour boundaries that pre-existed in
the 'start minute' box but otherwise each key works as
expected. The code doesn't look like it would cause any
other problems and I didn't find any. The only effect is
that the page up and down keys now do something =).

The patch did not apply cleanly against current CVS because
the "handled" flag changed. Attached is my modified version
for current CVS.

> Assuming there are no problems with this, it can be committed. The only
> enhancement I have planned is to extend this behavior to work with the
> SpinBoxSetting class (SpinBoxSetting needs to expose the flag in its
> constructor). Maybe I'll get to this today...

That would be great. The other place that this would be a
big win would be the Post-Roll and Pre-Roll boxes which
use SpinBoxSetting. It would be a Good Thing if at least
these boxes worked this way now. Other boxes could be
considered later.

-- bjm

Attachments:

spin2.diff (3.13 KB)

jcaputo1 at comcast

Dec 10, 2003, 11:37 AM

Post #23 of 23 (2631 views)
Permalink

Re: [PATCH] Jump behavior for spinboxes (was: Next release // website stuff?) [In reply to]

On Tuesday 09 December 2003 20:05, Bruce Markey wrote:
> Joseph A. Caputo wrote:
> ...
> > This patch has the new behavior enabled on the 'start minute' and
> > 'duration' spinboxes in the Manual Schedule screen.
>
> It seems to work for these spinboxes. There is some funky
> behavior when crossing hour boundaries that pre-existed in
> the 'start minute' box but otherwise each key works as
> expected. The code doesn't look like it would cause any
> other problems and I didn't find any. The only effect is
> that the page up and down keys now do something =).
>
> The patch did not apply cleanly against current CVS because
> the "handled" flag changed. Attached is my modified version
> for current CVS.
>
> > Assuming there are no problems with this, it can be committed. The only
> > enhancement I have planned is to extend this behavior to work with the
> > SpinBoxSetting class (SpinBoxSetting needs to expose the flag in its
> > constructor). Maybe I'll get to this today...
>
> That would be great. The other place that this would be a
> big win would be the Post-Roll and Pre-Roll boxes which
> use SpinBoxSetting. It would be a Good Thing if at least
> these boxes worked this way now. Other boxes could be
> considered later.

Try this one. I've added the new behavior to SpinBoxSetting, and modified the
Pre/Post roll spinboxes to use it (both global & per-recording). The
per-recording roll values will jump by 10 minute increments; the global
(which is in seconds -- probably should make these consistent) will jump in
60-second increments. I've also (I think) incorporated the new 'handled'
code.

-JAC

Attachments:

spinbox.diff (7.13 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads