I don't believe so. Shortly after creating the PR I had the same thought, it would be nice if I the GTK theme engine could follow the GTK icon theme. I think that would be a better solution than what my PR proposed.
I also had the thought the other day it would be nice if it were possible to set different GNUstep icon theme in NSGlobalDomain.plist so one could try out different sets of icons without having to fork a theme each time. Joseph Maloney Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Friday, July 11th, 2025 at 12:21 PM, Ethan C <[email protected]> wrote: > Does the Gtk engine support standard icon themes, like Gtk uses? I feel like > that'd make it integrate better with users' desktops. > > Also, the Gtk engine is not perfect, and it targets Gtk2 (which many themes > no longer support). I think the better way to achieve this is to actually > make GNUstep themes for the popular themes (Adwaita 4, Adwaita 3, Breeze, > elementaryOS, Yaru, Nord, etc). > > On 7/11/25 12:16, Joseph Maloney wrote: > >> 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]>](mailto:[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
