Window management change between F37 and F38 (observed on Silverblue).
I use many applications in a maximized window. Under F37 I could close those applications and when next opened they would assume their previously maximized state. After updating to F38 some of these applications don’t open maximized but open as a smaller, centered, window. This is changed behaviour from F37 and earlier.
I had some issues with mutter-x11-frames segfaulting (which has been fixed) and the ChangeLog for mutter makes mention of a “centering patch”. Could mis-operation of this patch be causing what I’m seeing?
Not yet known.
Bugzilla report: #NNNN
Can you provide a specific scenario someone could attempt to reproduce the issue? Is this happening randomly, or systematically with specific applications? Could you indicate whether you use Wayland or Xorg?
In some cases, you see an effect of a maximized window reopening in a maximized state because of a settting “auto-maximize”. Check your current setting with the command
gsettings get org.gnome.mutter auto-maximize
I am using the default Wayland Session (confirmed by Settings|About)
gsettings get org.gnome.mutter auto-maximize returns true. Changing this to false has no effect on the issue.
A number of flatpak applications, installed from flathub, which used to retain their maximized state between close and re-open under F37 but not F38 are:
org.kicad.KiCad - Standalone Schematic and PCB editors
I note that freeCAD is one of those flatpak apps you have this issue with.
Have you tried the rpm version of freeCAD from fedora? If it does not show the same behavior as the flatpak version then this might be related to the flatpak runtimes in use for those apps.
I use the freeCAD rpm version with x11 and have not seen the behavior you describe. I use the rpm version of slic3r and not the PrusaSlicer so cannot compare there, though slic3r also does not exhibit the described behavior.
Just as a thought – have you tried to see if the behavior is the same with both wayland and xorg?
It may be a quirk between the flatpak and wayland that might not exist with xorg.
I’m using Silverblue so you don’t install applications from RPM - flatpak is the install medium.
I raised this issue because this is newly introduced behaviour with F38 Beta. F37 and previous versions didn’t exhibit this.
If someone can confirm that all the aforementioned applications can maintain a maximized state over exit and restart on fedora 38 Workstation I’m prepared to accept that fedora 38 Silverblue final may address the issue.
From my perspective, I have tried these applications on fedora Silverblue 38 Beta and there is a discrepancy with the behaviour on previous versions. It would be a shame though if undesirable behaviour results after release because no investigation was made.
As I understand it you normally use the flatpak, but rpm-ostree certainly does allow installing rpm versions.
Thanks for the update on the apparent regression. It still seems likely that it is related to a runtime that may not match the current packages on the newer version of fedora so reporting it would be appropriate.
One thing to be aware of is that this forum is not always the correct place to report problems with a beta version. The developers have their own location for receiving reports of problems. Unfortunately, since I do not do beta testing I don’t happen to have that information handy.
You certainly can install RPMs on Silverblue but it’s recommended that doing so is limited. Large applications with significant numbers of dependencies are, sensibly, to be avoided.
I agree that this medium probably isn’t the best place for Beta-related issues but the fedora 38 Beta announcement on fedoramagazine actually directs people here or onto the fedora-qa IRC/Matrix channel.
I’ve been going through the aberrant applications vs. the correctly performing ones and there are a mix of GTK and Qt ones on both sides.
I don’t suspect a flatpak runtime issue because that’s the general point of flatpak in that older applications continue to run on newer systems due to the availability of the associated runtime.
This suggests, to me, it’s a graphical environment issue related to changes associated with F38. The same applications and runtimes operated correctly under F37 after all.
This is why I suggested comparing the results with wayland vs xorg.
Wayland or Xorg, the result is the same.
The RPM version was a good question, I just tried FreeCAD both from FlatHub and Fedora RPM and while the Fedora RPM is working as expected in this regard the FlatHub version exhibits the described behavior. This was tested using an update to date as of this writing Fedora 38 Beta Workstation installation.
Note that fedora tests the rpm packages. I think most of the flatpaks are not packaged nor tested by fedora.
Glad you can see a better solution.
I’m not sure I would call it a solution especially for a SilverBlue user, overlaying FreeCAD for instance would be less than ideal. I don’t personally use any of the apps listed, however I did observe similar behavior with another app on Fedora 38 which is why I was willing to test the Fedora RPM vs FlatHub theory.
Remember that at this time fedora 38 is still in Beta. It seems quite reasonable to expect flatpaks to lag behind in being repackaged (or maybe even to be tested) on an OS that has not yet been released.
It is probable that the flatpak packagers will test and adjust their products to work on F38 as soon as it is stable.
That’s not the way flatpaks work. They are an ecosystem of applications and runtimes. They persist over operating system releases. If a flatpak doesn’t execute on a particular release of a Linux distribution then it’s a case of the OS being at fault.
Without knowing a bit more about what the underlying issue is it’s hard to assess “fault”.
Especially since this isn’t even remotely about something as severe as an application “not executing”, it’s about a relatively minor (though quite annoying, I’m sure) behavioral quirk. The flatpak runtime could most certainly be at fault, perhaps it was relying on buggy behavior in Mutter that’s since been fixed. (That’s a tale as old as time, TBH.) Assigning blame isn’t really an especially productive part of the troubleshooting process.
This is a long shot, @neildarlow, but the GNOME “Tweaks” tool has a switch in its Window configuration,
Center new windows. Looks like it controls another flag right next to
auto-maximize in the
center-new-windows. You could see if that has any effect on this. Perhaps… I dunno, maybe it’s overriding the default-maximization state for some apps? (Like I said, long shot.)
If you don’t have Tweaks installed, the equivalent commands are
# to display the current value
gsettings get org.gnome.mutter center-new-windows
# to set a value
gsettings set org.gnome.mutter center-new-windows [true|false]
Something else to test with the setting “auto-maximize” se to true. Open FreeCAD. Drag the window corners to make the window as large as possible. Do not “maximize”, i.e., window should be large, but not in the maximized state. Close the application. Reopen: chance is high that now the application is maximized.
This has been fixed in mutter-44.2-2.fc38.x86_64.