I was finally able to get mate-base 1.20.3 to compile from ports. It was problematic, and this is a bit off topic, but, briefly, and in case anyone's interested, to make it compile successfully, I had to compile the dependency ports graphics/cairo and net/samba47 first and second, using
make install clean
. This was apparently because those two ports need to use python27 before it gets upgraded to python36 by the other ports. Then, thirdly, I compiled mate-base using
make DISABLE_VULNERABILITIES=yes install clean
, because of vulnerabilities in graphics/openjpeg which would cause the compile to abort otherwise. Finally, I compiled x11/xorg with
make install clean
. And it works. I'm sure there are other ways of doing it, but this worked for me. For comparisons, I also installed approximately the same things using packages on another partition of the same machine, except that version has mate-base version 1.20.0 instead of 1.20.3 because of the differences between available packages and ports.
Oddly, the compiled-from-ports 1.20.3 version shows the same problem with gtop you reported, whereas the control version of mate-base 1.20.0 I installed from packages does not. I don't know exactly why this is so, and otherwise they appear to be identical. I would have guessed it would have been the other way around.
To summarize from the postings above, my main reason for compiling mate-base from ports was to try to eliminate the lag-time in dragging windows, which I've long experienced, and which Quarter Wave Vertical also reported. This unfortunately did not work, and I still have the same lag time latency problem that I had experienced on the installed-from-packages version. Fooey. Ah whell.
About your problem with discovering and mounting USB drives, I had sort of forgotten some of this, but going through the compiler options reminded me, and, as I understand it, because the HAL Hardware Abstraction Layer (i.e.,
hald_enable="YES"
) is deprecated in FreeBSD, these versions of Mate have a default option selection to use devd instead of hald for device discovery. Some people use autofs as a workaround for this, but I've opted to use sysutils/automount instead. Briefly, all you should need to do to get device discovery to work properly is
pkg install automount
. Then, from the root account, copy
/usr/local/etc/automount.conf.sample to
/usr/local/etc/automount.conf and use your favorite text editor to change the setting for USER in
automount.conf to whatever the name of your non-root account happens to be. After a reboot, the system should then be able to automatically mount any USB stick you insert and automatically open the file manager for you. You can then use the caja file manager or the command prompt to copy files with read/write privileges to and from the USB stick, and also you'll be able to unmount the drive from caja or from the non-root user's command prompt using the
umount
command. I tried this using the hald daemon alone, and it did not work for me. I have thus disabled hald in this and in all of my other desktop configurations in FreeBSD, and only use devd and sysutils/automount for device discovery and automount needs.
I like kde5 and wouldn't discourage anyone from trying it. It's a bit more flexible, IIRC, with regards to being able to use either hald or devd plus automount for device discovery and automounting. I still used automount instead of hald on kde5, but you might prefer to just use hald instead, and, if I'm not mistaken, it will remain your choice on kde5, but only for as long as hald is still being supported therein. HAL has been deprecated for several years, and is reportedly no longer being upgraded, but is still being used and maintained, so who knows when, if ever, it will actually ever go away completely.
Thanks & best regards.
Edited to add: In
automount.conf I also changed:
Code:
ENCODING=pl_PL.ISO8859-2
CODEPAGE=cp852
to