Skip to content

feat: add LXMF type definitions#21

Open
torlando-tech wants to merge 1 commit intoattermann:masterfrom
torlando-tech:feat/lxmf
Open

feat: add LXMF type definitions#21
torlando-tech wants to merge 1 commit intoattermann:masterfrom
torlando-tech:feat/lxmf

Conversation

@torlando-tech
Copy link

Add type definitions for LXMF.

This was originally written by Claude Opus 4.5. I went through to review manually against the Python source code. The only difference I noticed is phrasing in the comments/docstrings.

I have not double checked that all of the types are correctly sized, but did spot check TICKET_INTERVAL requires 17 bits at least.

If you'd prefer larger PRs over numerous small ones, let me know and I will hold off until I have reviewed everything in my branch.

@DanBeard
Copy link

Question for attermann or the broader community: Would we want lxmf features in the microreticulum repo? or should it mirror the python and be a different repo? (and if so, then who will make that repo?) I'm working on LXMF with microreticulum for my rDeck and the LXMF logic is mixed in with the chat application layer, but I could go either way honestly.

@torlando-tech
Copy link
Author

Question for attermann or the broader community: Would we want lxmf features in the microreticulum repo? or should it mirror the python and be a different repo? (and if so, then who will make that repo?) I'm working on LXMF with microreticulum for my rDeck and the LXMF logic is mixed in with the chat application layer, but I could go either way honestly.

Atterman asked if I could submit a PR for the (working but not stress tested) LXMF implementation I'd made for my (functional but unstable) t-deck firmware.

I personally lean towards a separate package/library at the very least, but I do not have a background in C++ and thus am not familiar with industry norms for repo+package/library alignment. Either way, it's not a position I feel strongly about. Whatever makes it easier to adopt and use.

@attermann
Copy link
Owner

I'm still on the fence myself. I want to keep hardware-specific code out of the main microReticulum codebase for sure, but LXMF doesn't fall under that category. Hosting it in a separate repo adds more maintenance overhead, but does keep things cleaner.

Give me a bit to review your PR @torlando-tech and I'll get back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants