Hi everyone,

I've been working on a project called WGAF (Wayland GNOME Automation Framework), and I'd love to get some feedback from people who build GTK applications.

The project is here:

https://github.com/Ranrar/wgaf

What is it?

WGAF is an automation framework specifically designed for the GNOME Wayland desktop.

Instead of relying on pixel matching or screen scraping, it combines several GNOME-native technologies:

• AT-SPI for accessibility and semantic UI automation
• Linux uinput for keyboard and mouse input
• A GNOME Shell extension for window management and workspace integration

Examples of what I'd like it to enable:

• Automated testing of GTK applications
• Desktop automation
• End-to-end UI testing
• Accessibility tooling
• CI testing inside a GNOME Wayland session

Why I'm posting here

I'm interested in hearing from GTK developers.

Some questions I have are:

• Would this be useful for testing your applications?
• Are there parts of GTK or AT-SPI that are particularly difficult to automate today?
• Are there accessibility APIs or widget information you wish automation frameworks exposed more easily?
• What would make you trust a framework like this enough to use it in CI?

The project is still evolving, so this is a good time to influence the direction.

Any feedback—positive or critical—is greatly appreciated.

Thanks!

Hey r/sideprojects,

I wanted to share a small milestone for a project I’ve been working on called Marco.

It just passed:

• 100+ GitHub stars
• 219 downloads this month (Windows + Linux)

Repo: https://github.com/Ranrar/Marco

What it is

Marco is a native Markdown editor + viewer built in Rust, with a focus on performance and structured technical writing.

It comes with a companion app called Polo, which is a lightweight Markdown viewer.

Both run on Linux and Windows using GTK4 and WebKit/WebView2.

Why I built it

I work a lot with technical documentation and manuals, and I couldn’t really find a Markdown editor on Linux that felt:

• fast and local-first (no cloud / login)
• stable for long technical docs
• structured enough for complex documentation
• consistent between editing and viewing

So I started building one from scratch.

It turned into a deeper project than expected, including a custom Markdown parser and AST instead of relying fully on existing parsing layers.

What makes it different

Some key things I ended up adding:

• Custom Rust-based Markdown parser (marco-core)
• Live preview with scroll sync
• Full CommonMark compliance + extensions (tables, math, mermaid, etc.)
• RTL + Unicode support (important for international docs)
• Export to PDF + print mode
• Structured document navigation (TOC, bookmarks, cross-file links)
• Designed for technical documentation, not just notes

The idea was: Markdown should behave more like a real document system, not just a text format.

Tech stack

• Rust (core + parser)
• GTK4 (UI)
• WebKit / WebView2 (rendering)
• nom (parser combinators)
• KaTeX + Mermaid rendering
• RON config system

Where it’s going

Still early, but next focus is:

• improving editor intelligence (completion + diagnostics)
• collaborative editing (CRDT experiment)
• optional privacy-first telemetry (opt-in only)
• better packaging + easier install flows

Feedback welcome

If you try it, I’d really appreciate feedback on:

• usability (especially Linux workflow)
• documentation workflows
• what feels missing compared to other editors

If nothing else, thanks for reading 👍