[Feature idea] Map in the terminal

[varna9000]

I've been experimenting a bit with showing a static node map in the terminal. It seems it's possible entirely with python and with the help of libsixel. I'm using iTerm on MacOS which supports sixel protocol, and which is quite old btw. Not sure what others are using and if their terminals support sixel.

So I used static map generator - py-staticmaps to generate the image below by manually adding node names and their coordinates.

The idea is to collect a dynamic in-memory array of all node names and their coordinates and if the user presses, say ^m, the image will be generated on the fly and will be shown "full-screen". I guess it could be made to zoom in and out, as the generation is quite quick, but it will require further research.

The map generator uses various providers APIs to get the map tiles, so in case you want to use it offline, you need to figure out how to pre-download the tiles and generate the map. I haven't got that deep tbh and if it can be done without modifying py-staticmaps at all.

I experimented also with converting the image into ASCII, but the map is unrecognisable 😁 Any thoughts on the idea?

EDIT: This is a list of the sixel supported terminals. Not sure how up-to-date it is, but it's a starting point.

[varna9000]

Ok, I have implemented the map in my fork, although it might have some bugs. You can show the map with Ctrl-u

You need to have libsixel installed on your system e.g. sudo apt install libsixel or brew install libsixel

The most obvious bug is that the map is visible until:

1. a key is pressed OR
2. a payload update arrives, which brings back the main panels

I'm no curses expert and I couldn't find a way to stop refreshing the screen until key is pressed.

NOTE: Since the pip package of py-staticmaps is old and uses old pillow version (9.0.0) with breaking changes, I've added the git repo, so that the latest code of py-staticmaps is pulled form there.

[pdxlocations]

This looks really cool, though one of the project goals is to keep it compatible with all systems. Currently the only required library is meshtastic.

[varna9000]

That is fine. I thought it's a cool idea to have some visuals in the terminal, as big part of the Meshtastic fun is to see where the others are.

[pdxlocations]

I agree! I'm not opposed to visuals. It would be fun to have something like https://github.com/stephane-deraco/Termchart for metrics as mentioned in #184 . I just want to make sure we can run without complications on devices like an RPi and LuckFox. Maybe there's a lo-fi/retro mapping option?

[varna9000]

The only option I found, which looks really good is MapSCII, but it's javascript and requires nodejs. Sadly, I couldn't find anything that good in Python.

[pdxlocations]

I'd also be totally fine with a modules/plugins folder with options that are disabled by default. We could move scripts from a disabled folder to an enabled folder which is scanned at startup like how this one works: https://github.com/Murturtle/MeshLinkBeta

[pdxlocations]

Doesn't necessarily have to be a folder either. Could be an enabled-modules.ini or something. Totally open to other ideas.

[varna9000]

I need to wrap my head around curses loop a bit more, because it would definitely influence the design of the plugins. For example now we have the hotkeys in ui/contact_ui.py, but for a new plugin hotkey, we need to "inject" it into that loop too.

[pdxlocations]

Thinking out loud: instead of a file or folder, we could have list or dictionary that contains enabled modules, the we could check for if "map" in modules: or something before importing additional libraries and when checking for ctrl-m. A dictionary could be nice because it could also contain configs for each module.

[varna9000]

Yes, that would be the right pythonic way. I've seen other project doing it in similar way. They have config.py with all the initial global variables/settings, which is then included into main.py. I think there will be some shuffling of modules to get this plugin system working.

If the plugin requires visualization of data, would it create a new window, or just hide/show as the payload log pane? I think the current setup is ergonomic - 3+1 panes. But an option for a full screen plugin would be nice as well e.g. for the map or for plotting some stats with ascii.

[pdxlocations]

FYI there is a new single_pane_mode available in the app settings, in case you haven't seen that. It currently requires a relaunch.

For modules I suppose it would depend on the visuals but full screen sounds like the way. OR we could navigate to the map using the arrows: Channels -> Chat -> Nodes -> Map (full screen) -> Channels

[O-Ilpa]

I really don't know what's happening, but I'm happy to help

[varna9000]

FYI there is a new single_pane_mode available in the app settings, in case you haven't seen that. It currently requires a relaunch.

hm, I haven't seen it but will have a look.

For modules I suppose it would depend on the visuals but full screen sounds like the way. OR we could navigate to the map using the arrows: Channels -> Chat -> Nodes -> Map (full screen) -> Channels

Cycling seems reasonable, but if you have more than one plugin enabled, would that be just queued e.g. Nodes -> Fullscreen map ->Fullscreen graphs -> Channels ?

[O-Ilpa]

I've been asked to contribute to GitHub projects in order to gain experience, I'm a 16-year-old self-taught full stack developer, but I really don't know where to start, anyway here is my resume https://drive.google.com/file/d/1ttaXqyAOgU2IPNxLoiSZGZEqRr9m7xkt/view

[pdxlocations]

Cycling seems reasonable, but if you have more than one plugin enabled, would that be just queued e.g. Nodes -> Fullscreen map ->Fullscreen graphs -> Channels ?

Would need some thinking and experimentation. Each module may have it's own design requirements. I haven't looked at your fork to be honest. Starting simple by checking for modules and using ctrl-m to bring up a full-screen map window might be the first course of action. I'm using ui_state.current_window = 4: to announce we have the settings dialogue displayed. Adding more active windows may require some refactor there.