GNOME | Technology Tales

Mouse configuration in macOS

24^th August 2024

Now having a new location from which I can work, I acquired an all-in-one desktop computer for use while there. While tempted by an HP option that runs Windows, I ended up choosing an iMac instead. That gained me extra disk space and more memory at a cost. Having UNIX-style command line capability was another attraction. After living with the Windows terminal for a while, its limitations were all too apparent to me.

While I started off desktop computing on a Macintosh Classic and having owned a MacBook Pro in the more recent past, there still was a learning curve. One of these related to the configuration of the mouse supplied with the system. Whatever about only having one button and needing to learn gestures, it was the speed at which the pointer goes that really got me reaching for my more usual Evoluent. Even so, the subsequent discovery of LinearMouse makes things much more bearable once all the requisite permissions were assigned.

Getting the Evoluent configured to my liking needed another third-party application: USB Overdrive. If Evoluent's own software fitted the bill, that would have done. However, they have done some finger pointing at Apple instead of updating it to work with the latest Mac technology. There may be truth in the accusations, but it is striking that another piece of software works when theirs does not. Nevertheless, the other option worked once it got the permissions to detect the hardware. Then, it was a matter of working out which button was which on the mouse, so I could have them assigned as I wished.

After that, I could settle into the new system and get used to its idiosyncrasies. Adding Parallels got me a Windows 11 virtual machine for business compatibility, while I got going with setting up some automation using the macOS terminal. All is becoming more settled than working out of a laptop.

Needing third-party software does have a catch, though: underlying changes to macOS could scupper things. It was the sort of thing that made me move away from GNOME Shell as my Linux desktop. The extensions on which I was depending kept getting obsoleted by every new release. It is something to watch, even if macOS evolves less dramatic than GNOME 3 in its various forms.

Restoring the menu bar on GNOME Terminal in a GNOME Shell session

25^th July 2020

By default, a GNOME Terminal instance does not display a menu bar and that applies not only in GNOME Shell but also on the Cinnamon Desktop environment. In the latter, it is easy enough to display the menu bar using the context menu produced by right-clicking in the window before going to Edit > Preferences and ticking the box for Show menubar by default in new terminals in the General section. After closing the Preferences dialogue, every new GNOME Terminal session will show the menu bar.

Unfortunately, it is not so easy in GNOME Shell, though the context menu route does allow you to unhide the menu bar on a temporary basis. That is because the requisite tick box is missing from the Preferences dialogue box displayed after navigating to Edit > Preferences in the menus. To address, you need to execute the following command in a terminal session:

gsettings set org.gnome.Terminal.Legacy.Settings headerbar false

This change permanently adds the menu bar and includes the previously missing tick box, which is selected when necessary. Although GNOME Shell has a minimalist design in some aspects, making this function difficult to access seems excessive.

Removing obsolete libraries from Flatpak

1^st February 2020

Along with various pieces of software, Flatpak also installs KDE and GNOME libraries needed to support them. However, it does not always remove obsolete versions of those libraries whenever software gets updated. One result is that messages regarding obsolete versions of GNOME may be issued and this has been known to cause confusion because there is the GNOME instance that is part of a Linux distro like Ubuntu and using Flatpak adds another one for its software packages to use. My use of Linux Mint may lessen the chances of misunderstanding.

Thankfully, executing a single command will remove any obsolete Flatpak libraries so the messages no longer appear and there then is no need to touch your actual Linux installation. This then is the command that sorted it for me:
flatpak uninstall --unused && sudo flatpak repair

The first part that removes any unused libraries is run as a normal user, so there is no error in the above command. Administrative privileges are needed for the second section that does any repairs that are needed. It might be better if Flatpak did all this for you using the update command, but that is not how the thing works. At least, there is a quick way to address this state of affairs and there might be some good reasons for having things work as they do.

Turning off Apport crash reporting on Ubuntu

6^th April 2015

