Jan Hovancik

Stretchly 1.21 is now available

2026-04-25T06:00:00+00:00

Hi everyone,

I am really happy to announce, that version 1.21 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

advanced option for Break Health Mode

Fixed

fix focus mode detection on macOS Tahoe
fix idle time detection on Wayland

Changed

increased font size of current time in break window
moved macOS Homebrew installation to custom tap
improved tray icon styling
updated many translations

Stretchly 1.20 is now available

2025-12-24T06:00:00+00:00

Hi everyone,

I am really happy to announce, that version 1.20 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

new icon styles preference for tray (showing time to break or visual progress to break)
Autostart functionality in Flatpaks
portable version for Windows
set autostart based on the config file value

Fixed

snap package not starting on Wayland
break windows not closing correctly on all platforms
show breaks as regular windows on Windows

Changed

updated many translations

Fixing Good First Issues: A simple way to support Open Source

2025-12-18T13:40:00+00:00

Disclaimer: I work at Microsoft. The views in this article are my own and do not necessarily represent Microsoft.

It’s no secret that funding Open Source (OSS) projects is an issue that hasn’t been solved yet. (I’ll stop myself from linking memes illustrating the situation all too well.) Many individuals and companies try to help financially, but not everyone can donate, not everyone accepts donations (or can accept them), and there are a myriad of other things happening in between.

As December is the time of year when many Open Source projects update their yearly funding goals and ask for contributions, I find myself thinking about this topic as well. Not only because I have a few OSS projects and accept donations, but also because I am a proponent and user of the OSS model. For example, in one of my projects, I say: “Stretchly is free, but you can support it by contributing code, translations, or money.” And many people do.

So, as I keep finding more and more value in all these agentic tools and workflows now available, an idea started to crystallize: why not use the tools I get at work for free to help some OSS projects asking for help?

That’s what I started doing. If your employer allows it, this can be an easy way to support the ecosystem, and I encourage you to consider doing the same.

Here’s what I tried and how it went.

Good First Issues

One of the most common ways maintainers signal that an issue is good for taking is by using labels like good-first-issue or help-wanted. I started by focusing on good-first-issue, since I wanted to look at Rust projects and I’m not a Rust expert. And yes, I’m talking about GitHub (and Copilot), since that’s where my personal projects live and where I have an account and tools available.

I used this GitHub search to find good-first-issue labels on Rust projects, and I also asked VS Code Copilot to help me find some interesting good-first-issues in Rust projects that it could help me fix, even though I’m not a pro in Rust.

Here are the PRs I created with the help of agentic tooling, ranging from docs updates and code fixes to updating an older crate to a newer Rust edition: nushell/nushell#17178, serde-rs/json#1302, dsprenkels/sss-rs#15.

Since these are new, I haven’t heard back from the projects yet, but I already feel good about it. It reminds me the one of many reasons why I love OSS: it’s made of the thousands of tiny kindnesses.

Stretchly 1.19 is now available

2025-11-13T11:57:00+00:00

Hi everyone,

I am really happy to announce, that version 1.19 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

allow to show some HTML in breaks
advanced option for manual finish mode for breaks (breaks are only finished after user’s interaction)
advanced option to set preferred sound to be played at the beginning of breaks

Fixed

hide autostart option for Windows store
prevent memory issues where break windows were not closing correctly

Changed

hide update features in Windows Store, Snap, Flatpak versions by default
migrate long break sound preference from audio to longBreakAudio
updated many translations

Intro & Setup: Is Vibe coding with Rust feasible?

2025-10-03T13:11:00+00:00

Vibe coding (providing intent + context and letting AI handling the implementation) is one of those trends that sparks mixed reactions—some see it as a refreshing shift, others as a distraction. I think it depends on what you are trying to achieve. And right now, I’d like to vibe-code a solution to a real problem I have (as I have not vibe-coded, yet). To make it interesting and fun, I’d like to test a hypothesis with it: Rust should bring structure and safety to the otherwise fluid nature of Vibe coding.

