Still working the dark blues and grays.

Thank you Glenn! That's very kind of you to say, good to wake up to after working into the wee-hours last night.

I took @deepforest's comments to heart, and decided to offer some alternative artwork that's not so zombie-fied, but still works with the darker theme I use. Started out intending to just do something specifically for Vuu-do Openbox versions, but as usual once I start working with fractals it takes hours and hours and I wind up with several dozen pieces of assorted artwork.

But I did get a piece made that seems to work. it's tough (at least for me) to make things that are coherent using fractals, super-easy to make a bunch of pretty swirls and abstractions, but my goal here was to make something that referred to the term "openbox" in a graphic way. Here's where I am as of late last night, the thumbnail is clickable and takes you to the fullsize version, it's a pure fractal render, only used Gimp for the text and to darken it up some:

Not familiar with OpenOffice, but my wife uses Libreoffice here quite a bit, mostly writer and calc. And it's been flawless in Devuan.

If you're in a hurry that may be a temp solution until you get the OO issue figured out.

Good news for a lot of folks. Mate is pretty far down the list as far as Linux DE popularity, around 2% by most estimates i've seen, but still that works out to over 700,000 users world-wide. It's quite a bit lighter than Gnome or KDE but still gives a good well-rounded DE experience.

Good on older hardware too. And the older folks who I have converted to Linux over the years have overwhelmingly chosen it over other choices i've offered them.

I use it half the time, and Openbox the other half. It runs really well on Devuan, I think if more people tried it they would like it. So it's going to be one of my main focuses now that we are in testing season for new releases in the fall.

Mate's in the same boat as a lot of others, lack of developers and testers, so things take a while. Trying to learn more myself so I can help out better in the future, right now i'm just a user yelling at clouds, lol.

The colors are dark and calming and easy on the eyes, i've done a ton of research into color theory (I used to own a small custom paint contracting business), and I chose the colors for Vuu-do to be easy on the eyes and on the brain as well.

The skulls and the font for wallpaper (Zombified) are just pure whimsy based on the pronunciation of Vuu-do.

I'm a headbanger from waaaay back in the day, so that's some of my influence.

Also a former #! user and that's where I started really liking darker themes and Openbox, and the very first Miyolinux that I tried and based Vuu-do on, also had dark wallpaper and colors. The current Vuu-do wallpaper in fact was originally Miyo wallpaper that I modded, and that's why I still use it, as it has historical and sentimental value to me.

In any case, wallpaper is usually the very first thing people change on any linux distro upon install, so it's a moot point, I set Vuu-do up with very little onboard in the way of themes to start with, as I expect people will want to use their own. The whole thing is set-up to be easily customizable in the MIYO spirit. You'll find notes from me in all kinds of places, explaining how to easily change things.

^^^band-aids man. The update _should_ fix the wound itself.

The errors come from a glib/gio file that was changed at some point, hardcoded in and no way gnome was gonna take it back. So the Mate guys had to patch Caja. But Debian still has the unpatched 1.26.3 version in both trixie and sid, but they are moving 1.26.4 in hopefully soon, there are some other libraries that need to be pushed as well to enable the new version, we may see a lot of new Mate packages come down the pipe.

ETA: Thank you Mike Gabriel at Debian, we do appreciate it!

Well they closed the bug on me already, response indicated they will be pushing the 1.26.4 caja package sometime hopefully sooner than later. As soon as I see it i'll mark this one solved.

"Just delete the file and don't ever turn your machine off" is also not a great answer my friend.

In any case, I don't even blame Mate/Caja for the issue in the first place, as fanderal pointed out earlier this seems like typical gnome-f***ery once again. Break GTK yet again and call it a feature and everybody else has to scramble to figure out fixes and workarounds.

Debian needs to update Mate, they just literally swapped from a working version in bookworm to a broken one in trixie. I'd file a bug report but they pretty much ignored the last one I filed. Filed anyway.

No doubt, that's why i'm messing with it, it's a nasty bug.

And anyway, was hoping we'd be moving up to mate 1.28 or at least 1.27 in Devuan 6.

Thank you Altoid for that link!!!

That is EXACTLY what i'm experiencing, read through that link and others. Basic problem seems to be in Caja. And it's nasty, it will literally build to 100's of mb's if you select and then hover over that file, and pretty much any other file. It really is a critical error because it could build up bad enough unattended to do some damage.

In current daedalus Caja is version 1.26.1 and does not have this issue, in excalibur it's version 1.26.3 which seems to be particularly bad, and documentation seems to say they fixed the issue in 1.26.4 and later.

Need a .deb of Caja 1.26.4 to test....

ETA: Found one at the opensuse build service, testing here shortly.

FYI not only does trixie still have the 1.26.3 package, but so does sid. Pretty far behind...

Doesn't fix the problem but I do have a way to stop the alsa errors at boot, the error claims that it can't find the alsa_restore_go definition in the 90-alsa-restore.rules file in /usr/lib/udev/rules.d/ but, the definition is clearly in that file, seems like a syntax error somewhere.

Workaround to stop boot errors: Create a 90-alsa-restore.rules file in /etc/udev/rules.d/
content:

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $attr{device/number}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $attr{device/number}"

LABEL="alsa_restore_end"

And here's the /usr/lib/udev/rules.d/90-alsa-restore.rules file from excalibur currently if anyone can take a look and maybe see an issue:

# do not edit this file, it will be overwritten on update

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

ENV{ALSA_CARD_NUMBER}="$attr{device/number}"

# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"

# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-pdm-dmic", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"

LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $env{ALSA_CARD_NUMBER}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $env{ALSA_CARD_NUMBER}"

LABEL="alsa_restore_end"