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
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