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
<http://gnustep.github.io>) be the main website.
gnustep.github.io <http://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
