Master Feature: Centralized 'rgbmatrix' command-line interface (CLI)

1

Feature: Centralized ‘rgbmatrix’ command-line interface (CLI)

Hello there, I have some extra free time over the holidays and I’m looking to develop a feature that I think this project needs. I make heavy use of this architecture in my own personal project, but I’m looking to abstract away the generalized pattern into the rgbmatrix library. This can make it universally available for all users, as well as to promote the use of a single CLI layer that hides internal implementation details.

Thankfully I’ve already done what I consider to be a good majority of this work, but I’m looking to collect requirements before submitting a polished version. What I want to avoid personally is submitting my pull-request of a final version, but receiving a lot of critique in the PR stage. Then having to continually refactor and getting caught up in back-and-forth dialogue.

So in the spirit of efficiency and time-preservation, I’d like to submit an overall high-level idea of this feature and collect feedback from other developers to help unify the vision of a CLI that works for everybody.

But before I do so, I’d like to first address potential concerns beforehand:

Maintenance Burden:

Having something like this it can be argued it is extra fluff that can become a maintenance burden on the few existing developers/maintainers of this project. While I commit to be responsible for this feature of the codebase, I’d like to mention that a lot of repetitive and common issues submitted by newbies & stuck users looking for help can be reduced with a simplified and automated command interface.

If someone is stuck on an error in their terminal, this interface should provide tools to output the state of their environment/system and potential corrective actions. It should scan and handle these potential error-points with clear messaging that can shift the burden of help back onto the user themselves into a form of self-sufficiency. It should gracefully handle and guide them simply what is wrong and what command to run next as opposed to an uncontrolled massive dump of errors that prompt them to outreach for somebody to untangle. This potentially comes from missing system packages, bash scripts, libraries and dependencies which can be verbose and overwhelming. By separating things into domains of concern, we can add automated repeatable commands and guardrails that address them.

Feature Creep:

While I accept this library is just a driver for led matrices at its core, the users of this project typically use it in the context of a wider personal LED project they are working on with a Raspberry Pi IoT device. It would be beneficial to bundle common generalized tooling that serves the majority of the users. This can expand adoption while also reducing repetitive outreach to project maintainers; with everyone having the ultimate goal of an LED display in working order.

I’ll now describe the vision for the implementation below:

Concept of Views

A view described below is a display program. It’s written in C++, C# or Python. In the context of using this command interface, all views will be referenced by filename only. There is no concept of directories. The CLI is intelligent enough to scan directories to find the executable view. It searches the library folders (utils, examples, bindings) and optional directories provided in an environment variable (RGBMATRIX_DIR_VIEW=/home/pi/led-project/view). That allows you to plugin your own view executables so the CLI can find them.

Command Architecture

rgbmatrix is the top-level namespace / bash executable. Each of the children below it are domains. They house commands related to their domain of concern.

rgbmatrix
	view
	assert
	build
	cache
	cpu
	debug
	depend
	env
	flag
	gpu
	help
	install
	os
	perm
	python
	service
	sound
	status
	test
	uninstall
	update
	vendor
	__cleanup # cleanup handler
	__dispatch # command-dispatcher
	__main # entry-point

Usage Examples:

Note: If you prefer to skip right to the pseudo-implementation details instead of CLI usage, scroll past this.

# view
rgbmatrix view assert <view> # assert a view is in workable condition before execution
rgbmatrix view exists <view> # scan and check a view exists
rgbmatrix view build <view> # build (compile/link) an individual view
rgbmatrix view hook <view> # run external bash script hooks on event lifecycle (boot, build, start, stop)
rgbmatrix view start <view> # start a view
rgbmatrix view stop # kill all running rgbmatrix/view processes in daemon or interactive mode

# assertions
rgbmatrix assert root-user
rgbmatrix assert env-dev

# build (compile/link stages)
rgbmatrix build all
rgbmatrix build led-image-viewer
rgbmatrix build my-custom-view # in .env file, define RGBMATRIX_DIR_VIEW=/home/pi/my-led-project/view

# data/file caching for view programs
rgbmatrix cache set-ram # pipe data to /tmp folder (RAM store cleared on OS reboot)
rgbmatrix cache set-fs # pipe data to cache/ folder (Permanent filesystem store)

