I know a lot of people are going to disagree with this, but I think GNUstep needs a display manager for Wayland that's not based on WindowMaker. WindowMaker is super old and it makes it impossible to build an OSX-like UI. It'd be better if there was a modern Display Manager similar to Wayfire with compositing/special effects etc. That also integrates tightly with GNUstep via Objective-C calls and has a SystemPreferences.app ui for configuration of behaviour and themes.
On Sat, 12 Jul 2025 at 03:29, Joseph Maloney <[email protected]> wrote: > 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]> > <[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 > > > >