I don’t have much experience with Rust (I’ve seen some videos about it), but Rust’s strong safety guarantees, expressive type system, and helpful compiler should provide AI agents with the structure and feedback needed to reliably translate intent into implementation.

Plan

The Plan is rather simple: I want AI Agent (GitHub Copilot Agent, specifically) to go through the process of building an app that solves a real problem I have - tracking and managing 1-on-1 meetings with a wide range of people at work – while making sure the code is not what we are used to hear about vibed code: equal to the bad code.

That means letting Copilot do as much of the work as possible—from figuring out what the app should do, to writing the code and making sure it’s not a hot mess.

I won’t be blindly taken to wherever Copilot would want to take me, but at the same time, I plan to ask a lot of questions like “What do you think we should do?”.

Let’s start!

(disclaimer: I work at MS on Rust-related topics)
(note: as you might see from commit times, I played with this some time ago. I believe I’ve used Sonnet 4.)’

Setup

As that’s what I have easiest access to, I’m starting with bare Windows 11 DevBox, where I installed Git and VS Code Insiders. Though thinking back, I should let Copilot install Git.

After logging into Copilot with my GitHub, I jumped straight into describing my experiment to Copilot and asked what it thinks. As expected, it was way too optimistic—ready to dive into code before we even agreed on what the app should do. I had to slow it down. From experience, I know it’s worth stuffing some context into Copilot default instructions first, so I made it do exactly that. Now, when I start a new chat, I don’t have to repeat myself.