# cpu (perform rpi-rgb-led-matrix tweaks relating to the CPU)
rgbmatrix cpu isolate # set isolcpus=3 in /boot/firmware/cmdline.txt

# debugging info
rgbmatrix debug # output debugging info

# environment variables and setup
rgbmatrix env init # export .env environment variables for view programs

# flag (build common repetitive flags for view programs from a central config)
# Ex: --led-cols=64 --led-rows=32
rgbmatrix flag <view> # outputs full command-line flags to append to view program

# gpu (perform actions on the Broadcom VideoCore GPU)
rgbmatrix gpu

# help
rgbmatrix help

# install
rgbmatrix install # perform project-wide installation and conditionally python/c# installs

# os
rgbmatrix os # Run related commands on the underlying OS required by the rpi-rgb-led-matrix library

# perm
rgbmatrix perm # handle common permission-based issues (chmod/chown)

# python
rgbmatrix python # run common python actions
rgbmatrix python -v # get current python version
rgbmatrix python venv # handle setup of python virtual environment
# will be nice to convert this project from os-based python to python virtual environment.

# service (custom OS systemd services - you want to run your views as an automated service)
rgbmatrix service start 
rgbmatrix service stop
rgbmatrix service restart
rgbmatrix service reload

# sound
rgbmatrix sound onboard-disable # disable onboard 'snd_bcm2835' module
rgbmatrix sound onboard-enable # enable onboard 'snd_bcm2835' module
rgbmatrix sound onboard-check # output debug info on dtparam=audio status

# status
rgbmatrix status # Output name/status of current running view process in daemon or interactive mode

# test
rgbmatrix test # run all bash test suites in test/ directory
rgbmatrix test unit # run all bash unit tests in test/ directory
rgbmatrix test e2e # run all bash e2e tests in test/ directory

# uninstall
rgbmatrix uninstall # run system-wide uninstall and return OS to pre-installation state

# update
rgbmatrix update # update resources

# vendor
rgbmatrix vendor install # download and extract all external vendor packages to a project folder

Pseudo-code Implementation (Rough draft template):

