Gtopo

July 13, 2023

A socket listener protocol for Gtopo

This is motivated by having a file of GPX data from a recent hike and wanting to view (and edit it) in some way.

What I would like to be able to do is to write a program in Kotlin, Python, or whatever and have it send commands to gtopo over a network socket. A pipe could be used, but would be problematic to set up. The first command would probably be to send lat/long coordinates and ask Gtopo to put a marker of some sort (likely just a colored dot) on the map at that location.

Various questions immediately arise. Should a subsequent command add yet another dot, or should it move the first dot. Both behaviors are interesting and useful, so two commands should be provided. Once a protocol is in place, it could be augmented to allow entire tracks to be sent.

On the Gtopo side, the issue will be how to handle this with respect to the GTK event loop. My first idea would be to have a thread to listen (and block) on the socket. That is easy enough and could use Pthreads. When a command is received, it could be posted in some shared memory and some kind of signal sent to inform GTK that a command is waiting for its attention.

A crude but simple way to have GTK recognize a command would be to set up a timer event that watches for a command to appear in shared memory. This would in effect be polling at some rate.

Another question is whether a queue of commands would be required. One would be unless the listener thread did some handshaking with the client to indicate when a command was finished and it was ready for more commands.

Some links to think about some fine day:

The Gtopo source

According to my notes I last worked on Gtopo in 2021 (2 years ago). The executable I am now running was built in March of 2021. My sources are in /u1/Projects/Topo/gtopo/src

I have some cleaning up to do relative to my github repository. My origin is a non-existant repository on an observatory computer. The remote for github is "github" and I would like to change that to "origin".

/u1/Projects/Topo/gtopo
git help remote
git remote remove origin
git remote rename github origin

This is all tidy and clean, so the first order of business is to be sure that my working copy of the sources compiles clean:

cd src
make clean ; make

I get a warning about use of strncat in gpx.c that I fix and it compiles clean. I am still using gtk2. If I had nothing better to do, I might take on the task of converting this to gtk3, but why? It works fine as it is.

I currently do have a timer being run by gtk. It fires every 500 milliseconds and calls my "cursor" function to blink my little "+" cursor at map center.

Add some code

I am going to try to keep all of the code to handle this in a new file "remote.c". I create this file, add two stub functions, calls to them in gtopo.c and I add that file to the Makefile. We compile clean.

It turns out that the code I need is in overlay.c, which I put together 2 years ago to display GPX tracks. It also can display waypoints, so I can use the existing waypoint code to do what I want.

I don't need to do anything special to link in pthread libraries (much to my surprise). Getting the header file boilerplate for the TCP stuff is a pain, as usual.

I select port 5555 and a "telnet localhost 5555" lets me do testing.
I will try this for my first test. I paste the following line into telnet and ....

M -110.870457273 31.692344025

And it works! Just that line with "M" for mark does the job. The info from my GPS was:


        2211.200
        2023-07-12T20:40:30Z
        0.120000

By the end of the day, I have this working and a python script communicating with it.

More ideas

The current protocol processes a new command every 500 ms and only one command per connection. This is not adequate for "animation", so:

Let the client close the connection
Check for new values at 100 ms rather than 500.
Be sure we really are ready for new data when we send OK
Augment the protocol to include centering

The idea with centering is this. Currently coordinates that are not on the display are simply not displayed. If we center the display, it would act like most GPS displays when tracking motion, it will keep the mark in the center and move the rest of the display. In fact if we had this feature and some kind of GPS device sending positions over this new protocol, it would work in just this way.

So I am going to allow "C" for center and "M" for mark. Or both together as center and mark, i.e.

M -110.870457273 31.692344025

The logic to center is already in place (and is used by the current places file. Worth considering is that now an external GUI could handle a places file, perhaps in a fancier way.

Feedback? Questions? Drop me a line!

Gtopo / [email protected]