Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

Display popup from network control. Was: Re: Displaying messages from mythshutdown in mythfrontend - ideas?

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


devel at mrwire

Aug 22, 2007, 5:13 PM

Post #1 of 3 (754 views)
Permalink
Display popup from network control. Was: Re: Displaying messages from mythshutdown in mythfrontend - ideas?

Please see attached the latest version of my patch to display a popup
from the network control interface in mythfrontend.

USAGE:
>From the telnet interface the following commands are accepted:
/* Message format:
POPUP message defaultbutton timeout button1 button2 button3 buttonN
returns [popupIdentifier] OK
POPUP status (optional)[popupIdentifier]
returns [popupIdentifier] {ACTIVE|CLOSED}
POPUP close
returns [popupIdentifier] CLOSED

* The network interface returns immediately with an identifier for the
popup and "OK".
* Popup status can be obtained using popup status. This will return 0
or the popupIdentifier and ACTIVE or CLOSED.
* popup close will close any active popup.

* Creating a new popup will close any previous one.
* Use underscores (_) instead of spaces for messages/buttons - they will
be converted for display.
* The timeout is in seconds and will automatically cancel the popup
after the timeout.

KNOWN ISSUES:
* There is currently no way of querying which button was pressed. I'm
obviously planning on doing something about this but not sure how yet...
Probably allowing a query via the popup status message could return
button number as well if closed?
* There is no way of signalling that the dialog has been closed. This
will probably not be changed unless someone comes up with a good
solution!

Cheers,
Matthew

PS. Peter, this solves your first point about the dialog disappearing
automatically - if your app detects a dvd inserted it can simply send
popup close to mythfrontend and the dialog will go away!
Attachments: mythtv-networkdialog.diff (4.75 KB)


schachte at csse

Aug 23, 2007, 7:49 PM

Post #2 of 3 (701 views)
Permalink
Re: Display popup from network control. Was: Re: Displaying messages from mythshutdown in mythfrontend - ideas? [In reply to]

Hi Matthew,

Matthew Wire wrote:
> Please see attached the latest version of my patch to display a popup
> from the network control interface in mythfrontend.

Thanks! That looks like exactly what I was after.

> USAGE:
>>From the telnet interface the following commands are accepted:
> /* Message format:
> POPUP message defaultbutton timeout button1 button2 button3 buttonN
> returns [popupIdentifier] OK

Is "defaultbutton" a button name or number? If it's a name, is that name
required to be one of the button1...buttonN, or is it in addition to them?

> POPUP status (optional)[popupIdentifier]
> returns [popupIdentifier] {ACTIVE|CLOSED}
> POPUP close
> returns [popupIdentifier] CLOSED

It'd be safer to require a [popupIdentifier] with the close, in case it's
already been closed, or, worse, another popup has been opened by another
process (which you wouldn't want to close by accident).

> KNOWN ISSUES:
> * There is currently no way of querying which button was pressed. I'm
> obviously planning on doing something about this but not sure how yet...
> Probably allowing a query via the popup status message could return
> button number as well if closed?

How about:

POPUP status (optional)[popupIdentifier]
returns [popupIdentifier] {ACTIVE|CANCELLED|CLOSED buttonN}

where buttonN is one of the button identifiers

> * There is no way of signalling that the dialog has been closed. This
> will probably not be changed unless someone comes up with a good
> solution!

It's not really necessary, since you can poll with POPUP status. But on the
theory that polling is evil, you could add another command to wait until a
button is pressed or the dialog is cancelled. Equivalent to repeatedly calling
POPUP status until it returns something other than ACTIVE, but without actually
polling. Something like:

POPUP wait (optional)[popupIdentifier]
returns [popupIdentifier] {CANCELLED|CLOSED buttonN}

But I don't know enough about working with sockets to know whether or not this
is a stupid idea.

Last question: are you going to open a ticket and attach this patch? I'd love
to see this incorporated into 0.21.

Thanks for sharing this!

--
Peter Schachte Everything is relative. If the the rich are
schachte [at] cs getting a lot richer and the poor are getting a
www.cs.mu.oz.au/~schachte/ little richer, then the rich are getting richer
Phone: +61 3 8344 1338 and the poor are getting poorer. -- me
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


devel at mrwire

Aug 24, 2007, 4:26 AM

Post #3 of 3 (695 views)
Permalink
Re: Display popup from network control. Was: Re: Displaying messages from mythshutdown in mythfrontend - ideas? [In reply to]

> Is "defaultbutton" a button name or number? If it's a name, is that name
> required to be one of the button1...buttonN, or is it in addition to them?
It's a number, starting at 0 for the first button.

> > POPUP status (optional)[popupIdentifier]
> > returns [popupIdentifier] {ACTIVE|CLOSED}
> > POPUP close
> > returns [popupIdentifier] CLOSED
>
> It'd be safer to require a [popupIdentifier] with the close, in case it's
> already been closed, or, worse, another popup has been opened by another
> process (which you wouldn't want to close by accident).
I'll make the popupIdentifier on close an option. If it's already been
closed it's no problem since it will just return 0 as the identifier.

> How about:
>
> POPUP status (optional)[popupIdentifier]
> returns [popupIdentifier] {ACTIVE|CANCELLED|CLOSED buttonN}
>
> where buttonN is one of the button identifiers
I was thinking of something like that myself. Just have to work out how
to find out which button was pressed programmatically.
The other issue is that the status needs to be stored somewhere after
the popup has been closed, how many results should be stored? If two
popups run in quick succession you'd need to store the result of the
first and second one.

> It's not really necessary, since you can poll with POPUP status. But on the
> theory that polling is evil, you could add another command to wait until a
> button is pressed or the dialog is cancelled. Equivalent to repeatedly calling
> POPUP status until it returns something other than ACTIVE, but without actually
> polling. Something like:
>
> POPUP wait (optional)[popupIdentifier]
> returns [popupIdentifier] {CANCELLED|CLOSED buttonN}
>
> But I don't know enough about working with sockets to know whether or not this
> is a stupid idea.
The first patch I wrote waited until the popup was closed, but this did
nasty blocking and stuff to the UI, and also blocks the network control
interface. So, polling is the way to go I think.
>
> Last question: are you going to open a ticket and attach this patch? I'd love
> to see this incorporated into 0.21.
I will, but I want to iron out some of the kinks first - such as getting
the pressed button. Also, I will probably write some code for
mythshutdown to demonstrate the dialog.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.