------------------------------------------------------------------------
A poll associated with this post was created, to vote and see the
results, please visit http://forums.slimdevices.com/showthread.php?t=79524
------------------------------------------------------------------------
Question: Are you interested in IR-over-IP?
- Yes, I'd like to have IRoIP.
- No, I don't care.
------------------------------------------------------------------------
> I don't see the difference between a <command_group> and a <remote>.
I agree there's not much else in the <remote> element - the main reason
I thought this might be a good idea is to avoid splitting the buttons on
a single remote into two or more ID attributes, which means you have to
remember / guess later on which button pertains to which device ID. Two
or more names doesn't seem to be a good metaphor for the single remote a
person might hold in their hands. I suppose allowing identical ID tags
on <remote> elements would also allow this, if it doesn't introduce
other problems.
> A way to make menus from profiles without having to duplicate the xml?
> Not sure, things get really complicated when you begin to define
> multiple profiles each with a set of nested menus. I'll have to think
> about it more carefully!
I guess I'm seeing the trade-off of having multiple menus and profiles
independent of one another versus ease of configuration a bit
differently. I'm not really in a good position to sound off on this
because I've only tried to define a simple config and I've no idea how
anyone else uses the system. For me, though, things would be just as
good if profiles and menus were run together and both changed at the
same time (either with a player change or selection from the root
menu). I suspect you've gone to a lot of trouble to come up with such a
flexible system in the first place, so this may not be an attractive
option!
Another method that springs to mind (and one that maintains the
independence of the profiles and menus) is to allow the <actions> or
even <events> group to be defined independently and refer to actions /
events rather than commands in the <menu> and <profile> sections. My
first thought was to do this in the <remote> sections: instead of an
ID'd <command>, an ID'd <event> could be referred to later on. But of
course <remote> probably should literally describe a remote and in the
case of imported LIRC files, there are no <command> elements to replace
anyway. The alternative is introducing an additional layer of
abstraction, complicating the XML in one way, even though it simplifies
in another. I'm thinking something like the following:
Code:
--------------------
<remotes>
<remote ID="sample_remote">
<command_group protocol="DENON">
<parameter ID="device">12</parameter>
<parameter ID="subdevice">20</parameter>
<command ID="POWER"><value>80</value></command>
<command ID="SLEEP"><value>114</value></command>
</command_group>
</remote>
</remotes>
<events>
<event ID="POWER">
<modifier>once</modifier>
<actions ID="POWER">
<action order="1">
<remote>RC-877_AMP</remote>
<command>POWER</command>
</action>
</actions>
</event>
<event ID="SLEEP">
<modifier>all</modifier>
<sound>true</sound>
<actions>
<action order="1">
<remote>RC-877_AMP</remote>
<command>SLEEP</command>
<pause>2</pause>
</action>
</actions>
</event>
<event ID="SLEEP_30">
<modifier>once</modifier>
<sound>true</sound>
<actions ID="SLEEP_30">
<action order="1">
<remote>RC-877_AMP</remote>
<command>SLEEP</command>
<pause>2</pause>
<count>4</count>
</action>
</actions>
</event>
</events>
<profiles>
<profile>
<menu>SAMPLE</menu>
<keys>
<key ID="65"><event>POWER</event></key>
<key ID="stop">
<use ID="hold"><event>SLEEP</event><modifier>all</modifier></use>
<use ID="press"><event>SLEEP_30</event></use>
</key>
</keys>
</profile>
</profiles>
<menus>
<menu ID="SAMPLE">
<profile>SAMPLE</profile>
<item order="1"><caption>Power</caption><event>POWER</event></item>
<item order="2"><caption>Sleep</caption><event>SLEEP</event></item>
<item order="3"><caption>Sleep (30
mins)</caption><event>SLEEP_30</event></item>
</menu>
</menus>
--------------------
I -think- this takes care of all the subtleties necessary (but I'm not
completely familiar with your schema) and I've tried to stick to the
same rules you seem to be using elsewhere (only a single attribute to
any tag, similar elements in their own container element, things that
change with other values - such as "device" and "subdevice" do with
"protocol" - as parameters rather than element names), but I'm not
really sure what the constraints are. The <events> section is still
just as verbose, but the <menus> and <profiles> sections are a lot
tidier which should make editing them and duplication between menus and
profiles easier, especially with simpler items each on their own line.
I take your points about the other things - especially the XML
processing: I didn't realise a built-in, robust library wasn't
available.
I'll try to find a definitive way of reproducing the timer error and
let you have the full details. Pauses were all copy & pasted, but it's
more than likely I made a mistake in the "order" attributes (I've
deleted all the XML now). I couldn't see anything else in the log, but
I'll double check that.
--
TheAbbot
------------------------------------------------------------------------
TheAbbot's Profile: http://forums.slimdevices.com/member.php?userid=33769
View this thread: http://forums.slimdevices.com/showthread.php?t=79524
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
