Somewhere between deCONZ v2.25.3 and v2.28.1 the desktop window manager has been replaced.
Now the GUI doesn’t offer any possibility to close unneeded windows (using a huge amount of visible space) like originally mentioned e. g. here:
Closing this grey “basic VNC control window” using [ALT] + [SHIFT] + [C] as mentioned here is working great. Even it’s not intuitive and not written anywhere in the UI, so more like a “magic hack”.
But how to e. g. close the DDF editor (left part of the window)?
In general, the horizontal alignment of windows is kind of an issue while the vertical alignment from the past years was working great, being switchable by the window name at the top - quite intuitive, no need to actually close windows.
By the way: trying to use [ALT] + [SHIFT] + [C] in the DDF editor situation for example is not a good idea, as it is possible (e. g. when the mouse focus is on the right main part of the screen) it closes the whole deCONZ gui (like it does when it is the last window opened), resulting in a fully black screen and the need to wait some time until it obviously automatically reloads - again with the default look (containing the “basic VNC control window”).
1) How to close the DDF editor? 2) Can we set the new DWMs default to align windows vertically again to work around these new GUI issues?
It’s a really strange thing, I’m not sure why the window title bars sometimes are above the visible screen, if it’s Qt or the Window Manager, this wasn’t a problem in the past but the code for the window handling also wasn’t changed
That‘s a good idea. If possible for the grey window, too.
Can you reference a PR so we can watch when it arrives in a new (stable) release?
In general the window positioning needs a rework I think. Effectively working e. g. with the DDF editor with only 50 % of the screen is even on a 4K screen a bit challenging.
Well, using [ALT] + [SHIFT] + [C] now - another day, another endpoint using deCONZ - closed the DDF editor - but the remaining (main) window did not resize. I’m now stuck with this:
…AND: it seems like the whole addon gets restarted. I see things like these in the addon log:
[22:45:50] INFO: Successfully send discovery information to Home Assistant.
...
22:45:24:238 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXXXXXXXX-if00 / serialno: XXXXXXXXXX, ConBee II
And also because of the addon restart all information in HA is updated (unavailable entities and wrong entity last changed states etc.). So it creates quite some issues beside the fact the deCONZ UI is hardly usable.
So: kicking most of my smart home out of order for a few minutes only because of a - let’s agree to call it ‘broken/unusable DWM’ - is not that funny.
I fear this whole DWM thing needs much more attention than adding a bit of UI cosmetics.
May I suggest to finally switch to a PROPER window manager that can be used with the mouse like virtually EVERY other window manager out there since the invention of the mouse instead of forcing one of these exotic experimental incomplete unusable toy window manager experiments onto all the innocent users?
I’m asking myself… how can they even release a change like that without proofing it against common use-case scenarios? That’s straight away a P2 or P1 defect.
It all comes back to the never-ending core issue: nobody is REALLY taking care about deCONZ (specifically the addon) in Home Assistant. HA devs don’t understand the deCONZ mechanics, deCONZ team has no interest and/or no human resources to support the addon (yes, they still accept to not have full or ANY control about their product in the most important home automation system on this planet).
I put in so much energy in bringing up discussions about and raising awareness for this bad situation so so SO many times especially this year. Last time the mod even banned me on Discord - not being rude, just fingerpointing at this situation. Therefore I’m pretty much done with that “look, another result of the unmaintained deCONZ HA addon status” issue. Users need to accept that unacceptable situation - or migrate away from deCONZ software. This issue/topic and the now two months of wasted time seem to just act as another proof for this.
Hi all, sorry for the late response. The VNC support in deCONZ HA add-on right now is problematic, if I understand correctly since the former window manager/VNC thing needed to be replaced.
My knowledge here is super limited, but another option could be to expose the deCONZ GUI via VNC by using the Qt VNC QPA plugin and then use a regular VNC client to connect to it (not the Web based one which is embedded into HA).
At least from the deCONZ perspective this doesn’t look too complicated and would work similar to how the “headless” deCONZ run method works, by using the vnc instead of minimal qpa.