Hello, there is a new PR, which enhances zoom controls. Feel free to test and provide feedback. See PR for more info. Questions are welcome.

I think the console log output ends in the app log file in ~/.cache/upstart

Runned pinging from notebook to phone and while running, runned and trminated pinging from phone to net (ping 8.8.8.8). This was the outcome for first run.

$ ping 192.168.88.250                                                                                                                           
PING 192.168.88.250 (192.168.88.250) 56(84) bytes of data.
64 bytes from 192.168.88.250: icmp_seq=1 ttl=64 time=57.0 ms
64 bytes from 192.168.88.250: icmp_seq=2 ttl=64 time=243 ms
64 bytes from 192.168.88.250: icmp_seq=3 ttl=64 time=98.5 ms
64 bytes from 192.168.88.250: icmp_seq=4 ttl=64 time=119 ms
64 bytes from 192.168.88.250: icmp_seq=5 ttl=64 time=42.0 ms
64 bytes from 192.168.88.250: icmp_seq=6 ttl=64 time=63.1 ms
64 bytes from 192.168.88.250: icmp_seq=7 ttl=64 time=89.4 ms
64 bytes from 192.168.88.250: icmp_seq=8 ttl=64 time=14.2 ms
64 bytes from 192.168.88.250: icmp_seq=9 ttl=64 time=5.66 ms  <-- turned on pinging from phone to net
64 bytes from 192.168.88.250: icmp_seq=10 ttl=64 time=5.52 ms
64 bytes from 192.168.88.250: icmp_seq=11 ttl=64 time=3.06 ms
64 bytes from 192.168.88.250: icmp_seq=12 ttl=64 time=5.70 ms
64 bytes from 192.168.88.250: icmp_seq=13 ttl=64 time=8.30 ms
64 bytes from 192.168.88.250: icmp_seq=14 ttl=64 time=9.16 ms
64 bytes from 192.168.88.250: icmp_seq=15 ttl=64 time=6.26 ms
64 bytes from 192.168.88.250: icmp_seq=16 ttl=64 time=3.13 ms
64 bytes from 192.168.88.250: icmp_seq=17 ttl=64 time=3.09 ms
64 bytes from 192.168.88.250: icmp_seq=18 ttl=64 time=6.24 ms
64 bytes from 192.168.88.250: icmp_seq=19 ttl=64 time=9.07 ms
64 bytes from 192.168.88.250: icmp_seq=20 ttl=64 time=3.10 ms
64 bytes from 192.168.88.250: icmp_seq=21 ttl=64 time=3.06 ms
64 bytes from 192.168.88.250: icmp_seq=22 ttl=64 time=23.3 ms  <-- turned off pinging from phone to net
64 bytes from 192.168.88.250: icmp_seq=23 ttl=64 time=69.1 ms
64 bytes from 192.168.88.250: icmp_seq=24 ttl=64 time=60.9 ms
64 bytes from 192.168.88.250: icmp_seq=25 ttl=64 time=91.4 ms
64 bytes from 192.168.88.250: icmp_seq=26 ttl=64 time=109 ms
64 bytes from 192.168.88.250: icmp_seq=27 ttl=64 time=26.5 ms
64 bytes from 192.168.88.250: icmp_seq=28 ttl=64 time=50.7 ms
64 bytes from 192.168.88.250: icmp_seq=29 ttl=64 time=107 ms
^C
--- 192.168.88.250 ping statistics ---
29 packets transmitted, 29 received, 0% packet loss, time 28038ms
rtt min/avg/max/mdev = 3.065/46.122/243.244/53.585 ms

However, that happened only one time (the first time). Other runs were not that convincing.

