Today I scratched an itch I had with and . Every time I run it on my 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) 🤣

Integrate with GNOME Online Accounts Single Framework · Issue #2550 · nextcloud/desktop (GitHub)
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).

In it’s current state Nextcloud is supported and it can read calendar, contacts and documents (as in providing a quick mount option in the file explorer): https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Providers

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 (snap) on 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

When I finally found the cause of this I went on looking for a solution and it seems like the unsung hero @3v1n0 fixed this long standing bug like 8 days ago: https://github.com/ubuntu/gnome-shell-extension-appindicator/commit/745c66a73e0a15a870e92e5aa461e2e9e646b899

Here is a more coherent report on this: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+bug/1849142

Fun thing is: I only have that indicator because Discord would eventually crash without trying to access this.

Now it’s patched and gone – back to 😁

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 server for and this is exactly what the user starts by enabling the screenshare feature. Since 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
 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"

And that’s it. There is no root or sudo involved.

Example output executing the script

Don’t forget to kill the pid when done 🙂