Recently, I saw an Air series software project on GitCode and found it quite interesting. This series mainly attempts to port some desktop open-source software to HarmonyOS.
Project Warehouse:
I personally pay close attention to the porting of Qt/KDE apps to HarmonyOS, so this time I mainly tried Krita and Audacity.
My testing equipment
Currently, two devices are used for testing:
Huawei MateBook Pro（2-in-1 / PC）
Huawei MatePad Pro Max（Tablet）
These two devices represent typical PC and tablet usage scenarios and are also suitable for observing the actual experience of desktop applications on HarmonyOS.
Harmony-krita / AirDraw
Harmony-Krita was completed relatively early, around mid-August.
In actual use, I have basically encountered no obvious problems for about two consecutive weeks. What impressed me most was that both the fingers and stylus could draw normally, making the overall user experience quite complete.
Judging from the code and project structure, this version should be based on Qt 5’s Krita.
KDE ECM handling methods
Krita itself is a large application within the KDE ecosystem, so a key issue to watch when porting Krita is:
How is KDE Extra CMake Modules (ECM) handled?
Upstream ECM:
https://github.com/KDE/extra-cmake-modules
So far, I haven’t found a clear ECM approach in Harmony-krita.
Currently, the Harmony-krita repository has only two commits:
The first commit: the main code, imported content, and modifications are basically concentrated here.
Second commit: mainly modifying the README.
In other words, the core porting work is basically all placed in the first commit.
This approach is relatively straightforward for quickly completing a single port, but from the perspective of subsequent maintenance and upstream review, it is harder to trace the history.
I refreshed the submission history
So, I compared Krita’s upstream warehouse:
https://invent.kde.org/graphics/krita
Then I reorganized the Harmony-Krita submission history, hoping to to:
Upstream code
HarmonyOS related modifications
Build related modifications
The relationship between them becomes clearer.
The new submission history is located at:
https://github.com/liangqi/krita/commits/Harmony-krita/
Currently, I haven’t finished local compilation for this version, and further verification is needed.
However, from a code organization perspective, this approach should be more conducive to subsequent analysis and maintenance, and is closer to the upstream + patch development model commonly used in open source projects.
Harmony-Audacity / AirAudio
Harmony-Audacity was completed around August 25.
I conducted actual tests on the equipment, and the overall situation was a bit more advanced than simply “being able to start.”
The first launch question
The first time you open the app, there is no prompt prompt immediately asking “Do you want to allow the app to use the microphone?”
At the same time, the app also feels somewhat stuttering.
At that time, the application appeared to have not been fully initialized.
My approach is:
End the application process;
Restart;
This time, a microphone permission request appeared;
After allowing microphone permissions, recording and playback functions can work properly.
So at present, it seems there may still be some issues with permission initialization during the first startup.
Tablet mode
There is still a relatively obvious problem with tablet devices:
The app cannot be fullscreen.
For desktop apps like Audacity, the window size and display on tablets are still areas worth further optimization.
The technology stack behind Audacity
From the code perspective, Audacity involves many professional third-party libraries in the audio field.
Among these, the following are particularly noteworthy:
PortAudio
and other audio processing dependencies
This makes me feel that HarmonyOS’s support for desktop software is no longer just a simple GUI porting issue.
For an application to truly run, it actually means the following infrastructure must gradually be established:
Desktop Applications
│
├── GUI Framework
│ └── wxWidgets / Qt
│
├── Audio Framework
│ └── PortAudio
│
├── Codec / DSP Libraries
│
├── File / Thread / Network
│
└── HarmonyOS Platform
Especially for low-level libraries like PortAudio, if they can already work properly on HarmonyOS, it will be very valuable for future porting of more professional desktop software.
Additionally, Audacity 3.7.8 uses wxWidgets.
This itself is a very interesting signal:
If Audacity can basically run on HarmonyOS, it means that the wxWidgets layer is already somewhat feasible on HarmonyOS.
Therefore, in the future, it may not only be Qt/KDE applications; other traditional Linux/Windows desktop application frameworks may also have opportunities to gradually enter HarmonyOS.
Looking at the code repository, Audacity goes a step further than Krita
If you look purely at “whether the app can run,” both Krita and Audacity have made good progress.
But from the perspective of the code repository itself, I think Harmony-Audacity has made clear progress over Harmony-krita.
Harmony-Audacity has recorded the following content more comprehensively:
Upstream code sources
HarmonyOS patch
Build the script
The construction process
Third-party dependency
In other words, it’s not just about “compiling the software,” but starting to record step by step:
How this software is built from upstream source into a HarmonyOS application.
This is very important for subsequent maintenance.
Especially for third-party libraries, a fairly unified approach has now emerged.
This could become a very important step in the future migration of HarmonyOS desktop software.
From Krita to Audacity, a change can be observed
Looking at these two projects together, you can actually spot an interesting trend.
Harmony-Krita is more like an early quick port:
上游代码
↓
引入 HarmonyOS 修改
↓
完成构建和运行
Meanwhile, Harmony-Audacity began to pay more attention:
Upstream
│
├── Source
│
├── Patch
│
├── Build Script
│
└── Third-party Dependencies
│
↓
HarmonyOS Build
This means the project focus is shifting from:
“Can I run?”
Gradually shifting to:
“How to Maintain and Build Properly”
For large desktop open-source software, the latter is actually even more important.
Because the real difficulty is often not getting the program running for the first time, but rather the following:
How to track upstream;
How to maintain the HarmonyOS patch;
How to resolve third-party dependencies;
How to make the build process repeatable;
How to continuously synchronize with new versions;
How to ultimately contribute changes back to the upstream.
I’m quite looking forward to the next step
From my own interests, what I should continue to focus on is the ecosystem issue of Qt/KDE applications on HarmonyOS.
For example, Krita is just one example.
If Qt, KDE Frameworks, ECM, and common third-party libraries gradually establish stable HarmonyOS support, then theoretically, more KDE/Qt desktop applications may enter HarmonyOS in the future.
Projects like Audacity offer another path:
Besides Qt, traditional desktop application frameworks + third-party libraries in specialized fields are also starting to be portable.
If these two paths continue to develop, the open-source desktop application ecosystem on HarmonyOS will be more meaningful than simply porting a few GUI applications.
Summary
This time, I mainly experienced two activities:
ProjectSoftwareApproximate completion timeMain frameworkCurrent experienceHarmony-kritaKrita / AirDrawMid-AugustQt 5 / KDEFinger and stylus drawing is basically normalHarmony-AudacityAudacity / AirAudioAround August 25wxWidgetsRecording and playback are basically usable
Personally, I think what deserves attention right now is not “a certain app has already started,” but the changes behind it:
Porting open-source desktop software on HarmonyOS is gradually evolving from one-time code modifications to a systematic approach of upstreams, patches, build scripts, and third-party dependency management.
Especially as third-party libraries begin to adopt unified processing approaches, this may become an important foundation for large-scale migration of Qt, KDE, and other desktop applications in the future.
For me, this was also the most interesting part of this test.