[mythtv] MythTV GUI rebuild of current screen

[Mark Kendall]

On Thu, 12 Dec 2019 at 18:24, Klaas de Waal <klaas.de.waal at gmail.com> wrote:
>
> Hi,
>
> l am struggling a bit with the mythtv-setup GUI. There are pages, e.g.
> the "Card Type" where the type of the card selected does change the
> number of fields. When you select a DVB-S/S2 device there is an
> additional field about DiSEqC switches that is not present with other
> card types.
> The way it works now is that you have to select the DVB-S/S2 device,
> then save-and-exit, then select the page again and then the additional
> field is there.
>
> This is definitely not user-friendly and intuitive and I want to
> change this, if only to avoid documenting how this works.
>
> What I would like to do is to add the DISEqC field while the page is
> being displayed but I cannot figure out how to do that. Setting the
> field visible or not visible does not work. Enable/Disable does work
> and this is an alternative, especially now that the disabled fields
> are now painted grey.
>
> Comments and hints&tips are appreciated!

Klaas,

There are a couple of points worth mentioning - having been working
with this recently.

Firstly, as you've already mentioned/found out, the settings UI
currently cannot handle dynamically changing the settings shown (which
I think is a bit of a limitation - but couldn't get my head around how
to change that). So you have to show everything that you need and,
currently at least, disable what is not relevant. I think we can still
make some improvements to how disabled fields are shown.

Secondly, as Jonatan has mentioned, if you want more
complicated/dynamic behaviour like one setting reacting to a change in
another, then generally speaking you need to add code.

So using your example (I think), you would build the full list of
dvb-s/s2 devices and then connect the valueChanged signal for that
list to a function that populates/updates the diseqc values (and
enables/disables it).

As an aside, much of our code still uses the old SIGNAL/SLOT macros
for QObject::connect but I personally prefer the version that connects
to function pointers - e.g. connect(m_dvbsDevices,
&DVBSDevices::valueChanged... ) rather than connect(m_dvbsDevices,
SIGNAL(valueChanged(StandardSetting*)...). The function pointer
version gives you compile time checks (rather than run time failures).
You can also connect to lambdas where suitable - which helps contain
the code.

Hope this helps
Regards
Mark