Regarding theming. I made a PR for the GTK engine to integrate Rik icons. Combined with GTK themes I think it looks really nice. There are some other improvements I would like to make in the future. This doesn't help other platforms like Windows and I don't know what that looks like I guess but just thought I would bring it up.
https://github.com/gnustep/plugins-themes-Gtk/pull/2 Also McClaren labs has Rik working again: https://github.com/mclarenlabs/rik.theme.git I don't know of any other new themes from scratch yet. Joseph Maloney Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Friday, July 11th, 2025 at 11:42 AM, Ethan C <[email protected]> wrote: > Hi everyone, > > These are a lot of points that I could expand more on if needed -- my general > thoughts about the direction of the project. I haven't really caught up to > the messages in the past month, so maybe some of these have already been > discussed in depth. But some of these are new topics. > > Swift, SwiftUI, UIKit, and CoreAnimation > > We need to attract current developers in the macOS ecosystem. Simply being > able to port apps written in the pre-Swift era won't be very helpful -- the > best apps from that era are proprietary, and nobody is still developing apps > in the same style so it won't attract contributors very well. > > I see many exciting in-progress projects written in Swift and SwiftUI, and > there's a lot of open-source stuff written for UIKit that would be nice to > have. How I think we can tackle this: > > - We need native support for libobjc2 in the Swift compiler. There is no way > around this; we'd otherwise need to write a preprocessor for Swift, which > would involve needing to have a high-quality Swift parser already. The > compiler obviously can parse Swift very well, and it has support for objc4 > which we can hopefully adapt. > - We need to implement the CoreAnimation-AppKit bridge. This will allow us to > port AppKit apps written in the 2010s, and will be necessary for Chameleon > and SwiftUI. > - We revive the [Chameleon project](https://github.com/BigZaphod/Chameleon), > so we can implement UIKit on top of AppKit. This requires the > CoreAnimation-AppKit bridge. However, it targets iOS 3, so we will have to do > lots of work to get it up to iOS 26 parity. Perhaps with the amount of people > switching to SwiftUI we might not need a full UIKit implementation, however. > - We work with the [OpenSwiftUI > project](https://github.com/OpenSwiftUIProject/OpenSwiftUI) to support > SwiftUI. This also requires the CoreAnimation-AppKit bridge if we want to use > their current codebase which targets AppKit. They want to also support other > platforms, but of course those other platforms will not have the > SwiftUI-AppKit bridge, and I think it wouldn't be worth it for us to support > SwiftUI if we didn't support the SwiftUI-AppKit bridge. > > I originally planned to work on some of these, but I found that they were far > too difficult for me to work on. I don't think the project stands much of a > chance if we don't implement these, as the amount of people with AppKit > experience will go down and down as time goes on. > > Apps to port > > We really need to find apps to port to GNUstep. Porting apps to GNUstep will > help us find a lot of the pain points that users might face, and will show > people that GNUstep is useful for more than making NeXT-style apps from > scratch. > > We should probably work on a wishlist on the wiki. > > Packaging > > I'm planning on working on this, because I think the solutions I find will be > useful for every toolkit without a good packaging story. > > I think Conda packaging is probably the best way to target most needs; we can > work on native packaging later to allow for things that need to integrate > more closely with the system. > > Problems I'll try to solve: > > - There's no way to make installers. It shouldn't be too hard to figure this > out, though. > - I'll set up a CI to distribute nightly builds of GNUstep, which will make > it easier for people to test out bugfixes and new features. > - My Conda packages only support GNU/Linux currently. I'll need to make > Windows builds -- do we prefer mingw, MSYS, cygwin, or our MSVC+Clang > toolchain? I think the MSVC+Clang toolchain is the most widely supported. > - I want to support Android, especially once we figure out UIKit. But that's > a quite difficult task, I don't know if I can do it. If we can get this > figured out it will make it so much easier also to port other non-GNUstep > apps to Android. > > Also, does anyone else want to try out my current Conda packages? I have > instructions here: > https://github.com/ethanc8/gnustep-forge-feedstocks/blob/master/guide.md. > > Accessibility > > Nowadays many commercial users need accessibility; it's often required by > their customers or by law. I think we should implement the macOS > accessibility APIs on top of [AccessKit](https://accesskit.dev/), which > provides abstractions over the major platforms' accessibility APIs and is > used by most of the Rust GUI toolkits that support accessibility. We'll need > to disable accessibility when we're not on a platform supported by Rust, but > I don't think any users will need accessibility on platforms without Rust > support. > > Website and documentation > > I don't really have any plans for the website, and I think until we can have > good enough content to put on it we should just make the documentation > website (gnustep.github.io) be the main website. gnustep.github.io is not > ready for this yet. > > - We need to have good installation instructions available, which will depend > on packaging. In the near term, I will try to get my Conda setup instructions > there, and once we have good packaging for other platforms we can add those. > - I think we should convert the manuals into Markdown and put them into the > "manuals" section of the doc website. > - We need to figure out what to put on the homepage of the website. > - The Sphinx theme we currently use is not very good. I'd like to write a > better one, but this is a low priority. > > Wiki > > I think we should try to migrate the wiki to Miraheze, which provides free > MediaWiki hosting. This would allow us to not have to worry about maintaining > the wiki servers or preventing spammers from signing up, and with Miraheze's > easy sign-up flow it'll be easier for new people to contribute. Also, > Miraheze keeps up-to-date on MediaWiki versions, which will allow us to > provide the modern Wikipedia interface and make it comfortable for people > who've edited Wikipedia or other MediaWiki wikis before. > > Anyone logged-in can set their theme to whatever they want, so people who > like the old MediaWiki theme can still switch back to it. > > Even if we want to maintain control of our wiki hosting and login process (I > can see why we'd want that), I think we should still switch to a recent > MediaWiki version. > > Theming > > Is anyone currently working on a modern-looking theme? > > Once this is done, I think we should set it as default and make a lot of > screenshots using it to post on our website. Also, we can make a gallery of > high-quality GNUstep applications. > > Thanks, > > Ethan Charoenpitaks
