Page 11 of 18
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 2:48 pm
by Stevo
This is a screenshot of VBox 6.0.14 with the Kvantum theme--kvantum manager using KvDarkRed modified by me.
if you then change the theme in Kvantum Manager, Vbox follows it after a restart: KvBlender:
KvYaru:
KvCyan:
The light themes still seem to result in glaring white, but at least you can read the text, and some of the other colored themes are quite nice, IMO. I would say there's also a good chance this would work in Manjaro.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 3:29 pm
by Stevo
Tested a Live Session, installing VBox and qt-style-kvantum from the test repos. VBox looked OK with the default light theme, but fonts became almost impossible to read when I switched to a dark xfce theme. The Kvantum style worked out of the box, though, as well as using different Kvantum themes via Kvantum Manager--no need for KDE.
I don't see why this shouldn't also work on MX 18 with VBox 6.X.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 3:34 pm
by richb
I guess I do not know how to use the Kvantum Manager. I load a Kvantum theme from /usr/shar/themes for example kvantum and it gives an error "Not a kvantum theme". Seems like a simple enough thing to do.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 3:58 pm
by Stevo
richb wrote: Mon Oct 28, 2019 3:34 pm
I guess I do not know how to use the Kvantum Manager. I load a Kvantum theme from /usr/shar/themes for example kvantum and it gives an error "Not a kvantum theme". Seems like a simple enough thing to do.
It should have also pulled in qt5-style-kvantum-themes if you installed the test repo version--the Buster version may only have that as a recommended package, and didn't install it. Then in the manager, you hit "change/delete theme", and those should show up in a drop-down listbox "Select a Theme" when that section expands. You pick a new theme, then hit the "use this theme" button, and it should change to that theme.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 5:22 pm
by Stevo
Another issue and my hacky solution:
Wi-fi often stopped working after resuming from suspend or hibernation in the same area, even though network-manager showed the laptop still connected to the same network. Disconnecting and reconnecting to the same network gets it working again, but it is annoying.
Previously, I was using
this fix in the wiki, but it didn't work in MX 19, even when I changed the driver to the new one for MX 19, from "iwlwifi" to "iwlmvm". In fact, the wiki method broke hibernation--the machine just got to 4% and then locked up.
Unloading and reloading the driver manually resulted in a disconnect and reconnect, as I wanted, so I put a scriptlet named "wifi-fix" in usr/local/bin:
Code: Select all
#!/bin/sh
rmmod iwlmvm
sleep 1
modprobe iwlmvm
and then noticed touchpad-indicator, which we have installed by default, installs
/etc/pm/sleep.d/00_check_touchpad_status, so I added my scriptlet to it:
Code: Select all
#!/bin/sh
#copy to /etc/pm/sleep.d
LOGFILE="/var/log/sleep.log"
case "$1" in
resume|thaw)
echo "Resumed normal from suspend at `date`" >> "$LOGFILE"
/usr/bin/python3 /opt/extras.ubuntu.com/touchpad-indicator/share/touchpad-indicator/check_touchpad_status.py resume
/usr/local/bin/wifi-fix
echo "Touchpad enabled"
;;
esac
and that works to quickly unload and reload the driver after a resume. I assume that editing the original touchpad-indicator file, but saving it as another file, something like "30_wi-fi_fix_after_resume", with the touchpad-indicator parts removed will also work, along with just putting the rmmod and modprobe commands directly in that file, but haven't tested that. Maybe one of our scripting gurus can help with that.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 6:05 pm
by dolphin_oracle
that should work. usually those *.d directories grab everything in alphanumeric sequence, so numbers are good.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 6:20 pm
by Stevo
dolphin_oracle wrote: Mon Oct 28, 2019 6:05 pm
that should work. usually those *.d directories grab everything in alphanumeric sequence, so numbers are good.
I'm guessing the lines before and after the one that runs my script can be removed, then, and maybe the call to the script just replaced by the rmmod and modprobe commands.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 6:22 pm
by dolphin_oracle
yep, you shouldn't need them in the new script, although you might want your own echo statement.
Re: MX-19 Feedback
Posted: Mon Oct 28, 2019 10:44 pm
by asqwerth
Stevo wrote: Mon Oct 28, 2019 3:29 pm
Test a Live Session, installing VBox and qt-style-kvantum from the test repos. VBox looked OK with the default light theme, but fonts became almost impossible to read when I switched to a dark xfce theme. The Kvantum style worked out of the box, though, as well as using different Kvantum themes via Kvantum Manager--no need for KDE.
I don't see why this shouldn't also work on MX 18 with VBox 6.X.
Aha! Thanks. Now I know why newer Manjaro xfce releases have kvantum by default. I noticed it in a previous VM test of a newer iso.
My own real metal Manjaro installs pre-date kvantum, I think.
Re: MX-19 Feedback
Posted: Tue Oct 29, 2019 10:13 am
by Jerry3904
I have installed MX-19 on my production machine now, and am extremely happy with the result.
One question: I have an Nvidia card that is not being used:
Code: Select all
Graphics: Device-1: NVIDIA GF119 [GeForce GT 610] vendor: eVga.com. driver: nouveau v: kernel
bus ID: 01:00.0 chip ID: 10de:104a
Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa
resolution: 2048x1152~60Hz
OpenGL: renderer: NVD9 v: 4.3 Mesa 18.3.6 direct render: Yes
Everything seems fine on the monitor, but I do wonder whether there is any reason to consider switching to the NV card.