Opened 11 years ago

Closed 11 years ago

#5615 closed enhancement (invalid)

Add keyboard input to MythConfirmationDialog, exec() to new mythui Dialogs

Reported by: Nigel Owned by: Isaac Richards
Priority: minor Milestone: 0.22
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

  1. MythConfirmationDialog? currently only responds to mouse clicks
  2. libmythui dialogs are modal, but don't provide an API which allows the calling code to block until the user selects something off them

Attached patch fixes both of these. Have done reasonable testing, but not with any animation-heavy themes (only clock widget) or other background heavy processing stuff.

Attachments (2)

mythui.patch (5.2 KB) - added by Nigel 11 years ago.
mythdialogbox.diff (4.7 KB) - added by paulh 11 years ago.
Non blocking popup patch

Download all attachments as: .zip

Change History (4)

Changed 11 years ago by Nigel

Attachment: mythui.patch added

Changed 11 years ago by paulh

Attachment: mythdialogbox.diff added

Non blocking popup patch

comment:1 Changed 11 years ago by paulh

Great minds think alike I was just working on exactly the same idea. I've attached what I have for reference. It's only a quick proof of concept and isn't complete. I've tested it with the GANT theme which has the fading logo and it works fine.

You would use it just like the old dialogs which would make converting things over easy:-

   MythConfirmationDialog2 *dialog = new MythConfirmationDialog2("Are you sure?", true);
   bool res = dialog->Exec();

   if (res)
   {
         // do something
   }

As Stuart says your keyPressHander probably wont work as expected when you have both buttons visible? I think you should always give the currently focused widget a change to process the keypress first as well. And also while testing I found it a bad idea to pass unhandled keypresses on from the poupup because it caused unexpected behavior.

comment:2 Changed 11 years ago by Isaac Richards

Resolution: invalid
Status: newclosed

Anything using processEvents() will *not* be accepted. This is poor design, and leads to lots of unintended side-effects in any non-trivial case.

Blocking code in UI is bad - things need rewritten to wait for a completion event.

Note: See TracTickets for help on using tickets.