# Domain functions
rgbmatrix::view() {
	case "$1"
		assert)
			# Run and confirm assumptions for a view before attempting to execute it
		;;
		exists)
			# Scan all known directories and output successful exit code if view exists
		;;
		build)
			# Compile & link an individual view program (C++/C# only, not needed for Python)
		;;
		hook)
			# Run any individual bash hook scripts before executing the main view program
			# Useful for preparing content for your view before running it
			# This seperates the domain of data-fetching from the primary rendering responsibility of the view
		;;
		start)
			# Execution path in this routine:
			# - assert # Confirm assumptions (root-user, permissions, directories exist)
			# - stop # Stop all existing processes
			# - env init # Init environment variables for view program
			# - cache init # Init cache directories for writing
			# - build <view> # Build the individual view program
			# - flag all # Generate all command-line arguments for the view program
			# - *determine execution pathway* (C++, C#, Python?)
			# - view hook # Run all bash hooks for the program
			# - execute view program by its "filename.ext" identifier (no directories)
			# 	- spawn child process for the view program
			# 	- scan all known directories:
			# 	- utils/
			# 	- examples-api-use/
			# 	- bindings/c#/examples
			# 	- bindings/python/samples
			# 	- User-supplied .env ENV variable (Ex: RGBMATRIX_DIR_VIEW=/home/pi/my-led-project/views)
			# - *monitor process* # Monitor state of process/PID and restart if failed or exited
		;;
		stop)
			# Identify a view program by its name or process ID (PID) and kill it
			# Normally in daemon mode, or if you have a leaky process that accidentally went chaotic.
		;;
	esac
}
rgbmatrix::assert() {
	case "$1" in
		root-dir)
			# Confirm the current working directory is from the rpi-rgb-led-matrix root folder
		;;
		root-user)
			# Confirm whether we are in root permissions
			# Some commands can be ran without root, so we don't want to force it
			# But for running view programs we want to conditionally assert for root user
		;;
		env-dev)
			# Assert whether we are operating in `RGBMATRIX_ENV=dev` mode
		;;
		env-prod)
			# Assert whether we are operating in `RGBMATRIX_ENV=prod` mode
		;;
		exists)
			view_name="$2"
			# Scan all known directories where view programs live and check whether a view exists there
		;;
	esac
}
rgbmatrix::build() {
	case "$1" in
		all)
			make all
		;;
		dev)
			make dev
		;;
		prod)
			make prod
		;;
		view)
			view_name="$2"
			view_dir="..." # Scan known directories for view programs and run their Makefiles if C++
			make -C "$view-dir"
		;;
	esac
}
rgbmatrix::cache() {
	case "$1" in
		init)
			mkdir -p "/tmp/rgbmatrix.cache"
		;;
		set-ram)
			# Write temporary cache file to /tmp system folder
			# Stored in RAM, gets cleared on OS reboot
		;;
		set-fs)
			# Write permanent file to hard disk / SD card
		;;
		get)
			# Fetch cache item by "filename.ext" ID
			# Scan known cache directories and output file contents
		;;
		clear)
			# Wipe caches clean
		;;
	esac
}
rgbmatrix::cpu() {
	case "$1" in
		isolate)
			sed -i -e "s/ isolcpus=[^ ]*//g" -e "s/\$/ isolcpus=3/" "/boot/firmware/cmdline.txt"
		;;
	esac
}
rgbmatrix::debug() {
	# Perform debugging actions
	# Scan/enable logging
}
rgbmatrix::depend() {
	case "$1" in 
		install)
			# Install base OS package dependencies
			# Conditionally install Python package dependencies
			# Conditionally install C# dependencies
		;;
	esac
}
rgbmatrix::env() {
	# Parse ".env" file in project root directory
	# export environment variables for use in view programs
	# EX: "export RGBMATRIX_DIR_FONT=fonts RGBMATRIX_DIR_CACHE=/tmp RGBMATRIX_DEBUG=1"
	# - Use RGBMATRIX_DIR_FONT instead of hardcoded references to directories
	# - Use RGBMATRIX_DIR_CACHE in view programs to locate where to write cache files
	# - Use RGBMATRIX_DEBUG to conditionally log debug statements
}
rgbmatrix::flag() {
	# Read config file "manifest.yaml"
	# Assemble command-line string of flags for the given view program
	# EX (when running): rgbmatrix.sh view led-image-viewer
	# This function will output the repetitive runtime flags "--led-gpio-mapping=regular --led-cols=64 --led-rows-32"
	# As well as sensible/common default flags for the requested view program
	# EX: -C -f rpi-rgb-led-matrix/fonts (font dirs)
	# The common defaults for each view program can be mapped in manifest.yaml for what you prefer
	# The goal here is to eliminate repetition having to type out command flags, you store the common ones in a config
	# And each view program has a central config to list its default params
	# You can also add/override input params at the end of your CLI command and it will be appended with the generated ones
}
rgbmatrix::gpu() {
	# Perform actions on the Broadcom VideoCore GPU
}
rgbmatrix::help() {
	# Output command-line usage and help
}
rgbmatrix::install() {
	# Run system-wide uninstallation and return OS to state it was in prior to rgbmatrix install
}
rgbmatrix::os() {
	# Run related commands on the underlying OS required by the rpi-rgb-led-matrix library
}
rgbmatrix::perm() {
	# Handle common permission-based issues (chmod/chown)
}
rgbmatrix::python() {
	# Run common python actions including
	# - virtual environment
	# - install
	# - build
	# - version-check
	# - package/dependency installation
}
rgbmatrix::service() {
	# Run commands relating to OS systemd services (install, start, stop, restart, reload)
}
rgbmatrix::sound() {
	case "$1" in
		onboard-disable)
			printf "blacklist snd_bcm2835" >> "/etc/modprobe.d/blacklist-rgbmatrix.conf"
		;;
		onboard-enable)
			if [[ -f "/etc/modprobe.d/blacklist-rgbmatrix.conf" ]]; then
				sed -i "s/blacklist snd_bcm2835//g" "/etc/modprobe.d/blacklist-rgbmatrix.conf"
			fi
		;;
		onboard-check)
			# Output debug info on dtparam=audio status
		;;
		sound-check)
			# Probably not needed. But can pulse-check test audio through external or onboard sound device
		;;
	esac
	
}
rgbmatrix::status() {
	# Output name/status of the current running view if it is in daemon mode
}
rgbmatrix::test() {
	case "$1" in
		unit)
			# run unit test in test/ folder
		;;
		e2e)
			# Spawn a process of a view program in a subshell and verify that its stdout content is working as expected
			# This way utils, demos & user-generated view programs can be tested programattically without human intervention
		;;
	esac
}
rgbmatrix::uninstall() {
	# Run system-wide uninstallation and return OS to state it was in prior to rgbmatrix install
}
rgbmatrix::update() {
	# Run git pull, or other update routines from a remote server
}
rgbmatrix::vendor() {
	# If you have any external vendor libraries or external sources you want to include
	# You can supply a "vendor" key-value mapping in the manifest.yaml file that downloads and extracts them there
}
# Cleanup handler
rgbmatrix::__cleanup() {
	# When the main script terminates by interupt or script error
	# Append a log of the line_number, command, exit_code to error.log in project directory
}
# Dispatcher (command router)
rgbmatrix::__dispatch() {
	domain="$1"
	cmd_args=""${@:2}"

	domain_list="assert build cpu debug depend env flag gpu help install os perm python service sound test uninstall update view"

	# Redirect bad domain calls to help domain
	if [[ -z "$domain" ]]; then rgbmatrix::help; return; fi

	# Route command
	if contains_word "$domain_list" "$domain"; then
		domain_sig="rgbmatrix::$domain"
		$domain_sig $cmd_args
	fi
	printf "Unknown command: $domain"
	rgbmatrix::help

}
# Main (entry point)
rgbmatrix::__main() {
	# Entry point
	# Includes
	# Run assertions
	rgbmatrix::__dispatch "@"
}
rgbmatrix::__main() "$@"

