Barnabás

been pretty busy on construct lately — here’s what i shipped:
-hooked up GIF support so projects can actually show some life
-added a project type filter to the review page, way easier to navigate now
-built out review feedback showing up directly on the user projects page
-did a db schema change to properly handle allocated pricing

A little RGB control app for macOS. I built Orchestrator to make Logitech G213 and Razer lighting way less annoying to deal with. It lives in the menu bar, detects your devices automatically, and lets you slam on presets or pick your own color without jumping through a million hoops. It’s kind of become a tiny control center for supported peripherals, which is honestly way more than I expected when I started it.
This time I worked on a bunch of smaller improvements too:
-added support for Logitech G213 and Razer peripheral detection over USB/HID
-made a menu bar UI for quick RGB control
-added color presets and a custom color picker
-hooked up live device monitoring so it notices when stuff gets plugged in or unplugged
-added the plumbing for sending lighting commands directly to the devices

Last few hours were messy but productive. I reworked the hardware setup and added a second monitor, which pushed me into building the driver in earnest once I discovered my MacBook only supports one external display. The core idea stayed the same: render a virtual screen on macOS and stream it to a Raspberry Pi so I can actually use two monitors. Video streaming works now, but the virtual display gave me grief — it kept mirroring the main display no matter what I tried. I burned through a bunch of approaches (like ~15 attempts) until I dug up CGVirtualDisplay (private API) and a helpful GitHub repo that finally got me an extended display that can be streamed.
Current pain points: the raspberrypi4 with 2GB RAM is a major limiter — most animations and the heavier UI stuff kill the Pi. The web dashboard was hammering the backend with requests, tanking performance, so I added a guard: check if the monitor is actually available, and only render/send data when it is. That trimmed a lot of wasted work and smoothed things out.
Networking is another bottleneck: video goes over the network right now and can be slow or flaky. I’m prototyping a hybrid transport (Wi‑Fi + USB) so we can fall back to the faster link when available. Other tweaks: reduce encoder bitrate selectively, debounce dashboard requests, and avoid rendering frames when nothing changed.

My wifi is cooked rn sorry

I’ve been shifting the app away from just “it works” toward something I’d actually want to use in the car every day. The biggest chunks of work landed in the settings screen, update flow, and the Android bridge — I added a GPS test panel so I can actually verify signal without digging through logs, rewrote how APK updates get downloaded and installed so it doesn’t feel janky, and cleaned up the bridge code for unknown-source installs and media session handling.
The rest is mostly UI polish — tightening spacing, fixing up the styling across screens, making things feel more finished. Nothing flashy, just the kind of stuff that makes it feel like a real app rather than a prototype. Still a lot to do but it’s getting there.

Mapories is a privacy-first shared journal built around a map. Instead of dumping entries into a feed, you pin memories to real places, and the app keeps them private until you choose to share them.

It has:
-Google sign-in, so there’s no separate account system to manage
-Map-based journal entries with a visual location layer
-Private posts that stay hidden until one month has passed, unless you’re the author
-Photo uploads
-Encryption for sensitive data
-Role management for admins
-User, role, and pricing tier management on the admin side
-CSRF protection, rate limiting, and refresh token rotation on the backend
-Docker-based setup for running the whole stack locally or in deployment
-The backend is built with Fastify, Prisma, and PostgreSQL. The frontend is a React + Vite app using -Leaflet for the map UI. It’s basically a structured, private memory app that’s meant to be shared carefully, not instantly broadcast.

So basically it’s a Slack bot that answers FAQs. Pretty straightforward, right? You throw your FAQ docs at it and when someone asks a question in Slack, the bot uses an AI API to search through your FAQ and answers them with a concise, FAQ-backed reply in a thread.

