There is a bit of work to do to make wayland backend work fully properly. Neither close and minimize buttons work with any compositor. AppIcons showing crashes apps in most compositors so I turn them off.
I started a PR to fix close button: https://github.com/gnustep/libs-back/pull/57 I lost interest and may get back to it in the future because of this limitation with wayland: https://bugs.kde.org/show_bug.cgi?id=424485 There is a PR that is been open for many years that I believe will fix this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/33 Until that is merged it seems only plamsa apps work with dbus menus. I have actually already started an OS X like desktop environment here: https://github.com/gershwin-desktop/gershwin-desktop I have a lot of the same goals, integrate XDG, replace non GNUstep components with GNUstep components, etc. Joseph Maloney Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Friday, July 11th, 2025 at 4:58 PM, Ethan C <[email protected]> wrote: > wlroots provides a lot of useful stuff for writing compositors, and I think > if we want a GNUstep desktop we should probably use an existing wlroots-based > compositor such as labwc. > > While it doesn't have all the flashy compositing effects that wayfire does, > [labwc](https://labwc.github.io/) is a pretty nice openbox-based compositor. > > For solving common needs of a DE, you'll probably want to see: > > - [quickshell](https://quickshell.org/) - a Qt-based DE-building toolkit > - [Raspberry Pi Desktop](https://github.com/raspberrypi-ui) - they make a > lightweight desktop and recently switched from wayfire to labwc > - LXDE and LXQt, of course > - and the past GNUstep desktop projects > > and there's probably lots more. I have [some notes on this in my notes > repo](https://github.com/ethanc8/gnustep-notes/tree/main/DesktopEnvironment/steproots/Planning), > you'll probably find it helpful if you want to go that route. I was thinking > that we should try to make a desktop environment from Qt or Gtk components > first, integrate it into SystemPreferences, and later on replace more Qt and > Gtk components with GNUstep components. I'm not interested in working on a DE > right now, but this should get you started. > > On 7/11/25 16:38, James Carthew wrote: > >> 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]>](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
