Helge Heß

@helge
1.3K Followers
560 Following
11.8K Posts

It is okay to release a F/OSS project where the expected set of users is you.

It is okay to declare that a F/OSS project that you maintain is feature complete and stop.

It is okay to stop writing new code in a F/OSS project and just review patches from other people.

It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.

It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).

It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.

It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.

It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.

It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.

Since I just walked over it again, on non-Darwin platforms the MainActor does NOT necessarily run on the main thread. I think it's just a regular global actor there that can run on any thread.
Actually I wonder how to fix this. Could you do an own MyMain actor w/ an executor that uses the GCD main queue? If so, why doesn't Swift do this in the first place?

You can't make this up, we have *two* RFC'ed standards for JSON calendar data (and address data):
- RFC 7265: https://datatracker.ietf.org/doc/html/rfc7265 (standards people from various companies)
- RFC 8984: https://datatracker.ietf.org/doc/html/rfc8984 (FastMail)

It's seems clear that someone just didn't like the format of the other. So now we have two. For the same freaking thing. Yes, I read 1.1, all 4 points seem like utter nonsense to me. Yes calendars are hard. Independent of the format.

RFC 7265: jCal: The JSON Format for iCalendar

This specification defines "jCal", a JSON format for iCalendar data. The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.

IETF Datatracker
Verkaufe iMac M1 (2021), 24zoll, 16GB, 1TB, silber, olle Tastatur, Magic Trackpad. Ich hätte gerne 650,- Euro dafür. Karton fehlt, darum nur an Selbstabholer in 13355. Gerne RT.
I don’t know a single app in the current „Apple Design Award winners“ email. But i suppose that’s the idea, get to know new apps by featuring them. Recognizing apps that people actually use is a different thing.
Thomas Gottschalk wird auch immer schräger #lanz
It's one of those things where having less capabilities opens up new opportunities. A SwiftUI NavigationSplitView doesn't expose on what screens the views are or really gives you things to cross-draw between the subviews in a proper way.

People are wondering how the iPhone foldable would work, API/screen wise. Do you open separate scenes for the screens?
With our fancy “declarative UI” framework you could also build things where your 3-part foldable is actually:

[Sidebar] | [.              Content              ] | [ Inspector]

(to close, you'd put the sidebar/inspector on top of the content and the back becomes the regular combined thing)

Kinda like the iDrawerMac, but for reals. Might be less crazy than it sounds, IMO.

Also, if it would be FOSS, most people probably wouldn't really wait for the next OS versions to ship to get things they may have fixed. You'd fork it, fix it, and link the whole thing into your app.
The sad thing is that even if they did release the thing, I'm somewhat sure that it'll be another corporate FOSS thing like Swift itself, and essentially be driven by Apple only. Just another swift-swiftui repo on GitHub (meh) that no one else contributes to at a meaningful scale.
Though there might be forks on this one, who knows. As of today there are only a few things that require 1st party SwiftUI, like widgets.