[mythtv] [mythtv-commits] Ticket #5615: Add keyboard input to MythConfirmationDialog, exec() to new mythui Dialogs

[Nigel Pearson]

>> - 1. MythConfirmationDialog currently only responds to mouse clicks
>
> That first one should not be true, although I've not actually  
> tested it

OK, it's probably the way I am invoking it
(in my hacky extra run-loop).



...
> When I originally started converting to mythui I missed them
> but Isaac very deliberately designed them
> to be non-blocking and I've grown used to it now.

I agree that blocking is a bad thing,
and we must minimise its use. Most of
the current popups are informational,
and can be replaced by a simple OK
comfirmation which does nothing.



There are some uses (decisional flows)
that I think still need blocking. e.g.:

1) Schema upgrade prompt. Dangerous, so we
do this before qApp->exec() and main menu.

Essential that the user makes a decision
(because it can kill their working setup)



2) The user hits escape/Apple-Q/Alt-F4 in
the top-level menu, qApp->exec() returns,
handleExit() prompts for 6 different sets
of shutdown/reboot/halt.

It is almost possible to non-modalise this
(by intercepting most of these exit events
  in the MainWindow handler, and making it
  create a popup with appropriate slots
  to do the halt/shutdown/reboot/et c.),
but it has to behave very differently for
mythfrontend, mythtv-setup, mythtv and
mythwelcome.



3) Database bootstrapping. The modal popups
don't need to be blocking, but the whole
process is, because it is before the main
menu run loop. Still thinking about this,
but suspect it will need to call qApp->exec()
with both successful MC::FindDatabase() or
the various Exits, exiting the qApp runloop.

--
Nigel Pearson, nigel at ind.tansu.com.au|  4  8
Telstra Net. Eng., Sydney, Australia | 15 16
Office: 9202 3900    Fax:  9261 3912 | 23 42
Mobile: 0408 664435  Home: 9792 6998 |  Lost