[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mythtv-dev
Subject:    [mythtv] =?utf-8?q?Extending_mythnotification_UDP_interface=3F?=
From:       warpme <warpme () o2 ! pl>
Date:       2013-07-03 12:09:30
Message-ID: 6461c9c8.35a62ea5.51d4147a.b2fba () o2 ! pl
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Jya,
 
Big thx for notify extension. It is cool thing.
 
So cool that I want to use it for following, additional cases: 
notification-new-mail
 notification-disk-attached
 notification-disk-detached
 notification-disk-full
 notification-cpu-overheat
 notification-incomming-call-start
 notification-incomming-call-end
 notification-outgoing-call-start
 notification-outgoing-call-end
 notification-archive-disk-connected
 notification-archive-disk-disconnected
 
Names should be self-explanatory.
 
I know 0.27 is in features freeze.
 
For approaching above with minimal effort, I think 2 phases might be worth to \
consider:  
Short-term: add to UDP interface possibility to provide all fields \
(coverart,album,artist,time,info,progress). Only in UDP. mythutil can stay like \
today.  
Long-term: add to notification-ui.xml window definitions/translations for above.
 
Only real functional difference between short-term and long-term is possibility to \
define particular(per notification type) widow size/layout in long-term solution. Not \
big deal remembering that short-term ext.app. can already feed type-relevant \
dedicated icon/picture using UDP interface.  I think short-term will be flexible \
enough to temporarily stop users complaints for impossibility to make multiple \
layout-differentiated notifications.  
What You think?   


[Attachment #5 (text/html)]

Jya,<br /> <br /> Big thx for notify extension. It is cool thing.<br /> <br /> So \
cool that I want to use it for following, additional cases: <br /> <br /> <br /> \
notification-new-mail<br /> notification-disk-attached<br /> \
notification-disk-detached<br /> notification-disk-full<br /> \
notification-cpu-overheat<br /> notification-incomming-call-start<br /> \
notification-incomming-call-end<br /> notification-outgoing-call-start<br /> \
notification-outgoing-call-end<br /> notification-archive-disk-connected<br /> \
notification-archive-disk-disconnected<br /> <br /> Names should be \
self-explanatory.<br /> <br /> I know 0.27 is in features freeze.<br /> <br /> For \
approaching above with minimal effort, I think 2 phases might be worth to \
consider:<br /> <br /> Short-term: add to UDP interface possibility to provide all \
fields (coverart,album,artist,time,info,progress). Only in UDP. mythutil can stay \
like today.<br /> <br /> Long-term: add to notification-ui.xml window \
definitions/translations for above.<br /> <br /> Only real functional difference \
between short-term and long-term is possibility to define particular(per notification \
type) widow size/layout in long-term solution. Not big deal remembering that \
short-term ext.app. can already feed type-relevant dedicated icon/picture using UDP \
interface. <br /> <br /> I think short-term will be flexible enough to temporarily \
stop users complaints for impossibility to make multiple layout-differentiated \
notifications.<br />  <br />
What You think?   <br />



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-dev


[prev in list] [next in list] [prev in thread] [next in thread]