Last week, I kept getting a multitude of messages from Ubuntu's crash reporting tool, Apport. So many would appear at once on reaching the desktop session during system start-up that I actually downloaded an installation ISO disk image intending to perform a fresh installation to rid myself of the problem. In the end, it never came to that because another remedy produced the result that I needed.

Emptying /etc/crash was a start, but it did not do what I needed, and I disabled Apport altogether. This meant editing its configuration file, which is named apport and is found in /etc/default/. The following command should open it up in Gedit on supplying your password:

gksudo gedit /etc/default/apport

With the file opened, look for the line with enabled=1 and change this to enabled=0. Once that is done, restart Apport as follows:

sudo restart apport

This will need your account password before working, with any messages appearing afterwards. While I would not have done this for a real system problem, my Ubuntu GNOME installation was working smoothly, so it was the remedy I needed. The tool lets Ubuntu developers get information about application crashes, but it sends me to the Ubuntu Launchpad bug reporting website, which requires login details. This is enough to stop me continuing, making me wonder if developers could get what they need without this extra manual step. This would provide them with additional information and give us a more stable operating system in return.

Automatically enabling your network connection at startup on CentOS 7

15^th August 2014

CentOS 7's release sparked my curiosity, so I tried it in a VirtualBox virtual machine. It uses GNOME Shell in classic mode, making it feel similar to GNOME 2. One thing to note is that it requires at least VirtualBox version 4.3.14, or the Guest Additions kernel drivers won't compile. This might seem surprising when you learn it uses kernel version 3.10.x and GNOME Shell 3.8.4. Like Debian production releases, CentOS chooses established versions for stability, fitting its enterprise-focused user base. Despite this conservative approach, it still looks good, though trying to change the desktop background froze the machine. Otherwise, most things work well.

However, there are surprises, including one I noticed: network connectivity needed switching on every time the VM started. This occurs with the default installation and has been a known issue since at least CentOS 6. It's not difficult to fix once you know how.

What you need to do is look for the relevant configuration file in /etc/sysconfig/network-scripts/ and update that. Using the ifconfig command, I found that the name of the network interface. Usually, this is something like eth0, but it was enp0s3 in my case, so I had to look for a file named ifcfg-enp0s3 and edit that. The text that is sought is ONBOOT=no and that needs to become ONBOOT=yes for network connections to start automatically. To do something similar from the command line, CentOS had suggested the following:

sed -i -e 's@^ONBOOT="no@ONBOOT="yes@' ifcfg-enp0s3

This uses sed for an inline (and case-insensitive) edit of the file to change 'no' to 'yes' after accessing the /etc/sysconfig/network-scripts/ directory. I edited manually with Gedit, which also works. Note that file editing needs superuser privileges, so switch to root with the su command or use sudo.

Suppressing Update Notifier messages in Ubuntu GNOME 14.04

18^th July 2014

Even though I use only the command line for system updates, I still received system restart messages after kernel updates. Though these can be helpful, I prefer to restart my system on my own schedule, especially when running processes I don't want to interrupt.

In Ubuntu GNOME 13.10 and earlier, these messages didn't appear. I wanted to return to a notification-free experience. The Update Notifier application causes these messages, but removing it significantly impacts the system, making that approach impractical.

The application starts automatically at boot but doesn't appear in Startup Applications Preferences (launched via gnome-session-properties). This is because the NoDisplay flag in its autostart shortcut located in /etc/xdg/autostart/ is set to true. To make it visible, you need to set this flag to false.

The following command will reveal all hidden startup applications (note that the command is split across two lines for display purposes, and you may need to adjust quotes when executing it):

