On 05/18/2011 01:57 AM, Dan Smith wrote:
- # Return channels for a bank. Bank given as number
- def get_bank_channels(self, bank):
nchannels = 0size = self._memobj.bank_sizes[bank]if size<= 198:nchannels = 1 + size/2_channels = self._memobj.bank_channels[bank]channels = []for i in range(0, nchannels):channels.append(_channels.channel[i])return channelsThis is so that we can present the user with a list of channels belonging to a bank, right? I.e, they want to create a bank by tagging channels into it instead of marking the channel with a specific bank...
We need it no matter how the UI ends up. It's the most natural way to decode the bank membership information in the image. In turn, it can be directly mapped to a spreadsheet like channels by banks layout, or something different.
So, maybe we need to change the UI to not allow per-memory bank editing for any of the radios, but rather make the bank editor more robust, and capable of handling the one-to-one and one-to-many bank models. I'm definitely in favor of a unified workflow in the UI. We'll just need to change the current bank-supporting drivers to return banks of memories (like you have above) and declare whether they support one-to-one or one-to-many.
Sound reasonable?
It does.
I've seen two different approaches:
- A separate tab for mapping channels to banks - Two different views in the channel editor, one with a column for each possible bank, and one with columns for the other channel attributes.
I can try to hack some of the UI changes up in a prototype patch if this seems like a good path forward.
Looking forward to it.
Jon LA4RT