Thanks for your time and patience reading this and I welcome any suggestions and feedback!

3

Hello, sorry to bring this up, but wouldn’t this add too much complexity? I think creating a side project or separate repository that uses the current one as its API might be a better idea. Since this project essentially provides an API to develop your own code, the complexity of building a complete application here could be exponential, and the current cli tool is only here for fast testing purpose. It seems the current maintainers are already short on time for existing issues and progress.

4

I like the idea and would certainly consider using it for my project.

One problem I am having with my project at the moment is that I have no C# API equivalent of the led-image-viewer util. There’s the PlayGif example app, but it’s still an app not a library, and it does not support streams. I did have a go at repackaging it using AI, but have not yet succeeded.

So as an alternative, my app currently just launches the led-image-viewer util as a sub-process. However, if my app crashes, it can leave an orphaned led-image-viewer process still running.

The solution of course is some wrapper utility which launches my process and monitors child processes that it launches, and if my app crashes, it automatically kills the orphaned child process.

I wonder if the best place for such a mechanism would be inside your project? Do you think this is a common thing that people would want to do? Not saying that I necessarily am asking you to write it, just wondering if this makes sense as a component in your project

5

Thanks for the feedback. I feel the command interface is well scoped here and not an exponential complexity.

I also consider this bash utility already completed and in stable working mode in my own project. And once it’s written it’s done. As long as things don’t significantly change in the library from here on out it shouldn’t need much maintenance. As I’ve been using it in my own project for the last 4-5 years, it’s a culmination of the pain-points I’ve identified working with this library. I’ve generalized away a lot of the areas and slimmed it down as much as possible.

With that said, I don’t feel great about starting a separate repo because I don’t feel it will gain any traction that way.

That feature would be included in the rgbmatrix view start <view> command. The bash utility spawns view process and handles/manages it. If you want a professional-like quality to dealing with LED displays instead of hacking them together - Bash integration is a must.

6

Okay, I have a better understanding now. Since you have implemented it in your own project, you already have the experience and have paved the way. However, there is still a lot of work to be done. If you have the time, I say go ahead with the PR and let’s see.

It might make first tests of the library easier, but regarding the use of the API itself, I’m not sure if it really changes anything. for @evilC i think the core problem is that he cannot use the C# API, and as I understand your proposal, he would still need to write C# against a specific API.