sudo sed -i 's/NoDisplay=true/NoDisplay=false/g' /etc/xdg/autostart/*.desktop

The sed command changes NoDisplay=true to NoDisplay=false in all desktop files, revealing hidden entries in Startup Applications Preferences. This allows you to disable the Update Notifier. While deleting the desktop file would be more permanent, this solution works well as it stops restart notifications. Since I regularly update my system and shut down daily, updates are applied automatically, and everything functions properly.

Fixing Background Image Display in GNOME Shell 3.10

2^nd May 2014

On upgrading from Ubuntu GNOME 13.10 to Ubuntu GNOME 14.04, a few rough edges were to be noticed. One was the display of my chosen background image: it was garbled. Later, I discovered that there is a maximum width of 2560 px for background images in GNOME Shell these days and that things get messy beyond that.

In my case, the image width was around 6000 px, and I was used to it getting resized in GNOME Shell 3.8 and its predecessors. It appears that the functionality got removed after that though, so the workaround of manual image resizing in the GIMP needed to be employed. Though having big images open in memory creates an additional overhead, not handling them very well at all looks like a bug caused by setting 2560 px as a maximum screen width for the GNOME Shell panel and the complete removal of Nautilus from desktop rendering duties. Let's hope that sense is seen with ever larger screen sizes and resolutions coming our way.

It's the sort of thing that did get me looking at adding on Cinnamon 2.2 for a while before setting background image scaling using the indispensable GNOME Tweak Tool was discovered. LinuxG.net has a useful tutorial on this for anyone with such an adventurous streak in them. For now though, I am OK with my set-up but the GNOME project's focus on minimalism could affect us in other ways, so I can see why Clem Lefebvre started the Cinnamon one primarily for Linux Mint and the desktop environment is appearing elsewhere too. After all, Gedit lost its menu bar in GNOME 3.12 so it's just as well that we have alternatives.

Update 2014-05-06: It appears that the desktop image bug that afflicts GNOME Shell 3.10 got sorted for GNOME Shell 3.12. At least, that is the impression that an Antergos instance in a VirtualBox virtual machine gives me.

ERROR: Can't find the archive-keyring

10^th April 2014

When I recently did my usual system update for the stable version Ubuntu GNOME, there were some updates pertaining to apt and the process failed when I executed the following command:

sudo apt-get upgrade

Usefully, some messages were issued and here's a flavour:

Setting up apt (0.9.9.1~ubuntu3.1) ... ERROR: Can't find the archive-keyring Is the ubuntu-keyring package installed? dpkg: error processing apt (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: apt E: Sub-process /usr/bin/dpkg returned an error code (1)

Web searches indicated the issue was missing files in /usr/share/keyring, which I didn't delete. Since apt was disabled due to the missing keyring files, installing software for fixes was impossible. My solution was to copy the /usr/share/keyring files from an Ubuntu GNOME 14.04 virtual machine to the same location on my Ubuntu GNOME 13.10 host. For others without this setup, I've included these files in a zip file below. While other solutions like Y PPA were mentioned, they required prior installation, making them useless when tools like Synaptic were unavailable. I'd appreciate information on other fixes that don't involve reinstalling the operating system, potential causes for the file loss, and how to prevent it.

Ubuntu Keyrings

Installing FreeBSD in a VirtualBox Virtual Machine

2^nd March 2014

With UNIX being the basis of Linux, I have a soft spot for trying out any UNIX that can be installed on a PC. For a while, I had OpenSolaris on the go and even vaguely recall having a look at one of the BSD's. However, any recent attempt to install one of the latter, and there are quite a few around now, got stymied by some sort of kernel panic caused by using AMD CPU's. With the return to the Intel fold arising from the upgrade of my main home PC last year, it perhaps was time to try again.

The recent release of FreeBSD 10.0 was the cue and I downloaded a DVD image for a test installation in a VirtualBox virtual machine with 4 GB of memory and a 32 GB virtual hard drive attached (expanding storage was chosen so not all the allocated space has been taken so far). The variant of FreeBSD chosen was the 64-bit x86 one, and I set to installing it in there. Though not as pretty in appearance as those in various Linux distros, the installer was not that user unfriendly to me. Mind you, I have experience of installing Arch Linux, which might have acclimatised me somewhat.

Those installation screens ask about the keyboard mapping that you want, and I successfully chose one of the UK options. There was limited opportunity for adding extras, though there was a short list of a few from which I made some selections. Given that user account set up also was on offer, I would have been better off knowing what groups to assign for my personal user account to have to avoid needing to log in as root so often following system start up later. Otherwise, all the default options were sufficient.

When the installation process was complete, it was time to boot into the new system and all that was on offer was a command line log in session. After logging in as root, it was time to press pkg into service to get a desktop environment in place. The first step was to install X:

pkg install xorg

Then, it was time to install a desktop environment. While using XFCE or KDE were alternatives, I chose GNOME 2 due to familiarity and more extensive instructions on the corresponding FreeBSD handbook page. Issuing the following command added GNOME and all its helper applications:

pkg install gnome2

So that GNOME starts up at the next reboot, some extra steps are needed. The first of these is to add the following line into /etc/fstab:

proc /proc procfs rw 0 0

Then, two lines were needed in /etc/rc.conf:

gdm_enable="YES" gnome_enable="YES"

The first enables the GNOME display manager, while the second activates other GNOME programs that are needed for a desktop session to start. With each of these in place, I got a graphical login screen at the next boot time.

With FreeBSD being a VirtualBox Guest, it was time to consult the relevant FreeBSD manual page. Here, there are sections for a number of virtual machine tools, so a search was needed to find the one for VirtualBox. VirtualBox support for FreeBSD is incomplete in that there is no installation media for BSD systems, while Linux and Solaris are supported along with Windows. Therefore, it is over to the FreeBSD repositories for the required software:

pkg install virtualbox-ose-additions

Aside from the virtual machine session not capturing and releasing the mouse pointer automatically, that did everything that was needed, even if it was the open source edition of the drivers and their proprietary equivalents. To resolve the mouse pointer issue, I needed to temporarily disable the GNOME desktop session in /etc/rc.conf to drop to a console only session where xorg.conf could be generated using the following commands:

Xorg -configure cp xorg.conf.new /etc/xorg.conf

In the new xorg.conf file, the mouse section needs to be as follows:

Section "InputDevice" Identifier "Mouse0" Driver "vboxmouse" EndSection

If it doesn't look like the above, and it wasn't the case for me, then it needs changing. Also, any extra lines from the default set up also need removing, or the mouse will not function as it should. The ALT+F1 (for accessing GNOME menus) and ALT+F2 (for running commands) keyboard shortcuts then become crucial when your mouse is not working as it should and could avert a panic too; knowing that adjusting a single configuration file will resolve a problem when doing so is less accessible is not a good feeling as I discovered to my own cost. The graphics settings were fine by default, but here's what you should have in case it isn't for you:

Section "Device" ### Available Driver options are:- ### Values: <i>: integer, <f>: float, <bool>: "True"/"False", ### <string>: "String", <freq>: "<f> Hz/kHz/MHz" ### [arg]: arg optional Identifier "Card0" Driver "vboxvideo" VendorName "InnoTek Systemberatung GmbH" BoardName "VirtualBox Graphics Adapter" BusID "PCI:0:2:0" EndSection

The next step is to ensure that your HAL settings are as they should. I needed to create a file in /usr/local/etc/hal/fdi/policy called 90-vboxguest.fdi that contains the following:

<?xml version="1.0" encoding="utf-8"?>  <deviceinfo version="0.2"> <device> <match key="info.subsystem" string="pci"> <match key="info.product" string="VirtualBox guest Service"> <append key="info.capabilities" type="strlist">input</append> <append key="info.capabilities" type="strlist">input.mouse</append> <merge key="input.x11_driver" type="string">vboxmouse</merge> <merge key="input.device" type="string">/dev/vboxguest</merge> </match> </match> </device> </deviceinfo>

With all that set, it is time to ensure that the custom user account is added to the wheel and operator groups using this command:

pw user mod [user name] -G wheel operator

Executing the above as root means that the custom account can run the su command so that logging in as root at the start of a desktop session no longer is needed. That is what being in the wheel group allows, so anyone in the operator group can shut down or restart the system. Since both are facilities readily available on Linux, so I fancied having them in FreeBSD too.

Being able to switch to root in a terminal session meant that I could go on to add software like Firefox, LibreOffice, GIMP, EMACS, Geany, NetBeans, Banshee and so on. Though there may be a line of opinion that FreeBSD is a server operating system, all of these make it more than passable for serving as a desktop one too. There may be no package management GUI as such and the ones that come with GNOME do not work either, yet anyone familiar with command line working will get around that.

While FreeBSD may be conservative, that has its place too, and being able to build up a system one item at a time teaches far more than getting everything already sorted in one hit. So far, there is enough documentation to get me going, leaving me to see where else things go too. So far, the OS hasn't been that intimidating, which is good to see.

A fallback method of installing Nightingale in Linux

3^rd December 2013

When I upgraded to Ubuntu GNOME 13.10 and went for the 64-bit variant, I tried a previously tried and tested approach for installing Nightingale that used a PPA, only for it not to work. At that point, the repository had not caught up with the latest Ubuntu release (it has by the time of writing) and other pre-compiled packages would not work either. However, there was one further possibility left, and that was downloading a copy of the source code and compiling that. My previous experiences of doing that kind of thing have not been universally positive, so it was not my first choice, but I gave it a go anyway.

To get the source code, I first needed to install Git so I could take a copy from the version controlled repository and the following command added the tool and all its dependencies:

sudo apt-get install git autoconf g++ libgtk2.0-dev libdbus-glib-1-dev libtag1-dev libgstreamer-plugins-base0.10-dev zip unzip

With that lot installed, it was time to check out a copy of the latest source code, and I went with the following:

git clone https://github.com/nightingale-media-player/nightingale-hacking.git

The next step was to go into the nightingale-hacking sub-folder and issue the following command:

./build.sh

That should produce a subdirectory named nightingale that contains the compiled executable files. If this exists, it can be copied into /opt. If not, then create a folder named nightingale under /opt using copy the files from ~/nightingale-hacking/compiled/dist into that location. Ubuntu GNOME 13.10 comes with GNOME Shell 3.8, the next step took a little fiddling before it was sorted: adding an icon to the application menu or dashboard. This involved adding a file called nightingale.desktop in /usr/share/applications/ with the following contents:

[Desktop Entry] Name=Nightingale Comment=Play music TryExec=/opt/nightingale/nightingale Exec=/opt/nightingale/nightingale Icon=/usr/share/pixmaps/nightingale.xpm Type=Application X-GNOME-DocPath=nightingale/index.html X-GNOME-Bugzilla-Bugzilla=Nightingale X-GNOME-Bugzilla-Product=nightingale X-GNOME-Bugzilla-Component=BugBuddyBugs X-GNOME-Bugzilla-Version=1.1.2 Categories=GNOME;Audio;Music;Player;AudioVideo; StartupNotify=true OnlyShowIn=GNOME;Unity; Keywords=Run; Actions=New X-Ubuntu-Gettext-Domain=nightingale

[Desktop Action New] Name=Nightingale Exec=/opt/nightingale/nightingale OnlyShowIn=Unity

It was created from a copy of another *.desktop file and the categories in there together with the link to the icon were as important as the title and took a little tinkering before all was in place. Also, you may find that /opt/nightingale/chrome/icons/default/default.xpm needs to be become /usr/share/pixmaps/nightingale.xpm using the cp command before your new menu entry gains an icon to go with it. While the steps that I describe here worked for me, there is more information on the Nightingale wiki if you need it.

« Older Entries «