I use simpler solution (measuring by number of taps on the screen): share place from google maps to https://f-droid.org/packages/page.ooooo.geoshare which can convert it to actual latitude/longitude which in turn can be shared to any app working with locations: OsmAnd, Organic Maps, Uber, ...

One part of me likes this solution for being faster and elegant, and I've bookmarked it to be able to recommend to friends. But another part of me is frustrated that so many everyday computer users have little-to-no awareness of basic features like cut/copy/paste on mobile, resulting in another app install as a solution.

Not trying to imply this about you in particular, just griping that the general lack of awareness about how to take advantage of what should be fundamental/foundational OS features means that whole apps get written to, in essence, duplicate those features.

Geo Share is great!

Feels really laggy on desktop. Tried both Firefox and Brave. Like 3-4 FPS

It has really got unreliable in my experience.

Often desktop client just cannot connect to mobile. At first I noticed that this happens when desktop client starts to output in logs these (reported [1]):

  kdeconnect.core: Too many remembered identities, ignoring "<id of KDE Connect on my android device>" received via UDP

Restarting desktop client helped, so I wrote watcher that monitors logs for such lines and restarts kdeconnect. But it turned out to be insufficient. Now I have this script running in background to restart kdeconnectd whenever connection is missing, and finally can use KDE Connect reliably:

  #!/bin/dash -x
  
  
  while sleep 1m; do
      nmcli connection show --active | grep wifi || continue
  
      kdeconnect-cli -l | grep reachable && continue
  
  
  #   notify-send 'No reachable devices via kdeconnect. Restarting'
      systemctl --no-pager --user status [email protected]
      systemctl --no-pager --user stop [email protected]
      killall kdeconnectd
      systemctl --no-pager --user start [email protected]
  
  done

[1] https://bugs.kde.org/show_bug.cgi?id=506563

Uhm is it possible to mitigate second point by publishing encrypted article in social network along with is sending it to the agency to assign it timestamp? Or maybe in any blockchain if one does not like social networks.

Then if journalist does not like how mangled was his piece on publishing he can disclose encryption password to show everyone what he actually wrote in the article?

Using text? How old school! This is not how current generation interacts with computers.

My colleagues frequently send me cli output as screenshots instead of text. They are too accustomed to macOS embedded OCR I presume.

Or how would they share event details on social media. Rarely there is text description, mostly date and time is imprinted on image in Instagram.

It would help if somebody makes a comparison.

Mostly comparison of consumed RAM with identical set of extensions might help me choose without trying each of this projects.

I usually try to optimize for CPU usage more than I do for RAM, mostly because I care about my battery life and for things to remain snappy. Although Vicinae does a lot of caching where it can it probably maintains a quite reasonable memory footprint when compared to apps with web frontends.

IMO after launcher is optimized to be truly idle while there is no interaction with it shaving memory usage becomes more important for snappiness and battery life. Extra RAM that launcher uses it the same RAM that other apps cannot use and therefore become more laggy. I expect on average shaving off 100 MB of launcher RAM usage will save more battery then reducing time for rendering its window by 0.1s

Or after a while without interaction bloated RAM get swapped out and launcher invocation need to fetch swapped out info.

For comparison here is how krunner looks on my current machine. After some time without interactions:

  $ systemctl --user status plasma-krunner.service|head
  ● plasma-krunner.service - KRunner
       Loaded: loaded (/usr/lib/systemd/user/plasma-krunner.service; static)
       Active: active (running) since Sun 2025-08-10 20:31:40 WEST; 1 month 12 days ago
     Main PID: 57749 (krunner)
        Tasks: 37 (limit: 17782)
       Memory: 64.6M (peak: 1.4G swap: 338.2M swap peak: 679.8M zswap: 12.4M)
          CPU: 2h 58.702s
       CGroup: /user.slice/user-1000.slice/[email protected]/background.slice/plasma-krunner.service
               └─57749 /usr/bin/krunner

It seems to me I feel how it was less on the first invocation.

So what should user do before byuing? Reasonably it might search for "<modelname> reviews". Such reviews include a number of throughput tests but they never test for latency.

This might be a culture issue. At least we should push for popular benchmark solutions to include latency tests. In ideal world laptop reviewers should also test keyboard latency but I do not see how it might be automated.

And I encourage anyone who cannot delete their WhatsApp due to personal constraints to set WhatsApp profile picture to QR code with the link to their preferred messenger and set name in profile to "W̶h̶a̶t̶s̶A̶p̶p̶ Telegram".

What if we made crowdsourced database of external links to sources? Like SponsorBlock for skipping sponsored sections in YouTube videos.

Why new blockchain? There are already several of them that provide constant low fees and scaling to ~100k tps on L1.