ping 192.168.88.250                                                                                                                         130 ↵
PING 192.168.88.250 (192.168.88.250) 56(84) bytes of data.
64 bytes from 192.168.88.250: icmp_seq=1 ttl=64 time=101 ms
64 bytes from 192.168.88.250: icmp_seq=2 ttl=64 time=114 ms
64 bytes from 192.168.88.250: icmp_seq=3 ttl=64 time=377 ms
64 bytes from 192.168.88.250: icmp_seq=4 ttl=64 time=38.5 ms
64 bytes from 192.168.88.250: icmp_seq=5 ttl=64 time=165 ms
64 bytes from 192.168.88.250: icmp_seq=6 ttl=64 time=80.5 ms
64 bytes from 192.168.88.250: icmp_seq=7 ttl=64 time=146 ms
64 bytes from 192.168.88.250: icmp_seq=8 ttl=64 time=36.0 ms
64 bytes from 192.168.88.250: icmp_seq=9 ttl=64 time=6.09 ms
64 bytes from 192.168.88.250: icmp_seq=10 ttl=64 time=94.2 ms <-- turned on pinging from phone to net
64 bytes from 192.168.88.250: icmp_seq=11 ttl=64 time=97.7 ms
64 bytes from 192.168.88.250: icmp_seq=12 ttl=64 time=3675 ms
64 bytes from 192.168.88.250: icmp_seq=13 ttl=64 time=2670 ms
64 bytes from 192.168.88.250: icmp_seq=14 ttl=64 time=1670 ms
64 bytes from 192.168.88.250: icmp_seq=15 ttl=64 time=670 ms
64 bytes from 192.168.88.250: icmp_seq=16 ttl=64 time=58.6 ms
64 bytes from 192.168.88.250: icmp_seq=17 ttl=64 time=51.5 ms
64 bytes from 192.168.88.250: icmp_seq=18 ttl=64 time=54.6 ms
64 bytes from 192.168.88.250: icmp_seq=19 ttl=64 time=80.5 ms  <-- turned off pinging from phone to net
64 bytes from 192.168.88.250: icmp_seq=20 ttl=64 time=148 ms
64 bytes from 192.168.88.250: icmp_seq=21 ttl=64 time=130 ms
64 bytes from 192.168.88.250: icmp_seq=22 ttl=64 time=51.5 ms
64 bytes from 192.168.88.250: icmp_seq=23 ttl=64 time=92.0 ms
64 bytes from 192.168.88.250: icmp_seq=24 ttl=64 time=87.0 ms
64 bytes from 192.168.88.250: icmp_seq=25 ttl=64 time=115 ms
64 bytes from 192.168.88.250: icmp_seq=26 ttl=64 time=49.3 ms
64 bytes from 192.168.88.250: icmp_seq=27 ttl=64 time=64.7 ms
64 bytes from 192.168.88.250: icmp_seq=28 ttl=64 time=114 ms
64 bytes from 192.168.88.250: icmp_seq=29 ttl=64 time=138 ms
64 bytes from 192.168.88.250: icmp_seq=30 ttl=64 time=125 ms
64 bytes from 192.168.88.250: icmp_seq=31 ttl=64 time=179 ms
^C
--- 192.168.88.250 ping statistics ---
31 packets transmitted, 31 received, 0% packet loss, time 30030ms
rtt min/avg/max/mdev = 6.094/370.601/3675.571/804.042 ms, pipe 4

In Slovak, there is no capitalization after colon, except speech, citation or new independent text block begins after colon.

@PhoenixLandPirat I see, people don't want more indicators. Then my proposal is to make a setting that can switch the clipboard manager indicator on/off. Default would be off, so no one would get a new indicator.

@geekvine the link is not working for me either. 404 error. Is the project public?

@PhoenixLandPirat why to squeeze a clipboard manager into OSK? I can imagine it better somewhere in system tray. It also solves the desktop mode problem.

@UniSuperBox said in Continuation of rpi effort and how to test:

@jezek

No. Bespoke ARM images can only be installed to their target devices. Similarly to phone images.

so, it is possible, but there needs to happen some porting magic?

@mariogrip said in Continuation of rpi effort and how to test:

This has been tested on rpi3, but should work on anything newer then 3 (as it needs arm64)

does this mean it can be installed to pinebook? thanks...