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
