Desktop does not resize on many screen size changes

[outpaddling]

This is an ongoing minor problem with at least the past few versions. When running Lumina in a FreeBSD guest under VirtualBox with guest additions installed, the desktop does not resize the first time the screen size is changed via dragging the vbox window corner. The second and subsequent resizes all work fine.

[q5sys]

I 'think' this is a virtualbox issue more than a TrueOS issue. But we'll look into it when we get time. Thanks for the bug report!

[outpaddling]

Well, I used several other desktops before Lumina came along and never saw this issue with them. I just confirmed that it does not occur with gnome3. Thanks!

[outpaddling]

MATE, LXDE and XFCE also work fine.

KDE does exhibit the same issue, so maybe it's a QT issue.

[q5sys]

Thanks for reporting back, that'll give us a place to start looking.

[outpaddling]

I'll also try removing virtualbox-ose-additions and resizing from the display settings, just to rule that out. Last time we discussed resizing issues, they were reproducible outside virtualbox, but who knows...

[outpaddling]

Without guest additions, and using "xrandr --size" from the command line so that Lumina isn't directing the resize from the beginning, everything works fine. One other issue with resize is that the RSS reader doesn't reposition to the new lower right corner when the screen size is increased. Works fine when decreasing.

[outpaddling]

Just checking in to report that it's still an issue with 1.6.0 on FreeBSD 12.1. I installed an LXQT desktop yesterday and it did not exhibit the same issue.

If you have a little time to try and reproduce this, you can duplicate my setup using sysutils/desktop-installer in probably half an hour on a decent machine. Just choose Lumina from the menu and default responses for everything else.

Thanks again for your work on this. Lumina is by far my favorite DE!

[outpaddling]

I just realized that the problem has changed for the worse since I reported it, so I just edited the title. At some point in the past, it only affected the first resize, but now the problem is likely to occur on most resizes. The first resize does not seem to be detected for LXQT either, but after that LXQT resizes cleanly and reliably. Lumina, however, does not respond to many resize events and sometimes responds badly, drawing the dock across the middle of the screen and failing to resize the background image. It seems more likely to work properly when the window is shrunk than when expanded. Would it be possible to prioriitize this issue? It's the only major problem I see with Lumina under VirtualBox. Other remaining issues are not that bothersome.

[outpaddling]

Status update: The problem persists under VirtualBox 6.1.22. FreeBSD host and guest. ( Note that FreeBSD guests do not work properly with VMSVGA - use VBoxSVGA. ) FreeBSD + XFCE guest now resizes flawlessly, whereas it used to not respond to the first resize.

[q5sys]