The main things it does:
Reads your local FAQ file (markdown) and uses that as context
Hits an AI API with your question, validates the response follows specific rules (needs a greeting, must mention the FAQ source, suggests closing the ticket)
Has rate limiting and a circuit breaker so it doesn’t nuke your API quota or keep retrying forever
Supports concurrent workers so it can handle multiple questions at once
Has a manager dashboard where certain users can sync workspace members across channels
There’s also some channel management stuff — you can set it up to auto-invite people to specific channels and monitor others for new members. Ships with a health check endpoint and metrics tracking so you can see how many requests it’s handling.

The validation is pretty strict though — it checks that the bot doesn’t encourage follow-ups (no “let me know” or “any other questions” type stuff), which makes sense for keeping tickets moving.

Hiya!
I just made “dynamic island” for mac. It does support music widget, lock screen and screen saver detection, but it can be implemetned to other apps.
Also I added an important (at least for me) feature: key change. MacOS does not support Hungarian 101 keyboard so the í0 is changed, but now I can fix this error.
The whole notch has quite fancy animations in my opinion.

FInally the backend also works, so now the admin account has full permission on the server. Invite 308 error is also fixed.

Now deployed to: https://event.bbarni.hackclub.app/
You can access test account:
-username: admin
It will guide you thru login (it’s a restrained admin account tho)

Event Pyramide is basically a pyramid system for event which require tickets. So basically this is an invite only event manager and ticketing platform, ready to deploy via docker. It has the basic ticketing system, bar order and bar item tracking and even some kind of early security management. It’s based highly on instagram users, but I can be easily changed. It can handle quite big user groups at the same time too. And how does the pyramid system comes in you may ask? It has a feature where the admins can specify how much discount can a person get by inviting new people to the events.
Don’t be shy, feel free to try it out!!!! (it has fancy dark ui)

Last few hours was kinda painful. I made huge progress tbh, but I had a lot of problems during the development. So the main problem is that this raspberrypi4 only has 2gb of ram which isn’t enough for most of the animations, and this whole screen sharing, also the web dashboard used to nuke requests for the backend which significantly decreased the performance. Now I’m working on check if the monitor is actually available, and if yes only then will it render the infos out.
The video transfer now works only via network which can be really slow sometimes, so I’m working on a hybrid solution, which will use both wifi and usb.

Ooh, I didn’t know it was 7 hours, oopsie.
Over the last few days, I was a bit sick, so I had a lot of free time. I decided to update my setup, rearranged the hardware, and now my desk looks so much better. I did the cable management and set up two monitors. When I finished, I wanted to connect both screens to my laptop.
That’s when I realized my MacBook doesn’t support two external displays. So I decided to make a driver for myself to actually be able to use two displays. The idea is simple: software that renders a screen and sends the data to a Raspberry Pi, which then displays it on a monitor. Low latency, good colors.
I set everything up. The app works, video transfer works, but I had a lot of problems with the virtual screen. It always mirrored the main display. I tried around 15 different methods, but none of them worked.
That’s when I came across the CGVirtualDisplay private API. I had a few failed attempts with it, but then I found a GitHub repo that basically carried the whole project. Now I have a version where I can use an extended display that’s streamed to my Pi.

Now, I can actually upload a devlog, since last time I uploaded a devlog about the market and the design lowkey got leaked. In this time - along with some smaller improvemets - I did:
-refined printer dashboard (so gcode file would be necessarily)
-a project status bar which shows that the project currently is in what stage
-some optimalization for explore page to save some ram
-and an airtable integration fix

I just got a Junsun android head unit for my car but all the factory themes sucked, so I thought why not making one (specifically for my car). The idea was to add a 3d model of the car in the middle and read out the speed and rev infos from mcu (and canbus), but unfortunately Junsun does not give access to these. I just tested it, I does run really good on my mac, but the head unit has only 2gb of ram so most of the animations lagged out like crazy. So this is the current state, but now I’ll change it to make it more ram efficient, and still look smooth on my car.

I’ve added a snowfall to the whole Construct YSWS site. And also made the market system for the site. Admins can crud market items, and now market score actually does somthing:
It discounts your items!!!