[mythtv] diseqc

Yeasah Pell yeasah at schwide.com
Fri May 26 17:35:42 UTC 2006


>How about "dtv_device_config" and "dtv_device_tree" ?
>  
>
Sounds good. I'll use those names and derivatives.

>Implement the configuration UI before you get too attached
>to the schema. I think it is probably easiest to just have
>parent pointers in the device tree, with zeroed parent pointers
>for the roots.
>
>  
>
Here's my thoughts on the UI -- There are certainly tricky bits, but as 
far as the schema to UI relationship goes, it seems straightforward to me.

In the place where the diseqc type is configured (in the capture card 
setup), the interface initially stays similar. As a first cut, I'll 
probably just separate the switch type selection from the motor type 
selection, and have it build a tree based on those simple selections. 
This would fill my requirement (switch + rotor) without necessitating 
the much more complex UI task of presenting the device tree for 
modification.

Later, when a full tree-building UI is constructed, I envision that the 
user would pick from the "simple" or "advanced" diseqc setup mode. In 
addition to allowing the staged development path, I think it is 
important to keep the simple configuration interface as the default 
since the majority of users probably have very simple diseqc 
configurations which do not warrant the complexity of the tree interface.

I'm not clear on exactly what interface the tree-building UI should 
employ, but ideally it would look like an indented hierarchy of nodes. 
Leaves would always be populated with LNBs, so you wouldn't have to add 
those manually (but of course you could edit their type and parameters). 
It should probably load the tree from the DB into an in-memory tree 
structure and perform operations on that in-memory structure, so that 
the whole editing operation can be cancelled if the user desires. 

In the place where diseqc settings are configured (the input setup), the 
current interface would be replaced with a dynamic list of pull-down 
(for most options) or text entry (for usals angle) fields, in tree 
order. LNBs would not appear in this list, as they have no per-input 
config. The tricky bit here is that the set of devices you are 
configuring may change as you change options in the case of cascaded 
switches. If this is too confusing there are some tricks we could pull 
to minimize the impact of it, but I suspect that the list of people who 
would use cascaded setups is a proper subset of the list of people who 
could handle that kind of complexity in the UI.



More information about the mythtv-dev mailing list