A post was split to a new topic: Night Light isn’t working anymore
Using i3wm.
Before all windows just had a 3 pixel border, without the title bar.
After the update (this or the previous one, I’ve skipped the last one), some windows (not all) now have an unwanted title bar.
How to get back the previous behaviour, i.e. to force windows to not have a title bar?
EDIT: I think this might be the bug: `default_border pixel` doesn't hide title bars after upgrading to 4.21 · Issue #5149 · i3/i3 · GitHub
Just discovered that OBS 28.0.3 from the official repos is core dumping as well.
1 Like
Problems open files from samba share in dolphin, get cant create a lock file.
When i add a remote service in Libreoffice i can open, change and save files.
I just noticed that LibreOffice Writer starts Minimised, and I have to manually select Maximise from the right mouse menu on App Icon in the task bar.
This happens with all the LibreOffice Apps… If they are started Maximised. which seems to be the default.
when they are started Maximised they appear to be starting with the --invisible flag set.
It is possible to gain access to the window, by specifically setting window to Maximised, using the right mouse context menu from the app icon, or by selecting the Resize option from the same menu.
if the Window is set to a size smaller than Maximised, the Window opens normally, at that size.
Ina ddition, at least on my system the LibreOffice start Centre starts as a panel, with just a list of the various app options, opening any of the appswill then also open with the same width.
I’m looking at whether this is some sort of config issue.
1 Like
7.4.2 is out in Arch repositories, I think Manjaro should push this version asap because it fixes a major problem.
I upgraded LibreOffice to 7.4.2 using downgrade with A.L.A. enabled. I confirm that the bug is gone, but the old 0-sized window was still remembered by LibreOffice. I followed this procedure:
- Open LibreOffice
- Maximize the window, by right-clicking on the button on the Panel (i.e., application bar)
- Grab the window by its title bar, and drop it to one side edge of the screen, so that it resizes to half the screen (apparently the window disappears, but drag the mouse pointer to the screen edge nevertheless)
- Manually resize the window by dragging one of its borders
It would be nice to find a way to reset window size automatically, e.g. during the update process by pacman.
It is a known bug of LibreOffice 7.4.1, solved in LibreOffice 7.4.2 (already in Arch repositories). You can read my previous post.
1 Like
Hello, after the update qas mixer doesn’t work anymore.
> Cannot mix incompatible Qt library (5.15.5) with this library (5.15.6)
> Abgebrochen (Speicherabzug geschrieben)
Does anyone have an idea how i can fix it?
Thanks in advance! 
Ok, I find the solution:
> pamac build qt5-styleplugins
now qasmixer is running again.
Thanks. No worries. I missed your previous post on this.
BTW: the setting for the Window size is stored in ~/.config/libreoffice/4/user/registrymodifications.xcu and the variable is
:name=“ooSetupFactoryWindowAttributes” oor:op=“fuse”>0,0,1,1;5;0,0,0,0;
which holds the above values when the Bug is present. Resetting that value manually to for example
:name=“ooSetupFactoryWindowAttributes” oor:op=“fuse”>0,0,1366,746;5;0,0,0,0;
lasts for one iteration, it is reset to the bug values when the window is closed.
Quite interesting really.
4 Likes
I’m having the same issue and it came with the last update of libreoffice.
My workaround is opening an empty document and, instead of “maximize”, grabbing the minimized window and resizing it. Then close libreoffice.
And afterwards it starts with the resized Window. On KDE that is.
Great discovery. There is such an <item> element for each LibreOffice program (Writer, Calc etc.), and luckily they are located in independent lines. Apparently, these items can be safely removed: next time LibreOffice starts maximized, and can be unmaximized to a visible window (at least in LO 7.4.2).
Shall we create an upgrade script that removes these items automatically?
I’m using KDE, but resizing last for only 1 iteration, after that it resets to 0,0,1,1,… etc
Yeah, that’s right one of those lines for each LibreOffice app. A script might be useful 'til 7.4.2 arrives.
2 Likes
Strange, here it keeps the values of manually resizing for any start.
But anyway as @lallulli wrote this is already fixed for the next version.
I have a script that works for me on a KDE desktop.
#!/bin/bash
grep -v "ooSetupFactoryWindowAttributes" registrymodifications.xcu > tmpfile && mv tmpfile registrymodifications.xcu
if [[ $1 == "" ]]
then
libreoffice &
else
libreoffice --$1 &
fi
I named the script clearwindowsettings.sh, it’s currently in the ~/.config/libreoffice/4/userfolder
I just replaced the menu command with
~/.config/libreoffice/4/user/clearwindowsettings.sh <libreoffice app name>
I passed in no parm for the LO Start Centre
So now until 7.4.2 is available my LO apps load properly.
3 Likes
With the update to gtkhash + gtkhash-nemo v1.5-1 [→ stable update 2022-10-05] the digest/checksum tab disappeared from the file properties, as I only noticed today.
Since four different Manjaro Cinnamon machines in my sphere are affected by this, it seems to be a systematic issue.
Downgrading to v1.4-6 fixes the problem for now.
Fixed with 1.5-2 coming along shortly.
Over the past few days I have had a particularly confusing problem with Manjaro upgrades in which, every time I update, several programs stop working, complaining about locale problems. I am aware of the usual solutions to locale problems but none that I used were of any use in solving the problem. I therefore used timeshift to restore to a working system and then tried to figure out what had changed. It wasn’t easy, but I finally got to the solution. All upgrades to glibc (in my case 2.36.4 to 2.36.6) are deleting and not replacing the file ‘usr/lib/locale/locale-archive’. On my system multiple programs stop functioning without that file. My workround was to make a copy of the file with a different name, then update glibc and then rename the copy back to the original name. I don’t know if this behaviour is by design or mistake, but it needs to be addressed in either case.
I couldn’t find anything online about this relating to Manjaro, but this Fedora page describes the problem in detail although the solutions are obviously Fedora related as well and not relevant to Manjaro:
BTW I am travelling at the moment and may not be able to reply to this post for a while due unreliable internet connections.
A small change to my script, so that documents can be selected and opened direct from the filesystem.
if [[ $1 == "" ]]
then
libreoffice &
else
libreoffice --${1+"$@"} &
fi