[mythtv] MythUI miscellany

[Nigel Pearson]

>> 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 *>  
&focusList)
{
     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.
e.g.

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
MythContextPrivate::ShowOKpopup(...).


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