Announcement: Community‑ported Stellarium native build for OpenHarmony (Huawei devices, preview‑v1)

[joinother]

Hi everyone,
I have created a community‑led native port of Stellarium for OpenHarmony‑based Huawei devices, available on my forked repository, branch openharmony‑preview‑v1.

Current preview‑v1 features:

• OpenGL‑ES sky rendering via XComponent

• Full touch‑based operation (pan, zoom, select celestial objects)

• Multi‑language support, location detection, night mode, coordinate‑system switching

• Packaged as a 263 MB native HAP package, built with ArkTS‑N‑API‑C‑‑C++ bridge.

There is currently no comparable professional planetarium application on the HarmonyOS app market.
I am reaching out for two things:

1. Invite HarmonyOS device owners to test the unsigned‑HAP build and give feedback on touch‑routing issues and UI‑layout experience.

2. Seek advice from OpenGL‑ES mobile‑graphics developers for several edge‑case touch‑event‑routing bugs.

Repository: https://github.com/joinother/stellarium (branch: openharmony‑preview‑v1)

This is a personal side‑project. At this stage I do not intend to make a pull‑request to upstream mainline for now, as this is a separate platform‑specific port. Any feedback or suggestions would be highly appreciated.
Clear skies 🔭

[alex-w]

Why code is in docs directory?

[joinother]

Fixed in 9c9e13e — moved the source files to harmonyos/ and kept docs/ for documentation only.

[alex-w]

Interesting, why Positioning component is removed?

[joinother]

It was disabled because Qt 6.12 for HarmonyOS doesn't ship Qt Positioning (confirmed: no package in Qt Installer, no libQt6Positioning.so in the target sysroot). GPS is handled via HarmonyOS native geoLocationManager on the ArkTS side.

[alex-w]

It was disabled because Qt 6.12 for HarmonyOS doesn't ship Qt Positioning (confirmed: no package in Qt Installer, no libQt6Positioning.so in the target sysroot). GPS is handled via HarmonyOS native geoLocationManager on the ArkTS side.

Ouch... But in this case you should use IF(${CMAKE_SYSTEM_NAME} STREQUAL "OHOS") ... ENDIF() construction for cmake code (of course you can define some special flag for C++ code here) and __OHOS__ for C++ code. We use QtPositioning to obtain the coordinates from operating system (of course if device has sensors and OS can manage it) and flag ENABLE_GPS is used for direct managing the GPS devices. Using ENABLE_GPS for disabling handling positioning data is wrong way here.

[alex-w]

Stop! Looks like cmake doesn't know HarmonyOS out of box :-/

[alex-w]

@10110111 please check the branch, I think we may merge some parts of it into upstream after refactoring (I'm not sure for all code).

@joinother is it possible the testing your branch without Huawei devices?

[joinother]

Yes — use the DevEco Studio simulator . Full ArkTS + OpenGL ES pipeline runs without hardware

[joinother]

Also, with the help of AI tools (e.g. WorkBuddy / Trae / Codex), it is quite easy to clone the repo and start debugging on the DevEco Studio simulator. I have prepared a comprehensive onboarding doc (agent.md) in the repository that teaches AI assistants how to understand the project architecture, avoid common pitfalls (N-API threading, XComponent touch routing, ArkUI state traps), build the HAP, and debug on both simulator and real device. So even without prior HarmonyOS experience, contributors can get productive quickly with AI guidance.

[10110111]

@alex-w Hmm, I've just checked it out, and found that it has 171 commits generated by an AI tool with commit descriptions in Chinese. I'm at a loss how (and when) I could review this amount of changes. Do you have any actual idea what exactly of this you want to merge upstream?

Besides, have you seen the change just in src/StelMainView.cpp?

 src/StelMainView.cpp | 4818 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 4769 insertions(+), 49 deletions(-)

[joinother]

@10110111 fair point, the commit history is indeed a mess right now. Those are all AI-assisted development commits with Chinese messages.

To clarify: I'm not expecting an upstream merge at this stage. The discussion post itself says "I do not intend to make a pull-request to upstream mainline for now." This is still an active side-project port.

As for StelMainView.cpp — the +4800 lines are an N-API command bridge (ArkUI↔C++) that lets the HarmonyOS UI talk to Stellarium's core. I know it's ugly having it all in one file. Plan is to extract it into a separate StelOhosBridge.cpp before any upstream consideration.

I'll squash the commits into a handful of logical ones once the port stabilizes. Thanks for taking a look!

[alex-w]

@alex-w Hmm, I've just checked it out, and found that it has 171 commits generated by an AI tool with commit descriptions in Chinese. I'm at a loss how (and when) I could review this amount of changes. Do you have any actual idea what exactly of this you want to merge upstream?

Besides, have you seen the change just in src/StelMainView.cpp?

 src/StelMainView.cpp | 4818 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 4769 insertions(+), 49 deletions(-)

Ouch… Most changes was made in latest few hours and I haven’t seen it, plus GH shows weird diffs :(

[joinother]

Thanks for looking at the branch. I agree that it is currently far too large and messy for a PR. We are still developing the HarmonyOS app, so I will keep that work separate for now.

When it is more stable, what would be the most useful small part to prepare first for upstream? For example, should I start with the CMake/Qt build setup for OHOS, or something else?

I would only propose a small, self-contained change with English commits, documentation, and testing - not the current UI or the large bridge code.

[joinother]

@alex-w

[alex-w]

Eating the elephant need to be chunks :)

Yeah, the cmake part for checking OHOS platform is first part who need to be implemented as a module (see cmake directory in our source code). The next one is including/excluding Qt modules (or other needed stuff) for OHOS via cmake. Of course the comments and documents should be in English.

[joinother]

Thanks, that makes sense. For the first patch, I will add a small CMake module that detects OHOS from CMAKE_SYSTEM_NAME and use it as the single platform check. I will keep the Qt module/dependency selection in a separate follow-up patch, with English comments and documentation. Does that split look right

[alex-w]

Yes, this is right way IMHO - separate patches for separate features (+ rebase the "big patch")

[joinother]

Thanks, I have split the first part into a small PR: #5065 adds only the CMake OHOS platform detection module and is rebased on current master. I kept the Qt Positioning changes separate and will rebase/open them as a follow-up after this direction is confirmed. Does that match the split you had in mind?