[jeremypw]

Fixes #446

This PR addresses a number of issues around toggling the enabled property of monitors.

• Inactive monitors no longer are drawn as part of the layout, but as a smaller widget on the side
• Layouts that include a disabled monitor have a different key
• After changing the active state of a monitor the menu pops down and the "Apply" button is made sensitive
• After changing the active state of a monitor the remaining displays are rescaled and redrawn as if the change has been applied

This heads towards #74 although the disabled displaywidgets are currently still drawn on the overlay. A future improvement would be to put them in a separate sidebar widget.

[flodavid]

Hi @jeremypw. I took the liberty to rebase the branch on main and to fix the conflicts to be able to test this branch.
I found a few issues, so I also added small fixes.

Before them, starting from the following initial disposition:

if I disabled the blue screen, everything worked as expected, but disabling the "strawberry" one, the setup was updated to this (with the apply button active while the configuration is not valid):

With the fixes, I have the following. Still not perfect, as the blue screen aligned to the bottom of the yellow one, but good enough I think, as it is a valid configuration, close to the original one. (Re-enabling the disabled display moves the blue screen back to its initial position):

[flodavid]

A comment there would be nice, like Remove the dangling separator at the start

[flodavid]

Apart from the remark I added, the code looks good and can be merged after #423 is merged (if people are okay with the UI) my bad there are issues when two displays are disabled and we enable the first one.

[flodavid]

I see, the issue is here (comment in the code):

        // Generate a unique key based on the virtual monitors' monitors hashes
        //NOTE The key depends on the order of the list which will change depending on whether monitors are
        // active or not (and possibly on the order they were connected).
        //TODO Consider whether a more controlled key is needed

We try to load a configuration where ":DISABLED" is in the middle of the key, but ":DISABLED" is always saved at the end, so the configuration is not found.

[flodavid]

I fixed most issues I found when disabling two displays and then re-enabling them. There is just one issue that remains with only one of my screens. When I re-enable it, it goes over the other active displays. It does not happen with the other display of the same model I have. So my guess is that it is linked to the order that the displays are arranged. I will try to find a solution.
I will also fix the linting issue.

[flodavid]

I found the issue. It was not exactly an order issue.
When enabling a monitor transform was set after x and y and modifying it changes the transform dropdown selected value, which triggers configuration and positions checks, potentially modifying x and y.

It was the last wrong behavior I found with this PR when testing with three monitors.
There are the lint issues left, which I fill fix soon.

[flodavid]

I fixed the lint issues.
@jeremypw can you take a look at my changes ? I think this PR is good as it is.

[jeremypw]

I found an issue with disabling monitors while testing this but it appears to be unrelated to these changes as it happens in main before #423 was merged. Maybe related to an old issue #20 where I have left a comment.

[jeremypw]

@flodavid Thanks for your work on these two PRs. I have now merged them so we can work on any issues as they arise and start to improve the interface.