[mythtv] MythUI miscellany

Nigel Pearson nigel at ind.tansu.com.au
Thu Aug 14 01:00:09 UTC 2008

>> Looks like AddFocusableChildrenToList() doesn't
>> take visibility into consideration.
>> I will patch this soon.
> It does as of about a week ago, have you updated in the last few days?

At least twice a day :-)

% cat libs/libmythui/mythuitype.cpp
void MythUIType::AddFocusableChildrenToList(QMap<int, MythUIType *>  
     if (m_CanHaveFocus)
         focusList.insertMulti(m_focusOrder, this);

Changing that to (m_CanHaveFocus && m_Visible)
got single button MythConfirmationDialogs working
for me. MythDialogBox with multiple buttons
continues to work. Haven't tried others yet.

>> 2) A screen stack may contain several children,
>> but PopScreen() will only remove the top one.
> Just curious what you have planned?

Popup management in complicated call sequences.

1) MythContext::SendReceiveStringList() creates
a Dialog "The connection to the master backend "
"server has gone away for some reason.. "

2) LiveTV adds one that says
"You should have got a tuner lock by now"

3) Some later code invokes
MythContext::ConnectServer(), which reports
"Could not connect to the master backend"

We shouldn't block for any of these information
Dialogs, but I don't want multiple dozens of
Dialogs created by MythContext, so 1) and 3)
will call Popup generator, something like

It can't simply PopScreen, because that
would remove someone else's Dialog.
I either have a PopScreen loop to remove
everything in "popup stack", or we add
an API to remove specific ScreenTypes.

>> I think we need:
>> MythConfirmPopup(const QString &msg);
> Well you can suggest it to Isaac, but when I floated the idea of  
> having the
> popup dialogs add themselves to the stack he wasn't in favour. You  
> could
> create a new ConfirmPopup member for those classes which would  
> avoid the
> repetition

I tried adding something to MythContextPrivate,
but then mythmediamonitor and backendselector need
to do the same thing, and I haven't looked at all
the other libs yet. This really is a utility thing.
I don't think we should lose these error popups,
but implementing each in libmythui is a lot of
duplicated code.

> I'm not sure we always want to assume that dialogs will be in the  
> popup stack,
> there may be times when they'll be needed elsewhere.

Sure, but special needs can be explicitly coded.

As long as there is a popup stack in the themebase,
something like this should still work for these
library errors, though

> I agree it would be nice if they were all consistent.

Better to do sooner, before too much old UI changes?

Nigel Pearson, nigel at ind.tansu.com.au|"Look at this!
Telstra Net. Eng., Sydney, Australia | Do you think I put this in
Office: 9202 3900    Fax:  9261 3912 |  to get better reception?"
Mobile: 0408 664435  Home: 9792 6998 | Batty - Fern Gully

More information about the mythtv-dev mailing list