Once that was done, I asked Copilot to commit the files. Local repo created, commit made (by Copilot). But of course, the branch was master :( so I told it to rename it to main.

As I then asked Copilot to push to GitHub, it gave me instructions to create a repo there. When I mentioned the official MCP server (hey friend, do this for me), it just shrugged (metaphorically), that it does not have access to the GitHub’s MCP. I expected Copilot to suggest installing the GitHub’s MCP server, but nope. So I told it to update the files so this situation with making me doing things doesn’t happen again.

Copilot then suggested installing npm package (@modelcontextprotocol/server-github). I didn’t check it—no Node installed anyway—and asked for alternatives. It had some ideas (cargo, winget, direct binaries) but didn’t know whether GitHub MCP was included there. I know one can install MCPs from VS Code, so I asked about it. Copilot didn’t know VS Code could do that and suggested installing some extension instead. So, I gave up and installed GitHub MCP from the Extensions sidebar (shame on me).

After that, and short discussion about naming the repo oneone, Copilot was able to set it up and push my commits. It told me that it will use trunk (GitHub’s modern default) for the branch, but it kept main as we renamed master to previously.

MVP Spec

As helpful as always, Copilot asked me how I think about 1-on-1 meetings, whether it’s about person, meeting itself, timing or something else. While this is rather clever approach (I am going to steal it), it asked this because it was trying to map my thinking to structures in Rust, which I did not like as it’s too early to start thinking about code. But one must love Copilot’s sense of humor.

Copilot then created a file we iterated over to catch what I want to solve for, or what the first version should have. I have to say that I enjoyed the process: I read what it produced, gave it feedback and stated my pain points. Copilot was a bit too verbose for me (I prefer short descriptions without fluff), but in the end I was happy with it. You can check it here, and yes, I tried asking Copilot to give me link to the commit and it worked just fine.

That’s enough for one post

To end part one of this experiment, I had 2 questions prepared for Copilot:

Considering what we have so far, should we do anything before we move to thinking about how the app should work (i.e. command line or web app)?
Considering our conversations so far, should I edit instructions for you (or any other rules), so that you give me more of what I want or change how you interact with me?

For the first one, it took some time to make Copilot not think about technical side (as in structures, storage etc.), but in the end it had a good suggestion of adding a [Readme(https://github.com/hovancik/oneone/commit/1e63595)]. I ignored similar suggestions to add license file. I’ll hopefully remember to that later.

I was more interested in how it would handle the second question talking about our relationship. I won’t bother you with all details, but we had a good discussion that led to some updates in instructions. Copilot did some good self-reflection, but in the end, it was up to me to say what I think did not work so well. To sum up, I need Copilot to be more collaborative, don’t accept everything I say blindly and don’t just try to code right away.

But hey, you might want the exact opposite, and that’s fine.

Learnings

Let’s end this with list of my personal learnings / tip’n’tricks / recommendations from what I did so far, in random order:

Think about Copilot as a person, have a discussion, except mistakes
Be opiniated, don’t let it drive you too much
Create default instructions
Notice what you don’t like about Copilot’s behavior and update instructions accordingly
When working on more complex things, iterate over some sort of design file (where the thing is being described)

Next time I’ll let Copilot setup the Rust environment and discuss the next steps.

Stretchly 1.18 is now available

2025-09-15T19:05:00+00:00

Hi everyone,

I am really happy to announce, that version 1.18 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

Yiddish and Tamil translations
advanced option to show custom message in Preferences
advanced option to hide location of Preferences file in Debug info
advanced option to disable app update features
advanced option to hide Strict Mode preferences section

Changed

remove flags in Welcome window
updated many translations
do not check for Quiet Hours on Windows (deprecated)

Fixed

prevent error with negative time to break in tray icon
hide close/minimize actions on Break window on macOS
issue when not all strings correctly translate after language change

Stretchly 1.17 is now available

2024-12-24T09:43:00+00:00

Hi everyone,

I am really happy to announce, that version 1.17 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

Bengali, Catalan, Greek and Serbian translations
it is not possible to close app during break that is in strict mode
logs command line option to show location of logs
advanced option to make break windows’ background blurred (macOS)

Fixed

error when end break shortcut is not set
time in tray shows the correct number (and matches the tooltip value)

Changed

improved break window loading
improve DND detection for Linux
updated many translations
better icons for “Show time in tray”
showBreakActionsInStrictMode migrated to showTrayMenuInStrictMode

Stretchly 1.16 is now available

2024-08-11T09:45:00+00:00

Hi everyone,

I am really happy to announce, that version 1.16 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

Estonia and Belarus translations
advanced option to show break options (Skip, Pause, Reset) in Strict mode
autostart option for Linux
keyboard shortcuts for pause breaks for specific durations

Changed

updated many translations
disable skipping to next break from tray when in strict mode

Fixed

transparency issues on Windows 10
Schedule and Menu options not being updated after change of language
multiple RTL UI issues
RPM installer conflicts with other Electron apps
improve break window loading to improve blank window issues

Stretchly 1.15 is now available

2023-11-11T11:22:00+00:00

Hi everyone,

I am really happy to announce, that version 1.15 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

new end-of-the-break sound
both left and right click on tray opens menu (Windows)
double click on tray opens Preferences (Windows)
adds Vietnamese translations
reset breaks shortcut (advanced option)
skip to the next break shortcut (advanced option)
respect Do Not Disturb on Linux distros (KDE, XFCE, GNOME)

Changed

updated many translations

Fixed

improve Do Not Disturb detection

Stretchly is now available in Microsoft Store

2023-06-12T13:05:00+00:00

Hi everyone,

I am really happy to announce, that Stretchly is now available in official Microsoft Store. I hope you will find this useful.

Thanks to everyone for their support!

Stretchly 1.14.1 is now available

2023-06-04T12:54:00+00:00

Hi everyone,

I am really happy to announce, that version 1.14.1 of Stretchly is here! You can download it from downloads page.

Thanks to everyone for their support!

Added

advanced option to not show menubar (tray) icon

Fixed

break progress bar overflowing on tall screens
dock icon staying after break on macOS

Changed

updated many translations