Regarding the future of Hyperspace Desktop

[alicerunsonfedora]

In late November and early December, @Nomad1556 looked into the Flutter development toolkit for creating cross-platform apps. We're planning to create a small Dart library (Codename Foxy) that allows API access to Mastodon and Mastodon-like networks, similar to what we've done with Chica. We're also planning to make an experimental Hyperspace project, Codename Luna, with Flutter.

Why this matters

Hyperspace Desktop is the project-defining client of Hyperspace. Users and developers enjoy using the Desktop client for its ease of use and clean design, following the Material Design guidelines closely. However, maintaining this project comes with costs:

• First, the project structure is a bit outdated and doesn't match our newer schemes. This is also being discussed in Define a structure for all our projects #4.
• Second, the desktop apps for the Desktop client are built with Electron. We've had issues with App Store submissions in the past because of Chromium's usage of private APIs, which affects Electron. Additionally, the community has been sharing a growing concern about Electron apps for their performance costs and poor quality. Users want clean and performant native apps, and we're unable to deliver that with Hyperspace Desktop à la Electron.
• The source code for the Desktop client is beginning to become unmaintainable. We've been successful in trying to refactor some files, but we're still using some outdated practices for React, and we're not taking advantage of modern JavaScript features such as async/await. Furthermore, the codebase isn't well-documented, which adds another challenge to maintenance.

It's been nearly over a year since we made the decision to put Hyperspace Desktop in maintenance mode (see hyperspacedev/hyperspace#232). Since then, we haven't actively developed the app, but keeping an eye on issues and feature requests that we can implement into Starlight from the beginning.

So what's the deal?

@Nomad1556 and I are heavily considering replacing the Desktop client in the future with Hyperspace Luna or creating a new Desktop client altogether. This will allow us to do the following:

• First, we can offer nearly close to native performance thanks to the Skia graphics engine that makes Flutter possible.
• Second, we can enforce modern practices from the beginning and ensure we document our codebase in the process. This would also mean structuring our code as discussed in Define a structure for all our projects #4.
• Additionally, Flutter supports the Material Design language out of the box, as well as native components. We can use this as a means to extend Luna to other platforms if necessary.
• Furthermore, our code can be licensed with the Non-Violent Public License from the beginning, which ensures that our code remains ethically sourced.
• Finally, we won't be limited to Electron and TypeScript. Although they've served us well, keeping up to date with these dependencies can be difficult. Since Flutter uses the Dart programming language and is officially supported by Google, maintenance will be easier from the start.

I'd like to know the community's thoughts on this, as well as the Desktop development team.

[wakest]

Electron is a huge stopper for many apps. I am usually running older computers and electron apps are always so so much slower. Would love to see a modern take on desktop fediverse client. Also if you are building it from scratch take advantage of that and build with the idea that this should support many fediverse apps. Fine if you want to only support the mastodon api design but even so there are a lot of different dynamic features that different implementations support that are not just what mastodon does.

[alicerunsonfedora]

Also if you are building it from scratch take advantage of that and build with the idea that this should support many fediverse apps. Fine if you want to only support the mastodon api design but even so there are a lot of different dynamic features that different implementations support that are not just what mastodon does.

I'm not sure if we can guarantee support for the various features forks of Mastodon support, but we can certainly keep a new approach in mind. One of the points I failed to mention include keeping our target audiences and design goals from Starlight.

Regarding API support, while we will likely try to stabilize the API support for Mastodon first, we can definitely look into adding support for other API types.

[alicerunsonfedora]

Hey everyone,

After some deliberation and assessment of the team's capabilities, as well as the current state of Flutter desktop and its implications, we have decided that we will be moving away from Flutter when developing Luna and its networking counterpart, Foxy.

We will instead be focusing our attention on writing Foxy and Luna using the .NET Framework and C# to achieve this. The means of creating the apps are still unknown as of this moment, but we're researching this topic and will get back to you. It is very likely that we will either use a solution like .NET MAUI (currently in preview) or even the Godot engine, given its support with C#.

I'm excited to see what will come of Luna/Foxy in the future!

[Nomad1556]

Epic

[Nomad1556]

Hey everyone,

So remember how we said we'll be writing Foxy and Luna using the .NET framework and C#? Yeah, well not anymore.

After a poll we conducted, the majority of our users are using Linux and we found that .NET MAUI does not support Linux. We could have used Avalonia, though we would have preferred a Microsoft-built solution that's guaranteed to work with .NET.

With that said, we are now gonna focus on writing Foxy and Luna using Kotlin and JetBrain's Compose For Desktop to allow us to provide first-class experiences across Windows, macOS, and Linux.

Sorry for the flip flop. We promise this is the last time.

[alicerunsonfedora]

Amazing.