I’m mostly skeptical about the view part, as it introduces an opinionated way to interface with the library. If you stop maintaining it, it just adds another layer of complexity. Perhaps I haven’t fully understood the concept, so I might need further explanation.

As for the other commands, I don’t think they are necessary. The real issue for my project right now is the difficulty of installing the library for Python. With better documentation and a smoother process (like pip install), it should be quick and easy to handle. I feel that trying to centralize everything will create more problems and make it much harder to maintain than before, but of course, that’s just my personal opinion.

If it solves a real problem for users, it will. But, if it is too niche, i don’t know if integrating all of this functionalities could be viable.

1 Like
7

If I understood the following statement correctly…

I would not. From my understanding a “view” is just an application (C# executable, python script etc). His bash script launches my C# app, and my C# app executes the led-image-viewer executable utility (that is part of the hzeller repo) in order to show stuff. The image-viewer subprocess (If, for example, called with the -f flag to force it to show an image/animation forever) would normally persist if my app crashed.

In this instance, his shell script (Which launched my app in the first place) would detect that my app exited, but the image-viewer process is still running, and kill the image-viewer process.

In this way, people can write applications without needing to worry about referencing libraries, which is a right PITA if you wish to develop on another machine / OS, and very much raises the bar in terms of who has the ability to write applications using this library. All your app needs to do is to execute a process. One could even conceivably write a mock process for local development which mimics image-viewer - it could just open a window and display the GIF or image. Then, as long as your app is cross-platform, you could develop it entirely locally, and just re-compile for the pi when you wish to deploy.

Admittedly, all of the above is only really useful if you wish to write applications which display pre-rendered content. I don’t really see how you could do the local dev stuff easily if you wish to dynamically draw arbitrary graphics to the panels.

8

On the other hand, if you’re writing your own application, embedding a library is always preferable to using independent scripts—the system is more reliable, faster, and more compact.

9

Why would it be faster if your C++ code called the C++ API directly, as opposed to running the led-image-viewer C++ executable, which also uses the C++ API?

I am guessing that the only speed gain would be the time to launch - ie, you are not having to spin up a new shell. Surely, once it’s running, it would be just as fast?

10

Sorry i haven’t done multi processing in years, and i do not use c# but isn’t there ways to do this in c# ? I know that it is the case for python so i think it should work similarly in other languages.

And even if not, i think implementing the “views” for only this specific usecase where you need to call the samples in a process would be overkill. I don’t see other use cases for the views since everything could be done programmatically if we know how to install and build the library.

I only see views as opinionated way to have certain animations/code stored and play them when we want.

11

Let’s rewind and focus on the problem that is trying to be solved here.

It’s not to solve @evilC’s very unique C# coding problems or force how anyone uses the underlying API.

The goal is automation. Right now this library has an implicit bias towards manual intervention and tinkering with things in order to get to a final working state.

The common goal for every person who downloads rpi-rgb-led-matrix library is to get an LED displaying on a Raspbery Pi. In all of these cases that involves executing a program and viewing its display on the LED panel. This behavioral pattern from users is not opinionated; it is a core and central repeating pattern. The command does not tell you how or what to render, it just asks you for the identifier of your executable and calls it in a more graceful and easy fashion. If you aren’t using this library to “view” anything on LEDs I question what you are using it for. To hinder that progress seems like the more opinionated mindset

So just to rewind again, the need here is I want to be able to wipe clean and flash a fresh SD card with the latest Raspberry Pi OS and in one or two commands have an LED displaying colorful pixels without any scouring through the latest version of README docs, issue threads and Discourse for help on how to get it running. That is solved by a Bash utility that runs all of this manual fluff into one compact central automated script.

In fact, with this, I would then want to push for deleting large swaths of the README and just list the install command instead. The point being is less reading and experimenting through manual intervention, and more automation and reproducibility.

This is simply a bash utility that acts as a bridge between the OS and the rpi-rgb-led-matrix library to fill the gap in common installation and execution issues.

I’m totally okay with pushback of a slimmer more lightweight utility, but we need to point out which specific features those are and let’s exclude them after diligent discussion.

Agreed, I also suffer from this in my project and it seems like a common issue. Clearly something that could benefit from automation. The python command in this interface is to have an intelligent automated setup instead of the current process of manually fishing around for things and installing packages manually until it works.

I’d much prefer to handle everything with one command in an automated fashion. The alternative is locating the individual commands to run, arguments to those commands, installing OS-packages, discovering nuances that require manual searching and outreach (GitHub, Discourse), scouring README docs, libraries to install, errors to sort through. That seems way more problematic and difficult to maintain to me.

The benefit of the view command is simply:

  1. Reduce manual intervention in new installations (starting utils, examples, demos)
    • Benefit: Less time-spent on issue threads created by newbies. (which is the actual maintenance burden)
  2. Reduce manual intervention in existing installations
    • Ex: Instantiate my executable and handle its lifecycle from an OS-resource standpoint
  3. Simple-easy command interface (rgbmatrix view clock, rgbmatrix view weather)
  4. Automate common patterns like needing to reference hardcoded directories and command-line arguments on every run
  5. Instantiate programs effortlessly while the hiding underlying implemention details
    • Ex: Is this C++ or Python or C#? Doesn’t matter, we scan, locate, build and execute the program.
  6. Put common command-line arguments in configuration
    • (No repeating --led-cols==64 --led-chain=6 for every program)
  7. Scan well-known rpi-rgb-led-matrix library directories to search for executable views
  8. Scan for executables/resources (views) using a generic environment variable that defines the search directory. (An extremely common software design principle)
  9. build, start, stop, restart, hook onto a view process as a unified process management strategy for its lifecycle on the operating system.
  10. A view is simply a generic object with generic properties to solve common problems. There is no opinionated bias at all.
    • It serves generic commands to operate on that object:
    • assert, build, start, stop, hook.
    • Which of them is opinionated?
  11. The idea is not to have to do things programmatically. Common generic patterns should be abstracted away rather than everyone having to re-implement them. Less programming and more usability. That reduces struggles for everybody.

This Bash utility should not rely on external dependencies and libraries outside of the concerns of the rpi-rgb-led-matrix repo, but rather just group together common sequential commands that need to be ran to get things working. That onus should still be on the program to handle its own internal resources effectively.

This utility could also be optional and not required by all means. I’d even be ok with leaving it out of documentation and just having it there for power-users to secretly discover and use. Perhaps prior to becoming more widely accepted and adopted.

If there are specific unique commands that appear too heavy-handed or possibly unreliable to have a program depend on, happy to discuss those and omit them.

12

Thanks for that comment. So that we’re all on the same page, Henner is the main developer of this lib. He does not read this board as far as I know, and barely has time to look at bugs and PRs, which is why I offered to help, but I do not have deep knowledge of the lib or its internals, nor am I offering to take over the lib due to loads of other projects and hobbies :wink:
So I’m fine merging self contained things that improve things, but anything that touches the main code and needs careful review, i’m probably not going to review and approve, and Henner is not likely to have the time. Last I talked to him he was interested in adding PWM support though as this is pretty much necessary for any new panel.

So I’ll +1 comment on having a separate repo with layers on top. For that matter, I already did that myself:

13

I am cognizant that we are all donating our time and effort for free towards discussion threads and progressing the codebase (which could be spent instead on other enjoyments in life). And anything that disrupts that balance or creates extra perceived workload is undesirable. That might just be an unfortunate reality of the community culture that I had to discover for myself. I can accept that dynamic, and I wish it were different but such is life. It would be a lot less work for me not to submit this feature and that is also a desirable path to take. So unless there is more traction from other maintainers and people in charge I will retreat to the shadows back to a end-user instead of a contributor for now.

14

there is an option #3: build a lib on top of this lib, this is literally what I did.
If somehow you need a very small patch or two for your lib to work with this lib, that would be a lot easier to merge

15

I appreciate the positive encouragement, but I’m more interested in addressing core pain-points in the official codebase rather than offer third-party addons for other hobbyists. It’s as good as dead going that route and would be a wasted effort if it can’t impact a wider audience in my experience. It’s a popular and successful library - it’s just missing a Bash command-line utility. If you were trying to flash SD cards from scratch and automate the process you would reach similar pain and conclusions versus from the perspective of manually setting up a single LED hobby project once.

16

I think your feature is for higher-level users. For me, if you have basic coding knowledge, it is easy to create a basic LED display program (provided the install and build parts are easy—right now they are tricky) and to automate it, especially in the AI era where everyone can have assist on code.

Maybe your utility would be more useful for end users who don’t want to write code, but that is not what this library was aiming for at the start. I would see your tool at a higher level where these users don’t even have to write code in the first place, maybe with a web interface to create views or something else.

When I said ‘opinionated,’ it was more like ‘restrictive.’ What if I want the structure of my program to be different? What if I want to integrate other libraries ? or handle specific execution of my program myself? Views are okay for basic use of the library, but if we want to do more (and that need can come fast), a lot of users will need to work with the API. So, integrating this tool as a main part could be too much maintenance effort for questionable added value.

I don’t know if commands like build or python would be easier than doing things with make or pip install. I personally think the pain points should be solved independently in terms of maintenance.

1 Like
17

I was going to write my considerations, but @aeron169’s post almost completely expresses my thoughts :slight_smile:

I believe that creating a generalized interface shouldn’t deviate us from the original DIY concept. Let it be an option, not the core library code. Therefore, moving this code to a separate repo seems appropriate to me. This code is for a specific user group, not entirely consistent with the main GitHub audience.

Furthermore, when you want to avoid reading documentation and README, you don’t take into account the diversity of hardware we have to work with. Every year, there are more and more panel options, and I don’t quite understand how an automated program can figure out exactly which options are needed for your panels. Users will still have to understand the intricacies of all these options, protocols, multiplexes, and additional delays. And I don’t consider this a disadvantage. After all, if you just want to press the view clock command and get a ready-made clock, why not just buy one from a store? :slight_smile:

1 Like
18

There’s just a misunderstanding in what has been architecturally proposed here despite giving lengthy explanations and a technical deepdive in the original post. I’m not shipping ready-made clocks. I make no reference to shipping pre-made views or enforcing libraries on people or program structure. It doesn’t write code for you or gatekeep you from the underlying API.

I’d like to gently ask what is the experience level with Bash scripting in this Discourse board? It’s to handle batch low-level grunt tasks on the operating system and automate things with commands. You group a bunch of commands into single command and call that. You then bundle it into a command-line interface. It makes working with the OS easier and more productive so you can focus on creating actual graphics rendering code. If you are doing everything in C++ relating to that you will be seriously unproductive reinventing the wheel. The goal of every developer should be to write less code, not more.

And that might be why there are thousands of GitHub issues recently closed and countless help threads on Discourse. Because the current vibe is to require everyone to repeat the same tasks and reach the same conclusions individually. Then when there are willing devs stepping up to solve issues there is an underlying hindering of progress that is cultural in nature.

19

Yeah, this kind of sums up my experience to date TBH.

I know how to code, but what I do not know is the intricacies of make, cross-development etc.

It’s also that part which AI has proven the least useful for

20

For me, the real feature that doesn’t fit in your automation process is the views, since I don’t think it automates anything besides adding them to systemd. But for other commands, it could be debatable whether it has real added value or not.

As I said, it’s only my POV and I don’t want to hurt anyone’s feelings by saying it is bad or not, and my answer was not aiming for that.

I just want to aim at the future, and adding another layer which for now is only counting on you is very risky (we see it with the bindings where maintainers are needed). So we must be very careful

Only doing this is ok, but for me if someone can’t start an executable he should not use this library and ask for an higher level solution.

When we installed the library what are the benefit of doing that

This is fine if we’re okay with the samples not being samples and being used as the main program. We can easily do this programmatically.

I would rather create separate repos for bindings instead of doing that.

same as 4 ?

If you are talking about the samples, same as 1.

Ok, but why? If we are aiming for higher-level users, will they be able to code? And if yes, what is the benefit instead of writing in one file your program after you successfully installed the library?

ps: If i have the time i will quote the other points, but right now i must leave.

21

I understand the advantages of Bash and the C shell, but my usage scenario doesn’t involve a significant number of repetitive operations with the library that I need to automate.

Another issue is that any automation also requires initial setup. Wouldn’t it be possible that instead of initially setting up the library itself, the user would spend a comparable amount of time configuring the automated interface?