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
