So I got a stuck #Evolution from time to time. No mailbox or calendar would load and Evolution eventually claim that it can’t connect to the accounts. Turns out this is quite literal. I’m on #GNOME and that has a framework for single sign-ins called GNOME Online Accounts or GOA for short (that thing I wish the Nextcloud client would USE too).
Apparently this happens _sometimes_ after standby/suspend, that I use quite often to save on power, so it was really hard to find. Looks like the goa-daemon gets stuck on resume. There is nothing in the journal or so.
Anyway, it can be restarted quite easily by executing `/usr/libexec/goa-daemon --replace` manually. So basically what happens on login. The effect on Evolution is instant. Yay, ~~spam~~mails again!
Now that’s dope. #Gnome / gnome-shell-extensions comes with a watermark extension that can be tweaked 😲 – it usually shows the dist logo but can show any image.
gsettings set org.gnome.mutter workspaces-only-on-primary false and suddenly virtual workspaces on #gnome become pure awesomeness on a 🖥️🖥️🖥️ setup 🤘
Today I scratched an itch I had with #Gnome and #vscode. Every time I run it on my #Linux PC I have to drag around the window until it fills my 3 displays setup. It’s tricky because it’s a grown installation and the displays have different resolutions.
Gnome has smart borders auto-sizing windows when you come close to a border. Usually that’s awesome but in this case it’s not. wmctrl to my rescue!
Find out about current window position when satisfied: wmctrl -G -l -x
Use that information for a one liner script: wmctrl -x -r code.Code -e 0,0,109,5276,1136
This will do until I get a 4k display or learn how to auto-run this snippet on the launch of vscode (like I do this with RisingWorld to force semi borderless fullscreen) 🤣
GNOME has a feature for managing online accounts in one place ( GnomeOnlineAccounts | GOA). In it's current state Nextcloud is supported and it can read calendar, contacts and documents (as in ...
GNOME has a feature for managing online accounts in one place ( GnomeOnlineAccounts | GOA).
This way account credentials can be shared and are configured and managed in one place where they can be requested by an application. The communication is done via D-Bus.
Currently I have to configure my accounts in two places, the nextcloud-client and in GOA, to get a Nextcloud server tightly integrated into my system and while the passwords end up in the same place (gnome-keyring) it’d be more user friendly to share this from a common ground instead of having to configure this twice for each Nextcloud account.
There’s a weird issue with #Discord (snap) on #Gnome that starts when using voice chat causing really bad lag and short freezes (input, rendering, everything) that became worse over time. My journal filled up with looping messages from appindicator causing this.
appindicatorsupport(at)rgcjonas.gmail.com[2514]: discord1, Impossible to lookup icon for 'discord1_12-panel'
Followed by a JS exception and trace:
JS ERROR: Exception in callback for signal: icon: Error: Argument 'filename' (type filename) may not be null
Today I had to access my computer via VNC. There are several manuals how to enable VNC on a typical Linux desktop nowadays. It usually involves some sort of clicking on Sharing => Enable Screenshare and you’re done. It’s really that easy.
How would I do this however remote when I can not access my already running desktop computer via VNC? SSH is enabled on my machines since most of my work involves jumping and tunneling my way through various networks to get stuff done. Just forwarding X was not enough today.
Turns out this is really easy as well. The screensharing feature on my distribution is done with Vino. That’s an integrated #VNC server for #gnome and this is exactly what the user starts by enabling the screenshare feature. Since #Vino is part of gnome it can be configured using gsettings.
So after enabling the screenshare for testing on my laptop I tested for all existing keys by running this listing:
gsettings list-recursively | grep Vino
It’s really short and basically all settings are no-brainers. Only the password had me wondering but it turned out this is just base64 encoded (and also optional). All that is left is running the vino-server binary in the end. This needs the correct environment variable $DISPLAY set since our target is a running X session. This one we can determine by executing the command w and looking for the TTY in use. Hint: It’s :1 in this case.
beko ~ w
20:35:15 up 5:12, 1 user, load average: 1,92, 2,33, 2,37
USER TTY LOGIN@ IDLE JCPU PCPU WHAT
beko :1 15:24 ?xdm? 2:02m 0.00s /usr/libexec/gdm-x-session --run-script /usr/bin/gnome-session
Oh and you should also not connect with the X11 forward option -X because running the vino-server with this will result in some really funny endless picture in picture mode that I did totally not try out by mistake 😉
Now that I had all the information I needed I hacked together this little script that does this more or less automatically so I can forget about this again [and look it up two years later in my own blog]. It’s really crude and your mileage may vary. It does not account for multiple users or multiple running X Sessions:
export DISPLAY=$(w -oush | grep -Eo ' :[0-9]+' | uniq | cut -d \ -f 2)
echo "Display is $DISPLAY"
gsettings set org.gnome.Vino require-encryption true
gsettings set org.gnome.Vino use-alternative-port false
gsettings set org.gnome.Vino disable-background false
gsettings set org.gnome.Vino alternative-port 5900
gsettings set org.gnome.Vino icon-visibility 'client'
gsettings set org.gnome.Vino disable-xdamage false
gsettings set org.gnome.Vino authentication-methods "['vnc']"
gsettings set org.gnome.Vino prompt-enabled false
gsettings set org.gnome.Vino require-encryption true
#pw is just base64 so basically just echo -n 'awesomeness'| base64
gsettings set org.gnome.Vino vnc-password "YXdlc29tZW5lc3M="
gsettings set org.gnome.Vino view-only false
/usr/libexec/vino-server &
export VINOPID=$!
echo "Try vnc://$HOSTNAME:5900/"
echo "vino-server pid may be $VINOPID"
Jomik