Thanks for reporting back, there's definitely something weird going on, but i have no idea where. My gut is that it's either a QT issue or a fluxbox issue. Are you able to load Fluxbox natively and see if you can reproduce it just with fluxbox? Alternatively... change the Window manager for Lumina to something like openbox (you'll have to install it) and then restart lumina and see if it behaves the same. That will at least let us eliminate one possibility.

[outpaddling]

Just played a bit more to clarify. It doesn't look like a WM issue to me. The desktop is fully accessible after a resize, but the background does not redraw and interestingly the menu bar does not get placed properly on ODD resizes, while it does on EVEN ones. I.e. on the first resize, the menu bar is misplaced, on the second one it's back to the bottom where it belongs, the third it's misplaced again, etc. You can see an example in the attached pictures. A fluxbox-only setup resizes fine, as long as I run VBoxClient --vmsvga beforehand. This seems to be necessary for all basic WMs. Doing the same with Lumina doesn't help, though.

[outpaddling]

I tried switching to openbox and this didn't really change anything. Window decorations were different on the next login, but the only difference in behavior was that the main panel disappeared completely on odd resizes rather than being misplaced. It was drawn correctly on even resizes just as with fluxbox. The background still did not resize.

[outpaddling]

And KDE resizes properly now, though it's quite sluggish, maybe because my VM has only 2GiB RAM.

[outpaddling]

After playing with this for a while, it appears that the only issues are placement of the bottom panel after every other resize, and redrawing the background image. The background image redraws properly on the next timed rotation (if wallpaper rotation is enabled). Otherwise the desktop is fully functional after every resize as far as I can tell.

[outpaddling]

Similar behavior under VMWare: The background image does not get redrawn after resizing the virtual screen. The bottom panel does get resized and properly placed, though, so that issue may be specific to VBox.

[beanpole135]

Can you do something for me? After screen resizes, run lumina-desktop --check-geoms from a terminal and see if that resets the background/panel sizes for you.

[outpaddling]

That relocates/resizes the bottom panel, but has no effect on the wallpaper.

[beanpole135]

ok, so that means 2 things:

1. Lumina is never getting the notification from the WM that the screen geometry changed. Running that lumina-desktop --check-geoms command just manually triggers the event handler.
2. The wallpaper change routine in Lumina probably needs some kind of "force" flag to have it repaint the wallpaper even if the file did not change.

[outpaddling]

1. Lumina is never getting the notification from the WM that the screen geometry changed. Running that `lumina-desktop --check-geoms` command just manually triggers the event handler.

Why does it work every second time?

[outpaddling]

Just checked for the first time in ages and realized that there are resize problems on a hardware screen as well. This is after shrinking and restoring my laptop screen to it's native size: After some resizes, it seems like the WM died, because I couldn't close or move the preferences window.

[outpaddling]

Suggestion: Since polling the screen geometry takes something on the order of a microsecond, could you, as a clearly documented temporary hack, poll the geometry once per second and manually redraw things when it changes? We can leave this issue on the back burner for now and maybe it will go away when a new WM is integrated. Then we at least have a workaround ASAP and I can remove the warning from desktop-installer about using Lumina in a VM. Then again, maybe you're close to finding the root cause, which would of course be better.

[grahamperrin]

https://github.com/lumina-desktop/lumina/issues/536#issuecomment-850669645

hardware

As the symptoms are not specific to VirtualBox, can you edit the title of this issue? Thanks.

Some aspects of the screenshots under https://github.com/lumina-desktop/lumina/issues/536#issuecomment-847245369 are vaguely familiar to me, but not from #217; from a discussion elsewhere (I can't recall where) long ago.

[outpaddling]

With 1.6.2, the problem got worse. After resizing a vbox screen, the panels disappear and never return now.

[outpaddling]

With 1.6.2, the problem got worse. After resizing a vbox screen, the panels disappear and never return now.

I went back into Preferences/Panels and found the panel list empty. If I then click the profiles menu, copy screen, :0.0, Apply, the menus are restored. Then the resize behavior is pretty much back to how it was. Every 2nd shrink, panel 1 moves to the top of the screen. Expanding it sometimes stays at the bottoms but in the old position and the background doesn't redraw. After several resizes, it disappeared again.

[outpaddling]

Checked again on the hardware display of my T430. The first few resizes went fine, but when I went to 1368x768, the panel went form the bottom where it belongs to the top, and got truncated. I also noticed something new: The window manager was somehow hosed. New windows opened with no borders. I verified that fluxbox was in fact running using "ps ax" on a text VT, but it clearly wasn't interfacing with the applications.

[outpaddling]

If you guys could guide me down the right path, I'd be willing to try and track down the source of this issue and maybe even come up with a fix. I have a little experience with X11 programming from many years ago, but just Xlib and Xt. I'm mainly a systems and scientific programmer. In particular, if I knew the entry point into Lumina for a screen resize event, I might be able to trace the code forward from there and spot the problem. I poked around a bit and found this commented out, which looks suspicious to me:

//connect(screen, SIGNAL(resized(int)), this, SLOT(UpdatePanel()) ); //in case t
he screen resolution changes

But I'm not sure it's relevant and it would take too long to figure that out on my own.

[outpaddling]

Well, guess what... I uncommented the connect() call above and now the panel redraws properly every time in my VirtualBox guest.

--- lumina-desktop/LPanel.cpp.orig      2022-02-23 23:50:42 UTC
+++ lumina-desktop/LPanel.cpp
@@ -74,7 +74,9 @@ LPanel::LPanel(QSettings *file, QString scr, int num, 
     //panelArea->setWindowOpacity(1.0); //fully opaque for the widget on top (apply stylesheet transparencies)
   }
   QTimer::singleShot(1,this, SLOT(UpdatePanel()) );
-  //connect(screen, SIGNAL(resized(int)), this, SLOT(UpdatePanel()) ); //in case the screen resolution changes
+  // Why was this commented out?
+  // Without it, the panel does not redraw reliably when resizing the screen
+  connect(screen, SIGNAL(resized(int)), this, SLOT(UpdatePanel()) ); //in case the screen resolution changes
 }

 LPanel::~LPanel(){

The background still does not resize, but I'm guessing that could be handled similarly. The question is why the connect() handler was disabled in the first place. Was it causing some other kind of problem?

[q5sys]

That was a very old fix for an issue with utilities that would take over the entire screen and/or change resolution. https://github.com/lumina-desktop/lumina/commit/d97499cae8e344af6118f38ffa1c4b183a4d30cc

That may have been us trying to get around a fluxbox bug. There's quite a bit of gnarly hacks we put in place to try to get around fluxbox issues. Getting fluxbox issues patched upstream was pretty much impossible. That was the motivation behind creating a native WM for Lumina. At a certain point it made more sense to start working on something fresh and native than to keep wasting time on Fluxbox issues.

[outpaddling]

I think gnarly hacks are fine for the short-term as long as they're documented as such, e.g.

--- lumina-desktop/LPanel.cpp.orig      2021-12-26 02:33:45 UTC
+++ lumina-desktop/LPanel.cpp
@@ -74,7 +74,10 @@ LPanel::LPanel(QSettings *file, QString scr, int num, 
     //panelArea->setWindowOpacity(1.0); //fully opaque for the widget on top (apply stylesheet transparencies)
   }
   QTimer::singleShot(1,this, SLOT(UpdatePanel()) );
-  //connect(screen, SIGNAL(resized(int)), this, SLOT(UpdatePanel()) ); //in case the screen resolution changes
+  // This apparently should not be necessary, but the main panel does not
+  // redraw reliably without it.  Be sure to fully test resizing a
+  // FreeBSD VirtualBox guest before replacing this.
+  connect(screen, SIGNAL(resized(int)), this, SLOT(UpdatePanel()) ); //in case the screen resolution changes
 }

 LPanel::~LPanel(){

Another hack for redrawing the background would make Lumina usable in vbox guests until a proper solution can replace it. I made a couple failed attempts at hacks in LDesktop.cpp, but I don't really know what I'm doing. Just making half-educated guesses.

This is the last glaring defect from my perspective. If we can fix the background issue, even with a hack, the Lumina desktop will be running pretty clean on FreeBSD and I would be comfortable recommending it universally.

I understand the fluxbox issue. Looks like it hasn't been maintained in about 6 years. It still crashes for me frequently, though Lumina generally restarts it without my even noticing. Only time is causes a problem is during resume from sleep. Then the desktop crashes with it. This is infrequent, though. How complete is the new window manager?

[outpaddling]

Here's my latest pot-shot at a hack for redrawing the background upon screen resize, which does not work. At the risk of beating a dead horse, I'll say again that I don't know what I'm doing WRT QT or Lumina. Some guidance would be appreciated.

--- lumina-desktop/LDesktop.cpp.orig    2022-03-04 16:50:46 UTC
+++ lumina-desktop/LDesktop.cpp
@@ -208,6 +208,8 @@ void LDesktop::InitDesktop(){
   //This is called *once* during the main initialization routines
   checkResolution(); //Adjust the desktop config file first (if necessary)
   if(DEBUG){ qDebug() << "Init Desktop:" << Screen(); }
+    // Same var called screen in LPanel class
+    desktop = LSession::desktop();
     //connect(desktop, SIGNAL(resized(int)), this, SLOT(UpdateGeometry(int)));
     connect(desktop, SIGNAL(resized(int)), this, SLOT(UpdateBackground()));
   if(DEBUG){ qDebug() << "Desktop #"<<Screen()<<" -> "<< QGuiApplication::screens().at(Screen())->availableGeometry() << LSession::handle()->screenGeom(Screen()); }
--- lumina-desktop/LDesktop.h.orig      2022-03-04 16:51:38 UTC
+++ lumina-desktop/LDesktop.h
@@ -62,7 +62,7 @@ public slots:
 private:
        QSettings *settings;
        QTimer *bgtimer;
-       //QDesktopWidget *desktop;
+       QDesktopWidget *desktop;
        QString DPREFIX, screenID;
        //int desktopnumber;
        QRegion availDPArea;

[outpaddling]

An interesting serendipitous discovery: If the background is set to a specific file, it usually redraws after resizing the screen. About 90% of the time based on my brief test. If the background is set to a directory, so it rotates through a list on a timer, then it usually does not redraw, but does maybe 10% of the time and only when enlarging the screen, never when shrinking it. This behavior should provide a clue to someone who understands the event handlers.